Offline-first apps: the architecture decision that matters more than the framework

Clients spend a lot of time choosing between Flutter and native, and almost none asking a question that changes the architecture far more: what should the app do when there is no signal?

For a consumer app used on sofas, the answer is “show a spinner”. For a field sales app, a badge scanner at a trade show, a workshop tracker or a delivery app, the answer decides whether the product works at all.

What “offline-first” actually means

It does not mean “cache the last screen”. It means the app is designed so that the device is the primary place where work happens, and the server is where that work is synchronised to when a connection exists. Concretely:

• Every write succeeds immediately on the device. Adding a lead, scanning a badge, recording a measurement — none of these wait for the network.
• Reads come from a local database, not from an API call. The app is fast everywhere because it never waits for a round-trip to show you your own data.
• Sync runs in the background, retries on failure, and survives the app being killed.
• Conflicts have a rule. Two people edit the same record while offline; something has to decide. “Last write wins” is fine for some fields and disastrous for others (stock counts, say). The rule is written down per field, not discovered in production.

Why it has to be decided first

An online-only app is a thin skin over an API. An offline-first app has a local database, a sync engine, and a server that can accept changes out of order and resolve them. Adding that to an existing app means rewriting most of the data layer — in our experience, it costs more than building it that way from the start would have.

The reverse is cheap. An offline-first app works beautifully online; it is simply faster.

What it changes on the server

The backend needs to think in terms of changes rather than snapshots: accept a batch of operations with timestamps, apply them in order, detect conflicts, and tell the client what the resolved state is. Identifiers are generated on the device, not by the database, so records can be created without asking the server for an ID. None of this is exotic, but it is different, and it is far easier when the API is designed for it than bolted on.

Signs you need it

• Your users work somewhere with bad or metered connectivity: venues, sites, vehicles, rural areas, abroad.
• A failed save costs real money or real embarrassment — a lost lead at an exhibition, a missed scan in a warehouse.
• The app is used in short bursts throughout the day, where waiting for a spinner would be the whole experience.
• Users are on company devices with no data plan, syncing on Wi-Fi at the end of a shift.

Signs you don’t

• It is a consumer app for browsing content that changes constantly.
• Every action needs a live answer from somewhere else (payments, availability checks).
• Your users are at desks on office Wi-Fi.

If you are in the first list, say so in the first conversation. It is the single most useful sentence a client can put in a brief, and it changes the plan we come back with.