Most conversations about point of sale start and end at the till. That is the part a cashier sees, and it is perhaps a tenth of the system. A production POS also has to know what the shelf holds, what each branch may sell, who can discount, and what still sold while the connection was down.
The till is a writer, not the truth
The single most consequential decision in a retail system is whether stock is a number you update or a consequence you derive. Systems that store a quantity and adjust it on each sale drift immediately, because sales are only one of the events that change stock: returns, damages, transfers, supplier deliveries and corrections all move it too, and most of them happen away from the counter.
Modelling stock as a ledger of movements costs more up front and settles the question permanently. Every quantity on screen is the sum of recorded events, each with a timestamp, an actor and a reason. When a count disagrees with the system, the history explains why rather than inviting a guess.
Branches are a data model, not a report
Businesses usually discover multi-branch requirements after opening the second location, at which point it is tempting to treat it as a reporting problem — add a branch column, filter the totals. It is not. Branch affects stock, pricing, permissions, transfers and reconciliation, and retrofitting it touches nearly every query in the system.
Designing for branches from the beginning is inexpensive when there is only one. The alternative is the rewrite that most retail software eventually undergoes.
Offline is a product requirement, not a nice-to-have
A queue does not pause because the internet dropped. If billing stops, the business stops, so offline capability is a trading requirement rather than a technical luxury — and it is genuinely hard, because the risk is not failing to sell but selling twice.
The workable approach is to let the till write locally with client-generated identifiers, then reconcile on reconnect with idempotent handling so a replayed sale cannot become a second sale. Staff also need to see the state clearly: working offline, syncing, or synced. Hiding it produces the worst outcome, where nobody knows whether a transaction was recorded.
Permissions belong at the data layer
Retail permissions are specific: who may discount, who may void, who may see cost price, who may adjust stock. Enforcing these by hiding buttons is not enforcement — it is presentation. The rules have to live where the data is accessed, so a request that bypasses the interface is refused the same way.
The related requirement is attribution. Voids, discounts and adjustments each need a person attached, because that record is how a drawer variance gets explained rather than argued about.
Specify the operation before the interface
If you are specifying a retail system, write the operational list first: stock movements, returns, credit, branches, permissions, reconciliation. Decide what the till screen looks like afterwards.
Doing it the other way round produces a fast, attractive checkout that lies about inventory — which is the most expensive kind of software to discover you have bought.
Working on something this touches on? Tell us what you are building — we will say honestly whether we are the right team for it.