Retail operations
MultiPOS — A point of sale with an operational spine
A point of sale system for retailers running more than one branch, live at pos.awesome.co.ke.
pos.awesome.co.ke
The problem it was built for
Most retail software treats the till as the product and bolts stock control on afterwards. The result is familiar to anyone who has run a shop: the till says one thing, the stock report says another, and by month end nobody can say with confidence which of the two is right.
That gap is rarely carelessness. It is usually that the sale and the stock movement were written to the database as two separate events, and something — a dropped connection, a crashed tab, a till switched off mid-sale — happened in between. Once the two records disagree, every number built on top of them is suspect.
How MultiPOS handles it
The sale, the payments taken against it, the customer balance and the stock ledger commit as a single database transaction. Either all of it lands or none of it does. There is no window in which a sale exists but its stock movement does not, so the till and the stock report cannot drift apart in the first place.
That guarantee holds across branches. A business running several locations sees one set of books rather than one per till, and the ledger is the same ledger everywhere.
Isolation you do not have to remember to apply
MultiPOS serves many businesses from one platform, and each one is isolated at the database itself rather than by convention. It is not a shared table filtered by a WHERE clause that a future query might forget to include — the boundary is enforced underneath the application, so no business can read another's records.
This matters most in the cases nobody plans for: a new report, a bulk export, a support query written in a hurry. Isolation that depends on every developer remembering it eventually fails. Isolation enforced by construction does not.