Picture a building inspector in a concrete stairwell three floors underground. They open the inspection app on their tablet, get halfway through the checklist, take four photos and press "Save". The spinner turns, and keeps turning, and then an error appears. The work is gone. They finish the job on paper and type it up back at the office.
By the usual standards that app wasn't badly built. It worked perfectly in the office where it was tested, on fast Wi-Fi. It just assumed the network would always be there, and in the field it isn't.
New Zealand makes this hard to ignore. Rural coverage gaps, farm sheds, basements, plant rooms, hospital corridors and remote sites mean a lot of real work happens where the signal is patchy at best. If your users work anywhere other than a desk, it's worth thinking about.
What offline-first means
Offline-first doesn't mean showing a friendly message when the connection drops. It's an architectural choice: the app always reads from and writes to a local database on the device, and syncs with the server in the background whenever it can.
For the user, the network drops out of the picture. "Save" saves instantly, every time, because it's saving locally. A small indicator shows whether changes have synced, and when the connection comes back the app catches up without anyone lifting a finger.
Offline-first apps also tend to be fast apps. When every read and write goes to a local database, the interface responds instantly even on a perfect connection. Some of the most admired productivity tools of recent years feel as quick as they do largely for this reason.
The building blocks
The tooling has come a long way. For web apps and progressive web apps, you start with a service worker, which caches the app so it opens without a network, and IndexedDB, the browser's built-in database, for the data. Native and cross-platform mobile apps usually use SQLite on the device. A sync layer sits on top, and that's where the real design work happens.
There's now a healthy crop of "local-first" sync engines and libraries that handle plumbing teams used to write by hand, and picking a good one saves months. No library makes the decisions below for you, though.
The hard part is conflicts
Once two devices can edit the same data while disconnected, sooner or later you'll have two versions of one record. The inspector marks an item as failed on site while the office manager moves the due date back at base. Both edits are valid, so which one wins?
There's no universal answer, just a handful of strategies, and the right one depends on the data.
Last write wins is simple and fine where only the latest value matters, like a status field. It's dangerous anywhere both edits mean something.
Field-level merging keeps both changes when one person edited the status and another edited the due date. Most real conflicts touch different fields, so this sorts out the majority on its own.
Append-only records avoid editing altogether. You add events such as "inspection item failed at 10:42" or "note added", and events from different devices merge cleanly because nothing gets overwritten.
CRDTs (conflict-free replicated data types) are data structures built so that concurrent edits always merge to the same result. They shine for collaborative text and lists, but they're often more than a business app needs.
For the odd conflict that really can't be merged, show both versions and let a person choose. Keep that rare, or people will learn to click through it without reading.
The most important design step is walking through your data model field by field and choosing a strategy for each. It's tedious, and it's what separates an offline app that works from one that quietly loses data.
Decisions people don't see coming
What lives on the device?
You can't sync the whole database to every tablet. Work out what each user needs offline, such as today's jobs, the sites in their area and the reference data for their checklists, and sync only that. It's partly about storage and partly about security. A lost device should give away as little as possible, and the local data should be encrypted.
Photos and large files
Photos are often the most valuable thing captured in the field, and the most painful to sync. Queue them separately from the structured data, upload them in the background with retries, compress them sensibly on the device, and never let one stuck upload hold up the rest of the sync.
Permissions change while you're offline
What happens if someone's access is revoked while their device is out in a paddock? The server has to re-check every synced change against current permissions instead of trusting the device, and the app needs a graceful way to tell the user that some of their changes were rejected.
Telling users the truth
People need to trust that their work is safe. A clear, calm indicator showing that everything is saved on this device, and how many changes are waiting to upload, does more for adoption than any feature. Hide the sync state and people get nervous. Make it alarming and they get anxious.
Is it worth it?
Offline-first adds real complexity, and plenty of apps don't need it. An internal dashboard used at a desk certainly doesn't. But if your users are inspectors, technicians, carers, farmers, drivers, auditors or anyone else whose workplace isn't an office, the network will let them down regularly. Designing for that from the start costs far less than retrofitting it once the paper forms have crept back in.
Planning an app for people who work in the field? We'd be glad to help you design the sync model before it turns into a problem.
