Offline-first is not an optimisation

A driver in a basement, a nurse in a ward with one bar, a surveyor in a lift. The moment an app is designed assuming a connection, it fails at exactly the point where the user most needs it to work.

This is not a performance optimisation. It changes what the application is.

The usual failure

The connection is treated as the normal case and loss of signal as an error state. So the app shows a spinner, the save fails, the user backs out, and the work happens again when they are back in range.

The person doing the work does not care about the architecture. They care that the reading they just took is not lost.

What changes when offline is the default

The device is the source of truth, temporarily. Not "a cache" — the record genuinely lives on the phone until it syncs. That reverses the usual assumption and it has to be a real decision, not a fallback path bolted on afterwards.

Conflicts are designed, not avoided. Two people cannot scan the same parcel, and two devices in a dead spot can both edit the same record. You cannot prevent that offline. You have to decide what happens: last write wins, first write wins, or a merge, or a record flagged for a human.

Most field work wants first write wins with a visible conflict list. Choosing that during design is trivial; choosing it after two devices have diverged in a warehouse is not.

The schema has to be local-first. A table that lives only on the server cannot be read offline, so queries that used to be trivial become replication logic. This is the part that decides whether offline is feasible at all, and it is invisible until you go looking for it.

Sync is a product feature, not plumbing. "Last synced 4 minutes ago, 3 pending" should be on the screen. A user who cannot see whether their work is safe will not trust the app.

The parts people forget

Battery. A sync loop that runs every thirty seconds on a device that spends all day in a pocket will be the reason the app gets uninstalled. Sync when the app is foregrounded, when it charges, and when the network changes.

Identity. An offline device needs to prove who it is when it reconnects. Tokens with long lifetimes are tempting here and are how replay attacks happen.

Conflict visibility to the user. A record silently reconciled by a server rule is a record somebody will later say was wrong, and they will be right to say it.

When you do not need it

If the app is used at a desk, or the data is short-lived enough that losing it is acceptable, offline-first is a large amount of complexity for no benefit. We will say so.

But if the users are in places where signal is genuinely unreliable, then the question is not whether to build for offline. It is whether the current app is quietly losing your users' work when the signal drops. That is worth measuring before anything is designed.

The test

Point the app at a building with no signal and watch someone use it for ten minutes. Whatever happens in those ten minutes is the honest state of your mobile product.