Offline-First Apps for Field Teams

What offline actually means

Not caching the last screen. Offline-first means the device holds its own database, every action works against local data, and changes synchronise when a connection returns — including changes made by other people while you were away.

That last clause is where the cost lives. Everything else is straightforward.

Who genuinely needs it

• Engineers in plant rooms, basements and lift shafts
• Delivery and logistics across rural coverage
• Warehouses with poor internal signal
• Agriculture, construction, utilities, marine
• Anyone whose day fails if the app stops working for twenty minutes

The test is not whether connectivity is occasionally poor. It is whether the work stops when it is. A sales app that cannot load for a minute is annoying; an engineer who cannot close a job is stuck on site.

The conflict problem

Two people edit the same record while both are offline. Both sync. Now there are two versions and the system must choose — or ask.

1. Last write wins. Simple and silently loses data. Acceptable only for genuinely disposable fields.
2. Field-level merge. Different fields merge cleanly; the same field still conflicts.
3. Append-only. Record events rather than states. Avoids most conflicts and is our usual recommendation.
4. Ask a human. Correct, and unusable if it happens often.

Append-only design is the single most useful decision in offline apps. A job log with timestamped entries has no conflicts; a job record with an editable status field has them constantly.

Designing the data to avoid conflicts

Most conflict problems are avoidable at the modelling stage. Give each device its own lane: one engineer owns their own job entries, readings are appended rather than edited, statuses move forward through a defined sequence rather than being set arbitrarily.

• Prefer “add a reading” over “update the reading”
• Prefer state transitions with rules over free-form status fields
• Assign ownership so two people rarely edit the same record
• Keep server-authoritative anything that must be globally consistent, like stock

What the user has to see

Offline apps need honest status. The user must always know whether what they are looking at is current, and whether their work has been saved anywhere but this phone.

• A clear indicator of connection state
• How many changes are waiting to sync
• When data was last refreshed
• An explicit warning before anything that needs a connection
• Visible failure — never a silent drop

The nightmare scenario is an engineer completing forty jobs, none of which synced, and finding out on Friday. One visible counter prevents it.

What it adds to the project

Roughly 20–40% on top of the same app online-only. It is worth every day of it when the field genuinely needs it, and it is the first thing we cut when it is being requested for comfort.

Frequently asked questions