Offline-first apps: what it actually takes

Field software runs where the internet does not: loading bays, rural routes, cold stores, lift shafts, the inside of a container. An app that assumes a connection fails precisely where the work happens.

Offline-first is not a feature you add. It is a decision about where the truth lives, and it shapes everything above it.

The device becomes the source of truth

In a connected app the server is authoritative and the device is a window onto it. Offline-first inverts that: the device holds a real local database, works entirely against it, and reconciles later.

Everything hard about this follows from that inversion.

You need a conflict rule, and it is a business decision

Two people edit the same record while both are offline. When they reconnect, something has to decide what is true.

• Last write wins — simple, and quietly loses data.
• First write wins — safe, and frustrating for whoever was second.
• Merge by field — better, only works when fields are genuinely independent.
• Flag for a human — correct for anything involving money or safety, and needs somewhere for it to surface.

This is not a technical preference. Whoever owns the process should decide it, because the right answer differs for a delivery signature and a stock count.

Queue actions, not state

Syncing final state loses information. Recording that a driver *marked a parcel delivered at 14:32* survives reordering and replay far better than syncing that the parcel's status is now "delivered".

It also means a failed sync can retry safely, which is the difference between a robust app and one that duplicates records after a bad signal.

Partial connectivity is worse than none

The genuinely nasty case is not being offline — it is a connection that technically exists and drops mid-request. Requests time out after succeeding on the server, retries duplicate, the app cannot tell what landed.

Every write needs to be safe to send twice. That means an idempotency key generated on the device, so the server recognises a repeat rather than creating a second record.

The things that get forgotten

• Battery. Constant GPS and chatty sync are a real operational cost for a driver on a ten-hour shift.
• Storage limits. A device holding months of photos will fill up.
• Schema changes. The app must handle data written by a version from before the last update.
• Login expiry. An auth token that expires offline can lock someone out of their own job.

What it costs

Offline-first is the single largest multiplier in mobile scope. Designed in from the start it is a known and manageable cost; added to an app that assumed connectivity, it is a rewrite of the data layer and most of the logic above it.

This is why it belongs in the first conversation. More on the sector where it matters most on our logistics page, and on what it does to a budget in our mobile app cost breakdown.

What does offline-first actually mean?

That the device holds a real local database, works entirely against it, and reconciles with the server later — inverting the usual arrangement where the server is authoritative and the device is a window onto it. Everything difficult about offline-first follows from that inversion, particularly deciding what is true when two devices disagree.

How much does offline support add to an app build?

It is the single largest multiplier in mobile scope. Designed in from the start it is a known and manageable cost; added to an app that assumed connectivity it is a rewrite of the data layer and most of the logic above it. That is why it belongs in the first scoping conversation rather than being discovered in month three.