There is a moment every retail founder learns to dread: Saturday afternoon, queue at the till, and the internet drops. If your point-of-sale system is a thin client over someone's cloud API, that queue is now watching your staff apologise. After years of building POS systems for restaurants and retail, we treat one architectural rule as non-negotiable: the till must work with the network cable cut.
The failure mode nobody prices in
Cloud-first POS vendors quote uptime for their servers — 99.9% and up, usually honestly. But your checkout's real availability is that number multiplied by your shop's connectivity: the router, the ISP, the card network, the Wi-Fi that shares a wall with a microwave. A branch with a flaky line can lose checkout for an hour a week while every vendor status page stays green. Nobody's SLA covers the sale that walked out the door.
What offline-first actually means
Offline-first is not "we cache the product list". It is a design stance: the local device is the source of truth for the transaction, and the cloud is a sync target — not the other way round.
The till owns the sale
Every terminal runs a full local database — products, prices, tax rules, the day's transactions. Scanning, discounting, splitting bills, printing receipts: all of it completes locally in milliseconds, network or no network. A sale is committed the moment the receipt prints, not the moment a server acknowledges it.
Sync is a background conversation
When connectivity exists, terminals stream their transaction log to the back office and pull down catalogue changes. When it doesn't, the log queues. The interesting engineering lives in the reconciliation rules:
- Sales are append-only events — they merge trivially; two tills can never conflict about different sales.
- Catalogue changes flow one way — head office wins; a price change reaching a till late is versioned, so yesterday's sale keeps yesterday's price.
- Stock counts are the hard case — two tills selling the last unit while offline is unavoidable, so the system is honest about it: stock is eventually consistent, oversells surface as reconciliation alerts, and purchasing decisions use synced totals, never a single till's view.
Payments degrade gracefully
Card networks are the one dependency you cannot fake locally. An offline-first POS handles this with a policy ladder, not a spinner: store-and-forward for contactless under a floor limit where the acquirer allows it, a clear switch to cash-or-card-machine mode where it doesn't, and a queue that settles automatically when the line returns.
The numbers that justify it
Offline-first costs more to build — local storage, sync protocols, conflict handling, device provisioning. The arithmetic that justifies it is brutal and short. Take a shop doing £2,000 an hour on a Saturday. Four connectivity incidents a year at 45 minutes each is £6,000 of walked-away revenue — per branch, per year, forever. Multiply by a ten-branch estate and the "expensive" architecture pays for itself before the first renewal of the cheap one's licence.
And the soft costs are worse: staff who stop trusting the till start keeping paper fallbacks, and a fallback culture corrupts your data far more thoroughly than any outage.
Questions to ask your POS vendor
Whether you buy or build, these five questions expose the architecture in two minutes:
- Can a terminal complete a sale — scan, discount, receipt — with the router unplugged?
- Where does a committed transaction live before the network returns, and what happens if the device dies in between?
- How do two offline tills resolve selling the same last unit of stock?
- What is the card payment behaviour during an outage — store-and-forward, declined, or undefined?
- When connectivity returns after a full day offline, how long until head office reporting is whole again?
"That basically never happens" is an answer too. It tells you the vendor has never run a shop.
If you are speccing a POS — for one site or fifty — we are happy to talk through the architecture before you commit to anyone, including us.