2 September 2026 · 5 min read
Connectivity is worst exactly where the work is
Field software is used in the places networks are worst: inside warehouses with metal racking, in basement service corridors, on highways between towns, in loading bays surrounded by containers.
An app that needs a live connection to record what just happened does not fail gracefully in those places. It fails at the moment of record, which is the only moment that matters, and the user falls back to paper or a phone call. The data you were trying to capture is then gone.
What offline-first actually requires
Caching data for reading is the easy half and is often mistaken for the whole. The hard half is writes: letting someone complete a task with no network and guaranteeing it lands exactly once when the network returns.
That needs a local database as the app's source of truth, an outbox that queues each completed action, and a sync process that replays the queue in order. The user interface reads from the local database, so it behaves identically online and offline — which also means there is no separate offline mode to test, because there is only one mode.
Idempotency is the part people skip
A queued action will sometimes be sent twice. The network drops after the server commits but before the response arrives; the app retries; the work is recorded again. In a stock system that produces phantom inventory, and it is very hard to detect after the fact.
The fix is that the client, not the server, generates a unique identifier for each action, and the server treats a repeat of an identifier it has already seen as a no-op that returns the original result. This has to be applied per action — per refill line, per photograph, per delivery — rather than per sync batch, because batches get split and retried in pieces.
Evidence needs care when the network is absent
Photographs are usually the largest thing a field app captures and the most awkward to sync. They should be queued alongside the action they belong to, uploaded separately from the record itself, and named by the identifier of the row they belong to rather than by a timestamp — timestamps collide, and a retry with a new name produces orphans.
It is also worth deleting local copies once upload is confirmed. Field devices are shared, sometimes lost, and often short of storage.
Why retrofitting rarely works
An online-first app makes an assumption in every screen: that data is fetched when needed and writes complete immediately. Removing that assumption touches state management, navigation, error handling and the data model, because the app now has to represent things that are done locally but not yet acknowledged.
In practice, adding offline support to an app built the other way is a rewrite wearing a smaller name. If the people using your software move around, decide this before the first screen is built.
Running into this?
We build these systems for logistics operators in India. Describe your situation and we will tell you honestly what we would do.
Start a conversation