Contact Us
Back to blog

Offline-First POS: Why Your Point-of-Sale Shouldn't Depend on the Internet

Ask any restaurant or retail manager in Nairobi what "the system is down" means, and they won't describe a software bug. They'll describe a queue of customers, a cashier writing receipts by hand, and a manager mentally kissing goodbye to an hour of sales data. Power isn't always reliable, and neither is fibre — which makes "offline-first" one of the few POS features that isn't a nice-to-have.

What "offline-first" actually means

Most point-of-sale software is built cloud-first: every sale, every stock adjustment, every shift clock-in is a request to a server somewhere, and if that request fails, the action fails too. That's fine in a market with dependable, always-on connectivity. It's a liability everywhere else.

Offline-first flips the architecture. The terminal itself holds a local copy of everything it needs to keep operating — menu items, prices, stock counts, tax rules — and every action (a sale, a void, a stock count) is written to local storage first. The terminal keeps working exactly as if it were online. When connectivity returns, a background sync process reconciles the local queue with the central system, resolving conflicts (two terminals selling the last unit of stock, for instance) using rules agreed in advance rather than whichever request happened to arrive first.

What to actually check before you buy

"Works offline" gets marketed loosely. Before you commit to a POS system, get specific answers to these questions:

  • Can you process a full sale — item lookup, discounts, split payment, receipt — with zero connectivity, not just view existing data?
  • What happens to a card or M-Pesa payment initiated offline? (The honest answer for most systems: it queues for retry once online — cash and manual mobile-money confirmation still need a fallback flow.)
  • How does the system resolve a stock conflict when two terminals sell the same low-stock item while both are offline?
  • Does the kitchen display / order routing still work terminal-to-terminal on a local network with no internet at all, or does it also route through the cloud?
  • How long can a terminal run offline before sync becomes a genuine risk (queued data corruption, storage limits)?

The real cost of getting this wrong

The failure mode isn't dramatic — it's a slow leak. A few minutes of downtime here, a miscounted stock adjustment there, a shift report that doesn't reconcile at month-end. Individually forgivable. Over a year, it's the difference between a manager who trusts the numbers on the dashboard and one who re-counts the till by hand every night because they've stopped believing the system.

Core POS was built local-first from day one, specifically because we watched this exact failure pattern play out with a restaurant client running an internet-dependent system. Every terminal keeps taking orders, printing receipts, and updating local stock the moment power and a router are on — sync happens the second connectivity returns, with conflict rules that favour whichever action actually reflects what happened on the floor.

See how Core POS handles offline sales, stock, and multi-terminal sync in detail.

Explore Core POS

Your next great product
starts with one conversation.

Whether you have a detailed brief or just a rough idea — we'll help you shape it into something exceptional. No hard sells, no jargon.

Not ready to call yet?

Drop your email — we'll send you a free technology brief tailored to your industry.

No lock-in contracts
Reply within 4 hours
Dedicated project manager
100% satisfaction focus
Chat with us