The connectivity assumption is easy to make in an office, by people who have never lost signal while holding a clipboard in one hand.
An operational system is judged by its worst moment, not its best. The worst moment for field software is not a complicated workflow or an awkward form. It is a technician standing at a wellhead, far from the nearest signal, holding a device that has decided it cannot help.
What happens next is predictable: the technician writes on paper, intending to enter it later. Later is the end of a long shift. Some of it gets entered. Some of it gets entered wrong. Some of it does not get entered at all. Before long the organization has an expensive system and a parallel paper process, and nobody can say with confidence which of the two is authoritative.
Offline-first is not a synchronization strategy
The phrase is easy to hear as a technical detail — something about caching, or a queue, or a retry policy. It is not. It is a decision about where the authoritative copy of the day lives.
In a connected-first system the server holds the truth and the device holds a view of it. In an offline-first system the device holds the day and the server receives it. Everything else follows from that choice: what identifiers look like, how conflicts are resolved, what a partially completed report means, whether a permit can be consumed without confirmation, and what the technician is allowed to do when the last known state is hours old.
These are not questions that can be retrofitted. A system built connected-first and later given a cache produces something worse than either: an application that appears to work offline and silently loses a subset of the work. That failure mode is harder to detect than an outright refusal, and considerably more damaging, because it erodes trust in the data rather than in the software.
What we learned building it
OPS, the field operations product we are developing in-house, is offline-first — and not because it was specified that way at the outset. It was specified that way after the first crew to use a prototype lost signal, and the design assumption that had felt reasonable in an office stopped being reasonable.
The version now in development carries the day on the device. A technician receives their route, works the interventions, attaches photographs taken on site, and signs the daily report where the work happened. Nothing waits for coverage. The queue drains when the network returns, and the screens make the state of that queue visible rather than hiding it, because a person who cannot see whether their work has been sent will send it again.
OPS is in development. The screens shown across this site carry demonstration data. What is transferable is not the product — it is the sequence: the connectivity assumption should be tested against the worst place the work happens, and it should be tested before the architecture is fixed rather than after.
A question worth asking before procurement
When evaluating any operational system, ask the supplier to describe precisely what a user can and cannot do with no network, and what happens to work completed in that state. Ask what the user is shown. Ask how a conflict is resolved when two people edited the same record from two different dead zones.
The answers separate systems designed for the field from systems designed for a desk and then carried outside. There is no shame in the second — plenty of good software is meant for a desk. The failure is buying one and deploying it as the other.
Recalibre · OPS is in development. Every screen shown carries demonstration data.
