The jobs the pretty site will not do
A brochure site has one main user: someone who does not have a login. They read, they call, they send a form. That is honest work. It is also a different job from the one a dealer does on a Tuesday afternoon: check a claim, download this month’s price list, see which invoices are open, ask why a shipment is late. Those actions need a person, a role, a record, and a guarantee that the next dealer cannot open the same page and see the numbers.
Calling the second job “a members area” or “a website plugin” is how firms buy a theme, install a login add-on, and then discover that two accounts share a password “just this once”. The leak is not a theoretical security talk. It is a price list in a WhatsApp group by Thursday. This post is about the jobs a brochure cannot do, and the hybrid that usually should: Tally stays, the public site stays, a small portal does claims and prices.
The distinction is the same one we use on website versus web application. Anonymous visitors versus signed-in users with permissions. SEO versus a snappy screen under real data. A marketing failure versus a spreadsheet that appears beside the tool. If you need both — and most dealer networks do — they can share a brand and still need two definitions of done. .NET development is how we usually build the logged-in side. The brochure remains a website.
Claims are a process, not a form mail
A claim has a start, a state, and an end. Someone raises it. Someone attaches a photo or a note. Someone accepts, rejects, or asks for more. Accounts may need a credit. The dealer needs to see where it sits without ringing a person who is already on another call. A contact form that emails the office is not a claim. It is how claims get lost in a shared inbox when two people are on leave.
The rules are yours. No reputable product knows how you treat a damaged carton, a short shipment, or a warranty that is almost out of date. A package may give you a ticket. Staff will still keep the “real” decision in a sheet. That is the 80 percent test again. If the missing part is the decision you actually make, you do not have a plugin gap. You have an operational middle that belongs in a small application.
Write the states on one line: drafted, submitted, information requested, accepted, rejected, credited. Write who may move each state. Write what the dealer may see — usually the history of their own claims, not the queue of everyone else’s. Write what must post to Tally and what must never be typed twice. That page is the brief. A screenshot of a purple theme with a “support” menu is not.
Photos and PDFs will arrive. They need a place that is not a personal WhatsApp. They need a size limit and a person who can say the file is unreadable. They do not need a full document-management platform on day one. They need to stay attached to the claim when the dealer rings on Friday. If your first slice cannot do that, the WhatsApp group will remain the system of record.
Price lists that must not leak
Dealer prices are often the most valuable file in the building after the ledger. They differ by dealer, by slab, by season. They are not the MRP page on the public site. The brochure can show a range or a “call us”. The portal must show the number that dealer is allowed to see, and no other.
A shared PDF in a Google Drive folder is a leak waiting for a forwarded link. A WordPress download page with one password for all dealers is the same leak with a nicer header. A spreadsheet emailed every month is a leak plus a version problem: someone is always looking at last fortnight’s rates. If you are going to build anything in the portal first, this is often the slice — current list, by login, with a date, and a log of who fetched it.
Do not put the master list in the browser “hidden” in the page source. Do not use the same URL for every dealer with a different filename you hope they will not guess. The application has to decide the rows after it knows the person. That is ordinary authorised software. It is not a CMS trick. If a vendor quotes a plugin, ask what happens when two dealers share a login, and who owns the price file. Those answers decide build versus buy more honestly than a feature matrix.
Some firms also need the dealer to see only some products, or to see a list that expires. Put that in the first sentence if it is true. Leave it out if it is a wish. An MVP that publishes a dated, per-dealer list and records the download will teach you whether dealers stop asking for WhatsApp photos of the printout. A portal that also tries to be a full commerce engine will ship late and still leak if the permissions are sloppy.
Logins that must not leak
Every dealer is a person, or a small set of people, not a city name. “Kozhikode_dealer” with a password on a sticker is how you lose isolation the first time a salesperson leaves and the password does not change. Issue accounts to people. Give the dealer-principal a way to ask for a reset. Log who signed in. When someone leaves, turn them off the same day you take the visiting cards back.
Do not reuse the public site’s admin login for dealers. Do not reuse a single database role for “all external users”. Row-level rules are the product: this person sees these claims, these invoices, this price list. If you cannot say that in a sentence, you are not ready to build. You are ready to write the sentence.
Shared logins will be requested. “Just this once, the accountant and the owner can use the same one.” Say no, or accept that you have already designed a leak. If two people must act, issue two accounts. If a firm insists on one login, write the risk on the brief so nobody is surprised when a price list travels. We would rather lose a plugin-shaped job than pretend a members plugin is isolation.
Password reset, lockout after guesses, and a session that ends, belong in the first slice. They are not polish. A portal that emails a new password in plain text to a shared inbox is a brochure with extra steps. Hosting has to match the job: a database you can restore, identity that is not a shared password, a person who can roll back a release. Cheap shared hosting that cannot take a backup is for a marketing site. This is not a marketing site.
Hybrid with Tally — the usual architecture
Tally, or the ledger you already file from, stays the system of record for money. The public website stays the system of record for the story you tell strangers. The portal is the system of record for the dealer’s jobs: claims, the price list they are allowed to see, maybe order status if you can post it without inventing a second stock truth. Three systems, two joins. That is a hybrid, and it is the usual right answer.
The join to Tally is an export, an import, or a small service that posts a credit when a claim is accepted. It is not a promise that the portal will “replace accounts”. Replacing accounts is how custom projects get a bad name. If a line must appear in the books, decide who posts it and when. If the portal shows invoice copies, decide whether that is a PDF you already issued or a live balance you will have to explain when it disagrees with Tally by a few rupees. Disagreement is normal. An unexplained disagreement is a Friday gone.
Stock is the dangerous extra. If the portal starts promising quantities the warehouse does not have, you have grown a second system of record. Either the warehouse system is the truth and the portal is a delayed view, or you are not ready for that slice. Status of an order is often enough for the first year. Live stock is a different product.
Buy the commodity. Build the middle. We have written that on the custom versus off-the-shelf page, including a dealer-portal walk-through. This post is the operational version: claims, prices, logins, Tally. It is three sentences and, if the data is dirty, a first slice measured in months, not a weekend plugin.
What the first slice should contain
For most networks the first slice is: a person logs in, sees their claims, raises a new one with a file, sees the current price list, and cannot see anyone else’s. Optional if the data is already clean: a list of recent invoices as PDFs you already issued. Not in the slice: a full catalogue with cart, a loyalty scheme, a bilingual academy, last year’s analytics, a mobile app that does the same thing with a different vendor.
Write the assumption: “Dealers will raise claims here instead of email.” Count after two weeks. If they do not, you have learned cheap. Maybe the claim still needs a phone call because the rule is not written. Maybe the login was too hard on a cheap phone. Maybe the person who used to collect claims on WhatsApp is still faster. Do not add a chat widget to rescue the assumption. Fix the sentence or stop.
What we will not strip out: roles, backups, undo or a clear “withdraw”, a handover. A portal without a restore is a new place to lose the only copy of a claim photo. A portal without a handover is a vendor login you will still be asking for in year three. Estimate it as custom software on ASP.NET Core, not as five extra pages on the brochure.
A table for the briefing room
| Job | Brochure site | Portal |
|---|---|---|
| Explain the firm | Yes | No — link out |
| Rank in Google | Yes, public pages | Usually irrelevant behind login |
| Raise a claim | Email form at best | States, files, history |
| Show a dealer price | Unsafe | After identity, per row |
| Stop a leak between dealers | Cannot | The definition of done |
| Post money | No | Join to Tally, not a second ledger |
Client portals are the same shape with different nouns
Replace “dealer” with “client” and the jobs become document upload, case status, a report they are allowed to download, an invoice copy. The brochure still cannot do those safely. The same isolation rules apply. A school, a clinic, a service firm with retainers — the nouns change, the architecture does not. Public pages for strangers. A login for people who have a relationship. Tally or the practice ledger for money.
If the client’s job is to book a slot, the public page can be a website. The receptionist’s all-day screen is still an application. We have used that example on the website-versus-application page. Do not let a vendor fold them into one “portal” quote because the word sounds modern. Split the definitions of done. A single line is how the diary survives.
Permissions for clients are often stricter than for dealers. A family must not see another family’s file. A company must not see another company’s retainer notes. If you cannot name the rule, do not build. A workshop that writes the rule is cheaper than a launch that becomes a conversation with a lawyer.
How to keep the brochure from pretending
Give the public site a clear path: here is who we are, here is how to become a dealer or a client, here is the login for people who already are. Do not publish sample prices that contradict the portal. Do not put a fake “check your claim” widget on the homepage that emails a mailbox. The brochure’s job is to be fast, true, and findable. The portal’s job is to be correct for the person who signed in.
They can share a header and a mark. They can share a hostname. They should not share a cache that might show the wrong user’s list. They should not share one estimate. Marketing URLs are a website problem. App URLs are a software problem. If you are still arguing in the briefing, write who the daily user is. Price from that sentence.
If a vendor returns a theme list and a plugin list for claims and isolated prices, they have answered. Thank them and keep the brochure brief if you still need pages. Take the portal brief to someone who will talk about roles, restores, and Tally. That split is not snobbery. It is how you avoid paying twice — once for the plugin, once for the rewrite.
June is a good month to write the three sentences: what the brochure will do, what the portal will do in the first slice, what Tally will remain. If you cannot write them, you are not choosing software yet. You are still choosing the job. Come back when the sentences exist. The build-versus-buy table is then easy to apply, and the night shift — or the dealer on a phone in Palakkad — will not be asked to invent a workbook beside a site that was only ever meant to look nice.