Offline-first apps: building for the network your staff actually have

Every app works in the demo. The demo is on a new phone, on office wifi, with a developer driving. None of those conditions exist when a field worker is registering a beneficiary in a village, a teacher is marking attendance in a building with thick walls, or a driver is confirming a delivery at a factory gate.

Offline capability is not a feature to add later. It is a decision about how the app stores and moves data, and retrofitting it usually means rewriting the parts that assumed a connection.

What offline-first actually means

Not "it shows a nice error when the connection drops". It means:

• **The app writes to local storage first**, always, and treats the server as something to sync with rather than something to depend on.
• **The user is never blocked** by a network call. Saving a record completes immediately.
• **Sync happens in the background** when a connection appears, without the user having to think about it.
• **The user can see** what has synced and what is still waiting, so they can trust it.

That last point is underrated. A field worker who cannot tell whether their morning's work is safe will either redo it or stop trusting the app, and both are worse than a slightly uglier interface.

The hard part: conflicts

Two people edit the same record while both are offline. Both come back online. Now what?

This is where offline-first is genuinely difficult, and where you should press a vendor hardest. There is no universal right answer, but there are reasonable strategies and they should be able to name which one they are using and why:

• **Last write wins.** Simple, and it silently loses data. Acceptable for records only one person ever touches; unacceptable for anything shared.
• **Field-level merge.** If one person changed the phone number and another the address, keep both. More work, usually correct.
• **Flag for human resolution.** For anything where a wrong automatic choice is expensive, surface the conflict to somebody.
• **Prevent it structurally.** Often the best answer — assign records so two people are not editing the same one. A design decision, not a technical one.

"We handle sync automatically" is not an answer. Ask what happens to the second person's edit, specifically.

Things that break in the field

**Storage fills up.** Cheap phones have little free space, and an app that caches without limit eventually cannot save. Cap it, and clear synced data.

**Battery.** An app that polls constantly for a connection drains a phone by midday, and a field worker with a dead phone has stopped working.

**Time.** Device clocks are wrong more often than you would expect, sometimes by days. If sync ordering depends on device timestamps, it will misbehave. Server time should be authoritative.

**App updates.** A device that has been offline for three weeks may be several versions behind. The server has to accept data from older versions, or that worker's three weeks is lost.

**Photographs.** Field apps capture images, and images are large. Compress on the device before queueing, or the first sync over a weak connection will never complete.

What to ask before signing

1. What happens if the app is offline for a week? Not an hour — a week.
2. Two users edit the same record offline. Describe exactly what happens when both sync.
3. How does the user know their data is safe?
4. How much device storage does it use, and what happens when the phone is full?
5. What is the oldest app version the server will accept data from?
6. Can I test it on the actual devices my staff use, in the actual place they work?

That last one is the real test, and it is worth insisting on before payment rather than after. Ask for a pilot with five real users, in real conditions, for two weeks. What comes back from that fortnight will tell you more than any specification document.

The cost, stated honestly

Offline-first is meaningfully more work than an online-only app — the local storage layer, the sync engine, the conflict handling and the testing are all real effort.

It is worth it when your users work where the connection is not reliable, and it is not worth it when they do not. An office application used at desks on wifi does not need it, and paying for it there is paying for complexity you will maintain forever and never use.

Decide honestly which situation you are in. The answer is usually obvious once somebody asks the question out loud.