Skip to content
Engineering

Why we built SumPOS offline-first, and what that actually means

There is a real architectural difference between a system that caches for emergencies and one where local is the default. It shows up on exactly the day you cannot afford it to.

SPThe SumPOS team · Engineering8 min

A point of sale terminal is an unusual piece of software. It is used by people under time pressure, in front of a waiting customer, often on cheap hardware, frequently in a building with unreliable connectivity - and if it hesitates for two seconds, everyone in the queue notices. These constraints push you toward a particular architecture, and it is not the one most cloud software uses.

Two ways to build the same feature list

The conventional cloud approach is server-authoritative: the client sends a request, the server decides, the client renders the answer. It is simple, consistent, and easy to reason about. It also means that every action's latency is your network's latency, and every action's availability is your network's availability.

The local-first approach inverts this. The device holds a real database. Reads are local and therefore instant. Writes are local and therefore always succeed. Synchronisation is a background process that reconciles the device with the server, rather than a precondition for anything happening at all.

Events, not overwrites

The hard part of local-first is conflict. If two tills are offline simultaneously and both sell the last unit of an item, what is the correct answer on reconnection?

If stock is stored as a number that gets overwritten, one till's update destroys the other's - you sold two units and your system recorded one. If stock movements are stored as events, both sales are recorded, the stock level is derived by replaying the events, and the result is minus one with a flagged exception. That is the honest answer: you genuinely did sell two, and someone needs to know.

So every stock-affecting action in SumPOS is an immutable, timestamped, device-identified event. Quantities are derived, never assigned. This makes reconciliation deterministic regardless of the order in which devices come back online, and it makes the audit trail a natural consequence of the design rather than a feature bolted on top.

One core, five platforms

SumPOS runs on a single shared core. The domain logic - pricing rules, tax calculation, discount eligibility, stock movement, journal entry generation, receipt formatting, the sync engine itself - is written once and compiled natively for Android, iOS, desktop and the web.

This is not a cosmetic decision. In systems where each platform reimplements business logic, the platforms drift. A discount rounds differently on the tablet than on the desktop. A tax edge case is handled on Android and missed on iOS. Those bugs are miserable to find and worse to explain to a customer, because the correct behaviour depends on which device the sale happened on.

  • Shared: domain model, pricing and tax engine, sync, persistence layer, offline queue, printing engine, validation rules.
  • Native per platform: the user interface, hardware access, platform integrations and the parts where a native experience genuinely matters.
  • Result: identical behaviour everywhere, because it is the same compiled logic - not a promise that two teams stayed in step.

Making sync legible

Sync engines fail. Networks are hostile, clocks disagree, devices get replaced mid-shift. What separates a tolerable sync engine from an intolerable one is not the failure rate - it is whether a manager can understand what is happening without calling support.

So the sync centre in SumPOS shows the queue depth per device, the last successful sync, what is pending, what failed and why, in plain language. 'Waiting for network - 14 sales queued since 3:42pm' is a sentence a shop manager can act on. An error code is not.

The trade-offs, honestly

Local-first is not free. You carry a real database on every device, which costs storage and complicates upgrades. You need a genuine migration strategy for schema changes across devices that may be weeks out of date. Some things - a group-wide stock lookup, a live consolidated dashboard - inherently need the network, and you have to be honest with users about which those are rather than pretending everything works offline.

We think the trade is obviously worth it. The alternative is a system that works beautifully except on the days when it matters most, and those are exactly the days a business remembers.

Want this handled by software rather than a spreadsheet?

SumPOS does most of what this article describes automatically - and the free plan is genuinely free, so you can test the idea before committing to anything.

Ready to see your business on one screen?

The point of sale is free forever - unlimited registers, unlimited stores, no card required. Add the back office only when you actually need it.

No card required · Free forever · No commission on your sales · Your data stays yours