Engineering6 min read
Building software for businesses that outgrew the spreadsheet
The hardest requirement in a back-office rebuild is usually the workflow nobody wrote down.
A business with three locations is typically running on a register book, a payments app and a messaging group. It works, in the sense that the business runs. What it cannot do is answer questions across locations, and it loses things — a membership that expired, an enquiry that nobody followed up.
The undocumented workflow is the requirement
Every one of these businesses has a process that exists only in one person's head: how a transfer between branches is handled, which discounts a manager may apply, what happens when someone pays half now. It is never in the brief. It surfaces in week three, and it is not an edge case — it is frequently the thing the business most needs the software to respect.
The practical response is to spend real time watching the current process before designing the replacement, and to treat every 'oh, we usually just…' as a requirement rather than an irregularity to be tidied away. Software that forbids how the business actually works does not change the business; it gets worked around, and then the spreadsheet comes back alongside it.
Multi-branch is a data model decision, not a feature
Retrofitting multiple locations onto a single-location schema is one of the more expensive mistakes available. Even if the client has one branch today, the questions are worth answering up front: does a customer belong to a branch or to the business? Can staff work across branches? Is a price list global or local? These answers shape the schema, and changing them later means changing every query that touches them.
Roles are about blast radius
Role-based access in a small business is not primarily about malice. It is about limiting how much damage a tired person at the front desk can do at the end of a long shift. Who can delete a member, who can change a price, who can see revenue — those permissions are a safety feature, and framing them that way with the client tends to get a far more useful conversation than framing them as security.
Migration is the whole project
The register book has to get in. It will be inconsistent, it will have duplicates, and the business will keep writing in it during the switchover. Plan for a period of dual running, decide in advance which system wins on a conflict, and budget real time for the import. A back-office rebuild that is technically finished but has no data in it has not shipped.
