Offline-first, because the network is a place not a state
Software written in a city office assumes connectivity is on or off. Software used on a collection round, at a weighbridge or in a village school meets a third state far more often: connected, technically, at a speed and reliability that makes every request a gamble.
2 min readOadbox
Three states, not two
A request that fails immediately is easy to handle. A request that hangs for forty seconds and then succeeds is what destroys a field app, because the user has already tapped again, navigated away, or concluded the app is broken.
Designing for the middle state means short timeouts, optimistic local writes, idempotent operations so a retry is safe, and a sync indicator honest enough that the user knows where they stand.
Own the conflict model before you need it
Two devices editing the same record while offline is not an edge case in field operations — it is Tuesday. Deciding what happens is a domain question, not a technical one, and it differs by record type.
- Append-only records — receipts, attendance marks — merge safely and should be modelled that way.
- Master data edits — a corrected address — take last-write-wins with a visible history.
- Stock and cash — anything with a balance — must not merge silently; queue and reconcile.
- Anything genuinely ambiguous gets surfaced to a human rather than resolved by a rule.
Sync the day, not the database
The instinct is to replicate everything. On a mid-range phone with a small data plan, that is slow, expensive and mostly wasted — a collection officer needs today's route, not the entire portfolio.
Scoping the offline working set to what the user's day requires, downloaded before they leave, is both faster and cheaper. It also bounds the conflict surface considerably.
Test on the phone people actually own
The device in a field officer's pocket is several years old, has limited storage and shares a data plan with a household. An app tested only on current hardware over office wifi has not been tested.
We keep old devices and throttled networks in the test loop for exactly this reason. It is the least glamorous part of mobile engineering and it accounts for most of the difference in whether an app is used.
Written by the Oadbox team. Something here not match how it works in your business? We would genuinely like to hear it — connect@oadbox.com.