Why Software Cracks When You Open a Second Branch

Most systems crack when the second branch opens. Not because the software is small, but because it was built on the assumption there would only ever be one.

The symptom is always the same. Each site starts keeping its own records, head office asks for files to add them up, and at month end the total does not agree.

The answer is not to separate the branches

The first instinct is usually a separate installation per site. That works in the short term and destroys the central view completely.

The right structure is everyone writing to the same place while seeing only their own scope. We call that scope, and it is one of the most expensive things to add afterwards.

Where scope comes from

This is the critical technical decision. What determines which branch a user can see?

The wrong answer is the request. Trusting a branch id sent by the browser. A user who changes that value reads another branch data, and it can take months to notice.

The right answer is the session. Which branch a user belongs to is established when they sign in, and every query is locked to it.

The restriction belongs in one place

Writing the scope check into every query by hand means one day somebody forgets. And a forgotten check does not raise an error, it quietly works for everyone.

So the restriction lives in a shared layer. Someone writing a new screen does not have to think about scope, because the foundation already applies it.

And we do not assume it holds. We open two branch accounts and ask for the records of one while signed in as the other. If that works, there is a hole.

What sits centrally and what sits locally

This gets decided at the start, and separating them later is hard.

Usually the product definition sits centrally while price and stock sit with the branch. Leaving everything to the branches makes the catalogue drift apart. The same item ends up recorded under three different names at three sites and head office cannot add it up.

The opposite causes problems too. Locking price entirely to the centre leaves a branch unable to respond to local competition.

Should head office see everything

That is a data decision rather than a permissions one. Revenue and stock are normally open to the centre and that is reasonable.

For staff records and customer contact details the necessity is worth questioning. A system where everyone sees everything does the widest damage on the day something leaks.

With a franchise the boundary is harder

The structure is the same but the rule changes. A franchisee sees their own data, head office sees the total, and franchisees see nothing of each other.

Testing is essential here. Two franchisee accounts are opened and cross access is genuinely attempted. Assuming it is fine means accepting the risk that two competing franchisees can read each other customer lists.

When a branch closes

The data of a closed branch is archived rather than deleted, because historic reports still read from it.

Deleting a branch also deletes the revenue figures from three years ago. By the time anyone notices, there is no way back.

How many branches will it handle

The limit is set by data volume rather than branch count. If the structure was built with scope from the start, adding a branch is a definition change rather than a coding job.

Adding scope afterwards means reviewing every query one by one. That is where the real cost sits, which is why having this conversation before the second branch opens is far cheaper than having it after.

Without per-branch reporting there is no comparison

A single total says nothing. A dip at one site only becomes visible next to the others.

Revenue, stock turnover and staff performance need to be held per branch. This ends up being the screen head office uses most, because comparison is what makes a decision possible.

One thing to watch here. The same measure coming out differently on two screens ends trust immediately. What does revenue mean, do cancelled orders count, are refunds deducted. Those get defined once and every report uses that definition.

How stock moves between branches

Inter-branch transfers are the most commonly skipped part of a multi-site business.

When one site has too much of something and another too little, stock moves. If that move is not recorded, both sites end up with wrong figures and the total does not agree.

A transfer is a process with its own flow. Has it left, is it in transit, has it been received. Those are three separate states, and it is the only way to find where something went missing.

Opening a branch should not be a coding job

Here is a simple test. If opening a new branch means calling a developer, the structure is not multi-branch.

A branch should be a definition. It gets added from the panel, users are assigned, and it starts working. The system should not be what slows growth down.