Offline-first when your user is a barangay hall

Offline-first is usually sold as a performance feature — the app feels faster because it does not wait for the network. In a barangay hall it is not a performance feature. It is the difference between a system that gets used and one that gets quietly abandoned in week two.

The reason is not that the connectivity is bad. It is that the connectivity is intermittent, which is much worse for adoption than consistently bad.

I co-founded eSerbisyo, and most of the design below comes directly from seeing day-to-day operations where the network drops in the middle of serving an applicant and the queue does not stop. That constraint forces some narrow decisions.

Bad connectivity and intermittent connectivity are different problems

A system that is reliably slow still works. People wait. A system that works sometimes teaches people that it cannot be relied on, and the correct response to an unreliable tool is to keep a paper backup — which means the tool becomes the unofficial one. The failure is quiet: nothing breaks, the official record reverts to a notebook, and everyone agrees the software is “a bit slow.”

A good example: a clerk hits submit, the spinner runs for five seconds, the connection drops before the server responds, and there is no way to tell whether the record was created or not. If the interface gives no state, the only safe action is to re-enter everything — and after the second time, people stop trusting it.

Intermittency forces you to design for uncertainty, not speed.

What the offline path has to guarantee

Three things, and the third is the one usually missed:

1. No work is lost. A record taken offline is a record. Queuing it somewhere invisible and failing later is worse than not offering offline at all, because the user believes it is saved.
2. The user can see the state. Sync status cannot be a developer log. Someone has to be able to see what has landed, what has not, and resolve the second.
3. Offline is the default path, not an error path. If connecting is the normal case and offline is the fallback, the fallback will be neglected — because the failures only show up when nobody is looking.

These are not implementation details. They are product requirements, because the moment the software lies to the user about whether something was saved, the credibility is gone.

Connectivity is partial, not absent

Barangay halls often have signal that comes and goes by the minute. Some days it works in the window, some days only near the doorway. Some offices share the only stable connection and it saturates in the middle of the afternoon.

This means a queue forms while the connection is down, and work still has to happen. You cannot assume “we’ll wait for the network.” Instead, the application must assume the network will be unavailable for unknown intervals and return when it can without losing data.

The design consequence is simple: treat reads as best-effort with a visible staleness indicator, and treat writes as local-first, then reconciled later. This is the same posture you would take for a queue that cannot afford to stop, but it requires discipline in how the interface reports uncertainty. Not every stall is a failure, but every ambiguous stall will be treated as one unless the interface says otherwise.

Where last-write-wins stops being good enough

The standard offline strategy — each device keeps the authoritative copy until it syncs, last write wins — works when one person owns a record.

It fails the moment two people touch the same record from two devices, which in a shared office happens routinely: one clerk takes a payment offline while another updates the same ledger line. One change silently disappears.

The honest options are all more work than last-write-wins:

• Field-level merge. Detect the conflict per field rather than per record, so two people editing different fields of the same record are not a conflict.
• Explicit conflict records. Surface it as a flagged item for a human, and accept that a human resolves it. Unglamorous and correct.
• Ownership rules. Prevent the situation — one clerk owns a given record, so the conflict cannot arise. For a shared office this is usually the only one that holds up under pressure.

You cannot treat auth tokens as permanent when offline

If a session expires while the device is offline, the app still has to decide whether to show cached data. Showing private data to the wrong session is worse than showing an error, and silently downgrading permissions can be dangerous.

The rule we found that holds up is: unverified state does not become verified by absence of a network. Stale credentials mean cached public data is fine, but private data stays gated until a fresh check is possible. That preserves safety without making the system unusable during an outage.

Sync must be observable

An offline-capable system has to tell people, plainly, when they are looking at stale data and what will happen when the connection returns. Otherwise the system is lying by omission — someone makes a decision on a number that was correct an hour ago and wrong now.

The cheapest honest version is a persistent indicator of what is pending, visible without being clicked, and a record of what changed once it syncs. Queuing is only useful if the queue is visible. Pending writes that vanish into the background are indistinguishable from data loss.

Also, retries must be idempotent. If the same write is attempted twice because the first response was lost to a dropped connection, the server must recognise it as the same operation, not create a duplicate record. With limited bandwidth, retries should also back off rather than retrying immediately. This is more important than retry speed, especially when a room has only one usable signal. Where possible, do not retry large payloads at all: wait for a reconnection.

What this does not solve

Offline-first does not give you a connection. It stops the connection from being a hard requirement, which is a different and more achievable thing.

It also does not remove the process problems underneath. A clearance that needs three signatures takes three signature events whether the form is online or not. And it does not make a shared ledger merge-free — it just moves the merge decision to a time and place where a human can actually resolve it.

The goal is narrow: keep the work moving when the network will not cooperate, without losing the data that keeps the office accountable to its records. That means accepting sync as a process to manage, not a detail to sweep under the rug.