Offline-first as the premise, not as a degraded mode
Disaster software gets used hardest when the infrastructure is worst. If offline is only a fallback, the app is unavailable exactly when the data matters most.
Decision
Save to the phone first and merge on sync. The network is optional.
- Domain
- Mobile & edge
- Period
- 2018
- System
- Tanggap Bencana
Context
Tanggap Bencana was built in the weeks after the 2018 Lombok earthquake. Volunteers walked into shelters and recorded how many families were there, how many children, and what they were short of — so relief could reach the worst-off shelter first rather than the most reachable one.
Problem
The network goes down in exactly the places and hours where the data matters most. If you build assuming a connection and treat offline as the exception, the app is unavailable during the event it was built for.
Constraints
- Capture happens on a phone with no signal, and must survive until sync.
- Many volunteers collect independently; two can reach the same shelter.
- Someone moves physical supplies on the strength of this data, so it has to be trustworthy, not merely present.
Decision
Turn the default around. Saving to the phone is the normal path and always works. Syncing happens later in the background, and is never required in order to record something. When two volunteers file conflicting reports on the same shelter, that is a case the system has to handle on purpose — not a duplicate to quietly drop.
Alternatives
Trade-offs
Local-first means the overall picture is always slightly behind, and that merging conflicting reports becomes something users see rather than hidden plumbing. The alternative is a perfectly consistent view that is unavailable when you need it, which is worse here.
Outcome
Shelter data was captured in the field without connectivity and mapped for relief prioritisation. The work was later carried forward as Peta Bencana.