Offline-first field apps for inspectors and frontline teams
Inspection, enforcement, and maintenance teams work in basements, on sites, and at borders where connectivity is unreliable. Apps that assume a network fail exactly when the work matters. Offline-first is an architecture, and it changes the data model.
The field apps we build for regulators and operators have one thing in common: the user is somewhere the network is bad. A plant room, a construction site, a vehicle on a highway, a border post. An app that shows a spinner in those places is not a productivity tool; it is a reason to go back to paper. Offline-first is the requirement, and it has consequences all the way down to the data model.
Offline-first is not a cache
A cache makes reads work offline. Field work is mostly writes: an inspection with photographs, measurements, signatures, and a decision, captured over hours and submitted when connectivity returns. The app has to be the system of record while it is offline, and the server has to reconcile when it comes back.
That means a local database with a schema, not a key-value cache; a sync engine with a queue of pending changes; and an honest answer to the question of what happens when two people edit the same record.
Design the conflicts, do not hope
Most field data is append-only and conflict-free by construction: a new inspection, a new photo, a new note. Design the model so that the majority of writes look like that. For the small set of records that are genuinely shared and editable, choose a rule (last writer wins, field-level merge, or human resolution) and make it visible in the interface.
Silent conflict resolution is the most common source of lost data in the field apps we have been asked to rescue.
Media is the hard part
Photographs and video are most of the bytes. Compress on the device, upload in the background with resumable transfers, and never block the submission of the structured record on the media finishing. The inspector's decision should be on the server the moment there is signal; the photos can follow.
Show the state honestly: what is saved locally, what is synced, what failed. Field users forgive slow sync. They do not forgive uncertainty about whether their work is safe.
Identity, devices, and lost phones
Devices get lost, shared, and replaced. Data at rest is encrypted, sessions expire without the network, and remote wipe is a feature of the first release, not a later one. Where the client has mobile device management, integrate with it; where they do not, the app carries its own controls.
Authentication has to work offline too: cached credentials with a bounded validity, and a clear re-authentication path when the device has been offline longer than policy allows.
Native, cross-platform, and the field
We choose the stack per programme. Cross-platform frameworks are mature enough for most inspection and case-capture work and roughly halve the maintenance cost. Hardware integration (barcode scanners, thermal cameras, rugged devices with their own SDKs) still tips some programmes native.
What we tell clients: pilot on the worst site, not at head office. If the app works in the basement, it works everywhere.
Where we apply this in practice
Working on this in your own organisation?
If any of this maps to a programme you are running, we would be glad to compare notes.