Why business records should work offline first

The places where records actually get created — a basement meter room, a warehouse aisle, a site with one bar of signal and a concrete roof — are the places where connectivity is worst. Most business apps respond to that by refusing to work.

What “offline first” actually means

The phrase gets used loosely, so it is worth pinning down. There are three broad designs, and only the third one is what people mean when they say offline first.

• Online only. Every read and every write goes to a server. Lose the connection and the app shows a spinner, an error, or a blank screen. Most web-based tools opened in a phone browser behave this way.
• Offline reading.The app caches what you have already opened, so you can look at it later. Useful, but you still cannot change anything. This is where a lot of apps that advertise “offline support” stop.
• Offline first.The local copy is the app’s source of truth while you are using it. Reads come from it, writes go to it, and a background process reconciles it with the server whenever a connection exists. The network is treated as an optimisation, not a prerequisite.

The distinction matters because only the third design lets you finish a job. The first two turn a phone into a very expensive notebook the moment you walk indoors.

The thing that makes it work: a write queue

An offline-first app does not send your edit to the server. It writes the edit locally, appends a record of it to a queue, and returns immediately. The UI updates because the local data changed, not because a server said it was fine.

Later — seconds later, or the next morning — a sync process walks that queue and replays it against the server. If it succeeds, the entry is dropped. If the connection dies halfway, the remaining entries stay put and are retried.

Three properties follow from that design, and they are the ones worth checking for:

• Writes never block the interface. If tapping a cell ever produces a loading state, the app is not queueing — it is waiting.
• The queue survives the app closing. Battery dies mid-inventory, you charge the phone, you open the app, your edits are still pending and still yours.
• You can see what is outstanding. An honest offline app tells you how many changes have not reached the server yet. An app that hides this is asking you to trust it blindly.

The hard part: two people, one row

Queueing is straightforward when one person is editing. It gets interesting when two people edit the same record while both are offline, and both queues arrive at the server later.

The lazy answer is last-write-wins on the whole record. Whoever syncs second overwrites everything the first person did, including fields they never touched. It is simple to build and it quietly destroys work.

The better answer is to make the unit of a write as small as the unit of an edit. If your colleague changed the Status column and you changed the Notes column on the same row, those are two independent writes to two different cells. Both land. Nothing is lost, and no one has to arbitrate a conflict that never really existed.

This is why cell-level writes are worth asking about specifically. “We support collaboration” tells you nothing. “Two people editing different columns of the same row do not overwrite each other” tells you the shape of the data model.

Five questions to ask before you rely on an app

1. Turn on aeroplane mode and try to create something new. Not edit — create. Plenty of apps let you change a cached record but cannot make a new one without asking a server for an ID.
2. Force-close the app with unsynced changes, then reopen it. The pending edits should still be there.
3. Check whether the app tells you what is pending. A count, a badge, a list — anything other than silence.
4. Ask what happens on a partial sync. Half the queue uploads, then the signal drops. The remaining half must survive.
5. Ask what the unit of a write is.Whole document, whole row, or single cell. It determines how much of your colleague’s work you can accidentally erase.

The honest trade-off

Offline first is not free. Data lives on the device, which means the device matters: a lost phone with a full local copy is a bigger problem than a lost phone that was only ever a window onto a server. It also means the app is bigger and does more work on your hardware.

The mitigation is access control that is enforced where the data lives, not only in the interface — so a revoked share disappears from someone’s offline copy at their next sync rather than lingering forever. That is a database-level concern, and it is worth asking any vendor how they handle it.

For work that happens away from a desk, the trade is usually worth making. An app that works everywhere except where you need it is not a tool. It is a liability with a subscription.