The short answer
Offline is not a feature you add. It is a decision about where data lives, made on day one. Retrofitting it later usually means rebuilding the data layer, which is why it costs so much more after the fact.
The difference between the two designs
| Online-first | Offline-first | |
|---|---|---|
| Where data lives | On a server; the device is a window | On the device; the server is a copy |
| With no signal | The app does not work | The app works |
| When signal returns | Nothing to do | Sync, and resolve any conflicts |
| Complexity | Lower | Higher, in a specific place |
| Retrofitting | n/a | Effectively a rebuild of the data layer |
What has to be decided upfront
What must work offline. Not everything needs to. Capturing a delivery does. Browsing last year's invoices does not.
How long offline can last. An hour in a basement is different from three days on a rural route.
What happens on conflict. Two people edit the same record while both offline. Most field operations can safely use last-write-wins because two people rarely touch the same job. Where that is not safe, you need an explicit rule, and it is a business decision rather than a technical one.
What the user sees. People need to know their work is saved locally and has not yet reached the server. Silent queuing feels like data loss.
Questions to ask any supplier
Ask these before you commit
- What happens if the app is closed before sync completes?The answer should be that nothing is lost.
- What happens if the same record is edited twice offline?
- How does the user know something is queued?
- How long can a device stay offline before it becomes a problem?
- What does the battery cost of this look like over a ten-hour shift?
A supplier who has built for field teams will have answers ready. One who has not will say "it caches", which is not an answer.
The mistake to avoid
Common questions
Does offline support cost more?
It costs more than not doing it, and far less than retrofitting it later. Offline changes how data is stored and how conflicts are resolved, which is architectural. Decide on day one, not in month three.
What happens if two people edit the same thing offline?
That is the hard part, and the honest answer depends on your data. Most field operations can use last-write-wins because two people rarely touch the same job. Where they might, you need an explicit rule, decided by you rather than by the software.
How do I know if my app needs it?
If anyone will use it somewhere with unreliable signal, and losing their input would matter, it needs it. Basements, steel-framed buildings, rural routes, warehouses, and underground loading bays all qualify.