Why Your POS Should Keep Selling When the Internet Goes Down 

Picture a Saturday afternoon in a busy store. Twelve people in the queue, two tills open, and the internet drops. If the POS is a web app talking to a cloud API on every keystroke, the tills are now furniture. A retail chain we worked with measured exactly this before rebuilding: across 14 locations, they averaged nine connectivity incidents a month, and their old cloud-only POS turned each one into 20 to 40 minutes of handwritten receipts and abandoned baskets. Their own estimate put the loss at around $3,000 per store per month, before counting the customers who just left. That number is why offline-first POS system development exists as a discipline, and why 'it needs internet' should be a disqualifying answer when you evaluate retail software.

Offline-First Is an Architecture, Not a Cache

Plenty of vendors claim offline support because the product keeps the UI alive when the network blips. That's not the same thing. A genuinely offline-first POS treats the local device as the source of truth for the transaction: the catalog, prices, tax rules, and promotions live in a local database, sales get written locally first, and a sync engine pushes them to the cloud whenever a connection exists. The cloud becomes the aggregation and reporting layer, not a dependency in the checkout path. In practice that means an embedded store like SQLite on the till, a durable outbound queue for completed sales, and a versioned catalog that updates when connectivity allows. The till should be able to run a full trading day, hundreds of transactions, with the router unplugged. If a vendor can't demo that, unplugged, in front of you, the claim is marketing.

The Hard Part Is Coming Back Online

Selling offline is honestly not that difficult. Reconciling afterwards is where the engineering lives. Two tills sell the last unit of the same SKU while disconnected: which sale stands? A price change published at head office at 2 p.m. reaches one store at 2:01 and another at 6:40: which price was correct in between? Our answers are boring on purpose. Sales are append-only events that never conflict, they just accumulate and sum. Inventory is a projection over those events, so overselling gets detected at sync time and routed into an exceptions workflow rather than silently corrupting stock counts. Prices carry effective timestamps, so the price at the moment of sale is always defensible. What you don't do is bidirectional field-level merging of an inventory table. Teams that try that spend months chasing phantom stock discrepancies that nobody can explain to an accountant.

Yes, Cards Can Work Offline Too

The usual objection is payments: surely card transactions need the network? Mostly, but not absolutely. Modern payment terminals support store-and-forward, where the terminal approves transactions below a floor limit offline and submits them when connectivity returns, with the merchant carrying the risk on declines. On the chain we worked with, the floor limit was set at the equivalent of about $60, which covered 80 percent of their basket sizes, and the measured loss from offline declines came to a fraction of a percent of offline sales, a rounding error next to the revenue that would have walked out the door. The POS still needs to handle the workflow honestly: mark the payment as pending capture, reconcile terminal settlements against sales at sync time, and surface the rare failed capture to a manager instead of burying it. Cash, obviously, needs nothing but a drawer that opens. The point isn't that offline payments are risk-free. It's that the risk is small, boundable, and priceable, while the queue walking out is not.

What It Costs and What It Buys

Building the sync layer properly added roughly 30 percent to the till-software budget on that 14-store rebuild, most of it in the event queue, conflict handling, and the test rig that simulated flaky networks. What it bought back was concrete: zero checkout downtime in the first year despite the same nine-ish incidents a month, and an unexpected bonus, faster checkouts even when the network was fine, because scanning and totaling ran against the local database instead of a round trip to a cloud API. Latency per scan dropped from around 400 milliseconds to under 50. Cashiers noticed before management did.

Questions to Ask Any POS Vendor

• Can a till complete a full sale, including card fallback and receipt, with the network cable pulled out?
• Where does a completed sale live in the five minutes before sync, and what happens if the till loses power in that window?
• How are two offline sales of the same last unit reconciled, and who sees the exception?
• Do prices and promotions carry effective timestamps, or does last-write-win decide what a customer was charged?
• What's the longest a store can trade fully offline before something actually breaks?

The Takeaway

Connectivity failures are an operating condition for retail, not an edge case, and the checkout queue is the single worst place in your business to discover that your software disagrees. If you're specifying a new POS or replacing one that keeps taking your tills down with the router, put offline behavior in the acceptance criteria with numbers attached: transactions per offline day, sync recovery time, exception handling for stock conflicts. Then test it the way that retail chain now tests every release candidate: walk to the router, pull the cable, and run twenty sales. It takes ten minutes and it settles the argument better than any architecture diagram. Vendors who've built this will answer precisely and pass the test without flinching. Vendors who haven't will change the subject to dashboards.