One shop runs on trust and proximity. You are there. You know the stock because you can see it, you know the regulars, and when something is wrong you notice within the hour.
The second branch feels like more of the same. It is usually the third that breaks things — and what breaks is rarely the part anyone planned for. Sales are fine. What stops working is knowing what is true.
This happens on a predictable schedule to growing businesses across Udupi and Dakshina Kannada — a jeweller who opens in Kundapura, a supermarket that adds a second floor and then a second town, a bakery with four counters, a pharmacy chain, a hardware business with a godown separate from the shop. The symptoms are so consistent that you can almost set your watch by them.
The four things that break first
In roughly this order, and usually within six months of the third location opening.
1. Stock visibility
A customer at the Udupi counter wants a size you do not have. You are fairly sure Kundapura has it. So someone phones, someone else walks to the rack, and four minutes later you have an answer that was true when they looked. Multiply by forty times a day.
The cost is not the phone call. It is the stock you buy again because nobody could see the three sitting in another branch, and the sale you lose because the customer would not wait.
2. Pricing and discounts
Branch one gives a regular customer five per cent. Branch two does not know he is a regular. Branch three's manager has his own idea of what a reasonable discount is. Within a year you have three price lists and no way to tell which is intentional.
This one is quiet and expensive. It rarely shows up as a problem — it shows up as a margin that drifted and nobody can explain.
3. Cash and credit
Who owes you money, and from which branch? A customer taking goods on credit at one counter and paying at another is routine, and it is exactly the case informal systems handle worst. So is the daily cash reconciliation when three people close three drawers in three places.
4. Reporting
This is the one owners feel personally. You want yesterday's sales across the business before you have had breakfast. Instead you wait for three WhatsApp messages, two of which arrive by eleven, and then add them up yourself. By the time the picture is complete, it is history.
Why putting the software on each computer does not fix it
The obvious move is to buy another licence of whatever runs at the main shop and install it at the new branch. It is cheap and it feels right. It also creates the actual problem.
Now you have three databases. Item code RS-114 means one thing in Udupi and something slightly different in Kundapura. A customer exists three times with three balances. Every consolidated number you ever want again has to be assembled by hand or by a merge routine that somebody has to trust.
The end-of-day merge is where this usually lands, and it has a failure mode worth naming: when the merge disagrees with the branch, people believe the branch. The consolidated system becomes advisory, then ignored, then abandoned, and you are back to phone calls — except now you are also paying an AMC.
WhatsApp is already your software
Almost every multi-branch business we meet is running on WhatsApp groups, and it is worth being fair about why: it works, everyone already has it, and it costs nothing.
What it costs instead is retrieval. The information is all there — the stock photo, the price approval, the delivery confirmation — but you cannot ask it a question. "How many times did we approve a discount over ten per cent last month?" is unanswerable. The data exists and is unusable, which is the most expensive state data can be in.
The test is simple. If answering an ordinary question about your own business requires scrolling, you have outgrown it.
What actually changes with a web application
The answer to three branches is one database that all of them use at the same time. In practice that means a web application: the system lives on a server, and each branch reaches it through a browser on whatever hardware it already has.
The useful consequences, in plain terms:
- One version of the truth. Stock, prices and balances are the same number everywhere because there is only one number.
- Nothing to install. A new counter needs a browser. A new branch takes an afternoon, not a site visit with a pen drive.
- You can see it from anywhere. Yesterday's figures on your phone at 7am, without asking anyone.
- Roles become possible. A branch person sees their branch. A manager approves discounts above a limit. You see everything. This is difficult with copies and natural with one system.
- There is a record. Who changed that price, who cancelled that bill, at what time. Not for suspicion — for answering questions.
That last point deserves a sentence of honesty: an audit trail changes behaviour before anyone reads it. Most of its value is that it exists.
"But our internet goes"
This is the first objection every time, and on the coast it is a fair one. Monsoon, power cuts, a fibre cut on the highway — a system that stops billing when the line drops is worse than the paper it replaced.
There are three honest answers, and a vendor should tell you which one you are buying:
- Accept it, with a cheap backup line. A second connection from a different provider, or a 4G dongle that takes over. For most shops this is enough and costs a few hundred rupees a month.
- Billing works offline, the rest does not. The counter keeps working from the browser's own storage and syncs when the line returns. This is a progressive web app, and it is the right answer for a busy counter.
- A local server at each branch that syncs. Genuinely offline-capable, and genuinely the most expensive and most complicated. Appropriate for large operations and oversold to small ones.
Be suspicious of anyone who promises option three's resilience at option one's price. And be clear about what "offline" must cover: usually it is billing and nothing else. Nobody needs to run a sales report during a power cut.
Roles, and the conversation nobody enjoys
Multi-branch software forces a decision that single-shop software lets you avoid: who is allowed to do what.
Can a counter person cancel a printed bill? Give a discount without approval? See another branch's stock — and its margins? There is no universally right answer, but there is a wrong process, which is letting the developer guess and discovering the answer in month four.
Draw the table above, fill it in yourself, and hand it over as part of the brief. It is one page and it removes most of the ambiguity from the build.
How to roll it out without stopping the business
Do not go live everywhere at once. The order that works:
- One branch, full function, one month. Preferably the busiest, because it finds problems fastest, and preferably one where you are physically present.
- Fix what the first month found. There will be ten to twenty things, and they will mostly be small and specific to how you actually work.
- Add the remaining branches, one per week. By now the software is proven and the training is a half day.
- Only then switch off the old way. Not before, and keep the old data reachable.
Resist the temptation to add the warehouse, the e-commerce site and the loyalty scheme in version one. The business needs one truthful stock figure before it needs anything clever done with it.
Is it worth it?
The honest test is not a return-on-investment calculation, because the biggest gains — fewer wrong decisions, less rework, knowing where you stand — are real but hard to put a number on.
A better test is this: count the hours each week that you personally spend assembling information that should already exist. Adding up branch totals. Phoning to check stock. Working out who owes what. Reconciling three cash books. For most owners at three branches it is between four and ten hours a week, and it is the owner's hours, which are the most expensive in the business.
If that number is small, you do not need this yet, and anyone telling you otherwise is selling. If it is most of a day every week, it will not get better by itself — the next branch makes it worse, not easier.
Where to start
Start by writing down the four questions you most often cannot answer quickly. Not features — questions. "How much of item X do we have across all branches." "What did we sell yesterday, everywhere." "Who owes us more than thirty days." "What discount did we give last month, and who approved it."
Those four questions are a better brief than any feature list, because they describe the business problem rather than guessing at the solution. Hand them to whoever you are talking to and see whether they respond with an answer or a price list.
We build this kind of system as a web application — one database, branch roles, offline billing where the counter needs it — and as ERP development when stock and accounts have to move together. If you are at two branches and thinking about a third, that is the right time to talk, not after. Tell us the four questions you cannot answer and we will tell you what it takes to answer them.
