There is a particular kind of software failure that only happens in the field. The app works in the office, works in the yard, works on the drive out, and then stops being useful at exactly the moment somebody needs it — standing in a cutting, in the rain, with a check sheet to complete and no signal.
The usual response is to add an offline mode. That rarely works, because offline-first is not a feature. It is a decision about where the truth lives, and it has consequences all the way down.
Connected-first and offline-first are different architectures
A connected-first app treats the server as the source of truth. The device asks questions and displays answers. Losing the network means losing the ability to answer, so the app degrades into a spinner.
An offline-first app treats the device as a source of truth, and the server as somewhere changes are eventually reconciled. The device can create records, edit them, and show a coherent view of the world without asking anyone’s permission.
You cannot convert one into the other late in a project. The data model, the identifiers, the validation and the interface all encode the assumption.
The four decisions that have to be made early
1. Where identifiers come from. If the server allocates record IDs, a device offline cannot create a record. Identifiers have to be generated on the device and be safe to merge — which in practice means they cannot be sequential.
2. What a conflict is, and who wins. Two people can edit the same record from different sites. Some conflicts are genuine and need a person; most are not and need a rule. Deciding this per record type, early, avoids a sync layer that asks the user questions they cannot answer.
3. What must be validated on the device. Anything the server would have rejected has to be caught before the record is accepted locally, or the operative finds out days later that the form they completed was invalid. That means the validation rules live in a shared place rather than only in the API.
4. What “done” means to the user. This is the one most often missed. If the person on site cannot tell whether their work is safely captured, they will either redo it or assume it worked when it did not. The interface has to be honest about the difference between saved here and synced.
The interface constraints are unforgiving
Field software is used in conditions office software never encounters:
- In gloves, which sets a floor on target size that no design system anticipates.
- In direct sun, which rules out low-contrast interfaces entirely.
- One-handed, because the other hand is holding something.
- Under time pressure, competing directly with starting the job.
Every one of those pushes in the same direction: fewer fields, larger targets, higher contrast, and no interaction that depends on precision. A form that takes ninety seconds in an office takes four minutes on a windy embankment, and a form that takes four minutes gets completed at the end of the week from memory.
That last failure is the expensive one, because the result looks like data. It passes validation, it populates reports, and it is wrong.
Sync is a user experience problem, not just a technical one
The technical part of sync — queueing changes, retrying, resolving conflicts — is well understood. The part that determines whether the software is trusted is what the person sees while it happens.
A few things that matter more than they sound:
- Show the queue. People trust a number more than a spinner.
- Never lose a record silently. If something cannot sync, say so, and keep it.
- Make sync survive the app being closed, because it will be closed.
- Do not block the next task on the last one syncing.
Get these wrong and people work around the app: photographs taken separately “just in case”, paper kept in parallel, records re-entered later. The software then costs more than the process it replaced.
Where we have done this
ECS Group Command captures site packs, briefings, check sheets, plant inspections and site diaries once, on a phone, offline where there is no coverage, syncing when signal returns. Structured forms are generated from JSON Schema templates, photographs and sign-off are captured in place, and the quality record assembles itself rather than being reconstructed at the office.
The measure of success is not that the app has an offline mode. It is that nobody on site thinks about connectivity at all.
Building something that has to work away from a desk? Get in touch, or see how we approach rail and infrastructure work.