Insights · Engineering
When the internet doesn't cooperate: offline-first systems for far-west Nepal
The short version
When people design software in Kathmandu, they design for Kathmandu's internet. Then the software goes to Kailali, or Kanchanpur, or a hill village three hours past the last tower, and the assumptions quietly fall apart. A form that needs a live connection to save is not a form in those places — it is a locked door.
We learned this early. During the Covid-19 lockdown of 2020, our founding team — then working as Promethean Technologies — was asked to move whole educational institutions in Nepal's far-west online in a matter of weeks. There was no option to wait for perfect connectivity; the work had to function in the conditions that actually existed on the ground.
Connectivity is a range, not a switch
“Has internet / has no internet” is the wrong mental model. In practice you get a spectrum: a strong connection at the district headquarters, a weak and intermittent one at the ward office, and nothing at all where a field worker is standing when they need to record something. A system that only works at the top of that range fails exactly where the real work happens.
Offline-first is an architecture, not a bolt-on
The instinct is to build an online system and later “add offline support.” It rarely works, because the hard parts — where data lives with no connection, what happens when two people edit the same record on two disconnected phones, how you reconcile it all when a signal appears — have to be designed in from the start. Offline-first means the device is the primary place data is captured, and sync is a background process that catches up when it can.
What has to be true before you can call it offline-first
The hard parts are not the cached form. They are where data lives with no connection, and what happens when two disconnected people edit the same record.
Tap any component above for its role and the real tech.
- Forgiving interface (Client, Field-worker UI): The hardest constraint is often not bandwidth — it is that the person entering data has never used a system like this. Interfaces have to be forgiving.
- Local store (Data, On-device database): Writes land here first and are treated as real, whether or not a connection exists. This is the part that cannot be bolted on later.
- Outbox queue (Queue, Durable write queue): Every change waits its turn, survives a restart, and retries — so a form submitted past the last tower is not lost.
- Sync engine (Service, Bidirectional sync): Runs when a connection appears, however briefly. Designed for a spectrum of connectivity, not an on/off switch.
- Conflict resolution (Service, Deliberate merge policy): The real test: when the same record has been touched in two places, what is the truth? A serious system has a deliberate answer, not a silent overwrite.
- Server API (API, Institution backend): Accepts reconciled writes and is never assumed reachable — the client works whether or not it answers.
- Institutional record (Data, System of record): One reconciled truth per record, arrived at on purpose rather than by whichever device happened to sync last.
Where the data actually lives when there is no signal — and what has to exist before sync can be honest.
Sync is where the honesty is
Anyone can cache a form. The real test is conflict resolution: when the same record has been touched in two places, what is the truth? A serious offline system has a deliberate answer, not a silent overwrite. If a vendor can't explain their conflict-resolution approach in plain language, they haven't built for the field.
Two ways to claim offline support
The instinct is to build an online system and later add offline support. It rarely works — and these are the questions that expose which one you have.
| Criterion | how we build it | |
|---|---|---|
| Where a write lands first | The server — the form needs a live connection | The devicetreated as real immediately |
| Past the last tower | Blocks or loses the entrythe assumption quietly fails | Keeps working; the change queues |
| Two people edit one record | Silent overwritelast write wins, invisibly | A deliberate resolution policythe honest part |
| Connectivity model | Has internet / has no internet | A spectrumstrong at HQ, intermittent at the ward, none in the field |
| Cost of getting it wrong | A rewrite — the hard parts are structural | Designed in from the first commit |
Drawn from delivering education technology into Kailali and Kanchanpur during the 2020 lockdown.
The same five questions, asked of both approaches. This is the checklist we use when a vendor says they 'support offline'.
Build for the people, not just the network
The far-west taught us that the hardest constraint often isn't bandwidth — it's that the person entering data has never used a system like this before. Interfaces have to be forgiving, training has to leave people able to operate on their own, and the goal is always to hand over something the organisation can run itself.
Frequently asked
What does offline-first actually mean?
The device is the primary place data is captured and held, and synchronisation runs as a background process that catches up when connectivity returns — so the user never waits for the network to do their job.
Why is conflict resolution important?
When the same record is edited in two disconnected places, a serious offline system has a deliberate rule for which version wins — not a silent overwrite that loses someone's fieldwork.
Want this run on your numbers?
We'll do the same analysis on one of your workflows in the two-week Automation Sprint.
Related service · Studio Engineering