Why your point of sale should work without the internet

There is a moment every shopkeeper who uses a cloud point of sale eventually experiences. A queue of customers, a full basket on the counter, and a screen that will not respond because the connection has gone. The router, the electricity, the mobile signal — it hardly matters which. Selling has stopped.

What happens next is worse than the outage. You start writing on paper. You guess at prices. Stock counts drift out of sync. Later, someone spends an evening keying it all back in, and some of it never gets entered at all.

"Offline mode" is not the same as offline-first

Many cloud systems advertise an offline mode. Read the detail and it is usually a limited fallback: you can complete a sale in progress, or hold transactions for a short period, but core functions — searching the full catalogue, checking a customer's credit balance, running a report — are unavailable until the connection returns.

That is a safety net for a brief interruption. It is not a design for a shop where the connection is unreliable by default.

Offline-first inverts the assumption. The device holds the real data. Every product, price, customer and sale lives locally, and the app never waits for a network to do its job. Syncing, when there is something to sync to, happens quietly in the background. The connection becomes a convenience rather than a dependency.

The practical difference: in an offline-mode system, losing the connection is an event you notice and work around. In an offline-first system, it is not an event at all.

Why this matters more in some markets than others

If your shop sits on fibre in a city with stable power, this is a mild concern. Across much of the world it is not. Scheduled load-shedding, unreliable mains power, mobile data that weakens in bad weather or when the local tower is congested — these are ordinary operating conditions, not emergencies.

Software designed in places where connectivity is assumed tends to treat these as edge cases. For the shop, they are Tuesday.

What offline-first has to get right

Keeping data on the device is the easy part. The details that decide whether it actually works:

• A real local database. Not a cache with a short lifetime — the authoritative copy, on the device, surviving restarts.
• A crash-safe queue. If the app or the device dies mid-sale, the completed transaction must still be there when it comes back. This is where weaker implementations lose data.
• Background sync. Reconciliation happens when a connection exists, without ever making the person at the counter wait.
• Visible sync state. The operator should be able to see at a glance whether everything is synced or something is pending. Ambiguity here creates mistrust in the whole system.
• Local reporting. Closing the day should not require the internet. If you cannot produce your own sales report during an outage, your data is not really yours.

The cost of getting it wrong

It is worth putting numbers on this. A shop taking a modest volume of sales an hour, down for two hours, has lost that revenue outright — customers with full baskets do not usually wait, they leave. Add the evening spent re-entering paper receipts, the stock counts that are now wrong, and the credit sales recorded from memory.

Then add the part that does not appear in any ledger: the customer who watched you fumble at the counter and decided the shop next door was faster.

If that happens twice a month, the annual cost is not small. It is usually larger than the entire cost of the software.

The test to apply

Before choosing any point of sale, do one thing: turn off the connection and try to use it for ten minutes. Sell something. Search the catalogue. Check a customer's balance. Take a credit payment. Run today's report.

Whatever still works is what you will have on your worst day. Everything else is a feature you only get to use when the internet cooperates — and your customers do not care whether it does.