Offline-first is an architecture, not a feature
Treating connectivity loss as a degraded mode produces software that works in the office and fails in the field. We learned this the expensive way.
Priya Raman
Principal Engineer, Mobile
On a fleet logistics engagement we shipped a driver app that tested beautifully and failed in production within a week. The problem wasn't a bug. It was an assumption baked into the architecture: that connectivity was normal and its absence was an exception.
Degraded mode is a trap
The intuitive design treats offline as a state you fall into. The app is online; if the network drops, you enter offline mode, queue writes, and reconcile on reconnect.
This works when disconnection is rare and brief. It fails badly when disconnection is routine — and for anyone working in a vehicle, a warehouse, a basement, or rural terrain, it is routine. Our connectivity survey across two hundred lanes found stretches where drivers were offline for forty minutes at a time, several times a day.
In degraded-mode designs, every one of those transitions is a chance for state to diverge. The queue grows, reconciliation gets more complex, and eventually a conflict resolves the wrong way and a driver loses their proof of delivery.
Inverting the assumption
The rewrite inverted it. The local store became the source of truth for anything the user did. The app never waits on the network to proceed. Sync is a background reconciliation between two authoritative stores, not a restoration of normal operation.
This changes the conflict question from 'how do we recover' to 'who wins.' And that question has domain-specific answers you can actually reason about: a driver's proof-of-delivery capture always wins, because the driver was physically there. Dispatch's route assignment wins, because dispatch has network-wide information the driver doesn't.
The cost
It's more work. You need a real local database, a sync protocol with explicit conflict semantics, and a testing approach that exercises partition scenarios rather than assuming them away.
You also need to design the interface for it. Our first version showed an alarming offline banner, which caused drivers to stop and troubleshoot mid-route. The app worked fine offline; it just said so in a way that implied it didn't. A quiet indicator replaced it.
The test that matters
If you're building for the field, test on a device in airplane mode for the whole session — not toggled mid-session. If the app is unusable, you've built degraded mode, and it will fail in exactly the conditions your users spend their day in.