Building field software for places with no signal

NGO field officers, distribution delivery staff and rural health workers share a problem that office software never has to solve: the network is not there when the work happens.

Retrofitting offline support into an app built for connectivity is close to a rewrite. It has to be decided at the start.

In an offline-first design the app writes to a local database first and treats the server as something it eventually reconciles with. The user never waits for a request, because no request is on the critical path.

This inverts the usual assumption, which is why it cannot be bolted on: every screen, every validation and every ID strategy is affected.

Server-generated sequential IDs break immediately — two officers offline will both be assigned the same next number. Records need client-generated identifiers that cannot collide, assigned at creation, with the server accepting rather than issuing them.

When two people edit the same record offline, something must decide the winner. Last-write-wins is simple and occasionally wrong in ways that matter — a corrected beneficiary record silently overwritten by a stale one.

We surface the rule to the client rather than choosing silently, because the right answer depends on what the record is. For beneficiary data we usually keep both and flag for review; for stock counts, the later physical count wins.

The failure mode we see most is software tested only on a good connection, with offline handling assumed to work. Airplane mode should be part of the standard test pass, including sync after an extended offline period with a large queue.