Point of sale for a shop that also holds stock
A counter that takes payment, and behind it the stock, the suppliers and the day’s reconciliation — one system rather than a till that has to be squared against an inventory sheet after closing.
Talk about scopeEverything happens with a customer waiting
A point of sale is the only system we build where the user cannot pause to work around a problem — there is a queue, and every second of hesitation is visible to it. That constraint outranks features: a screen that needs two taps instead of one costs real money across a day, and staff who find the system slower than the old one will simply keep a paper record beside it. Designing for the queue, rather than for the reporting the owner wants, is what separates a till people use from one they route around.
Everything in the first column queues locally and settles on reconnect, in the order it happened. Everything in the second fails at the counter, where somebody can still do something about it.
What we would build
It has to sell with the internet down
A till that stops when the connection drops is not a till. That single requirement decides the architecture: the counter queues transactions locally and reconciles later, which forces an early answer to what it may do while blind — which prices it still trusts, whether it can take a return, and what it must refuse rather than guess.
The count at close is the real test
Cash drawer, card settlement and the day’s recorded sales are three numbers that must agree, and the useful system is the one that shows where they diverged rather than reporting a variance. Voids, refunds, discounts and staff overrides are where the difference always comes from, so each has to be a recorded event with a name on it.
Stock moves at the counter, not at month end
Every sale is an inventory movement, and a POS that posts stock in a nightly batch is one where the shelf and the screen disagree all day. Selling a line to zero, receiving a delivery mid-shift and reversing a mistaken sale all have to settle against the same live quantity.
Where a shop outgrows a till
The point at which businesses come to us is usually not the counter — it is the second outlet, the supplier account that needs terms, or the accountant asking for a figure the till cannot produce. That is when a point of sale stops being a device and starts being the front end of a stock and purchasing system, and it is a much cheaper transition to design for than to retrofit.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.