Opening a second food hall: the settings that have to split first
One building is a special case that hides everywhere. Receipt footers, buzzer rules and till PINs all have to belong to a hall before there are two of them.
Software written inside one food hall quietly assumes there is one food hall. Nothing announces the assumption; it just sits in every setting that was made global because, with one building, global and per-building look identical. The week you sign the lease on a second site is the week every one of those settings turns into a bug.
The list, from our own audit
We went looking for Winchester assumptions in our own product before opening the door to a second hall, and found more than a dozen. The pattern repeats, so the list is worth having whoever your supplier is:
- The receipt footer and support phone. A guest in hall two must not be told to call hall one.
- Buzzer rules. Whether there are pagers at all, how many, lettered or numbered — physical facts about a building.
- The manager PIN and register toggles. Different staff, different building, different overrides.
- Pause switches. Closing one hall for a private event must not stop the other one trading. If "pause ordering" is one switch, it is the wrong shape.
- Reports. A hall owner should see their hall. If a sales report can quietly sum both buildings, one day it will, in front of the wrong person.
Inherit unless overridden
The mechanism that makes this manageable: every setting has a platform default, and a hall stores only what it overrides. Empty means inherit. The screen has to show the difference — an inherited value appears as a placeholder, not as text in the box, or every visit to the settings page silently converts defaults into copies that will not follow future changes.
The question to ask a supplier is not "does it support multiple sites" — everything says yes. Ask where the receipt footer lives, and what happens to the second hall when you change it.