What an offline-first architecture means for retail software

Retail software is often designed as if the shop were a browser tab with a reliable connection. Counters are not like that. A card machine, a barcode scanner, and a queue of people do not pause because a back-office API timed out. Offline-first means the sale is recorded on the device first, and the network is a convenience for sharing that record, not a requirement for taking it.

The device is the system of record for the shift

During a shift, the till needs a local copy of the catalogue, the prices it is allowed to charge, and the stock it believes it has. It also needs a local log of every sale, void, and return. That log is the source of truth for the shift. The server’s copy is a replica that catches up.

This is the opposite of a typical web app, where the server is the only place a write is real. If you keep that model and add a cache, you will still lose the sale when the cache cannot refresh. Offline-first turns the cache into a store with rules, not a temporary hint.

Sync is a product decision

When the connection returns, the device sends its log and receives what other branches have done. Two tills can sell the last unit of the same item. The software has to decide what that means. Common choices are: accept both sales and let stock go negative so a person can reorder, or block the second sale if the device had heard about the first. Neither choice is free. Negative stock is honest about what left the building. A hard block is kinder to the count and ruder to the customer in front of you.

Write the rule down before you build it. Include who is notified, how a supervisor corrects a duplicate, and how a purchase receipt updates the count the tills are using. If the rule only exists in code, the next branch will invent a different one.

Identity, stock, and money do not travel the same way

A product barcode can be copied to every device and updated when it changes. A staff PIN should not live in a spreadsheet on the shop floor, but the device does need to know who is allowed to discount while it is offline. That usually means a signed list of roles, with an expiry, stored on the device and refreshed when it can.

Payments are stricter. If a card is authorised by a network you do not control, you cannot invent an approval. The offline design has to say what the cashier does: take another tender, record an order to complete later, or refuse the sale. Cash and house accounts can be local. Card acquiring usually cannot. Pretending otherwise creates a reconciliation problem that finance will find at month end.

What to test before a second branch

One branch is a pilot. The tests that matter are dull:

• Unplug the network, sell three items, print or show the receipt, and reconnect. The server should show the same three lines, once.
• Sell the same item on two devices while both are offline, then reconnect. The stock figure should match the rule you wrote, and a person should be able to see both sales.
• Change a price at head office. Devices that are online should pick it up. A device that was offline should not apply the new price to a sale it already finished.
• A cashier without the supervisor role should not be able to void a sale they are not allowed to void, even with no network.

If those paths are not tested, you do not have offline-first software. You have a till that happens to have a local database.

Keep the scope smaller than the platform diagram

Teams get lost when offline-first becomes an excuse to sync every table in the business. Start with the catalogue, the shift log, and stock movements. Leave HR, marketing, and long reports on the server. A device does not need a year of history to sell a shirt this afternoon.

The point is narrow: the queue keeps moving, and the books can be explained the next morning. The network will fail on a busy day whether the diagram allowed for it or not.