A great deal of business software is built on an assumption that quietly fails in practice: that the network is available. For warehouse staff, delivery riders, field engineers, agricultural collection centres and retail counters, it frequently is not.
Offline-first inverts the assumption. The local store is authoritative for the user's immediate experience, and the network is a background concern.
What offline-first actually means
It is not caching. Caching makes a read-only view available when the network drops. Offline-first means the user can perform their full workflow — creating, editing and completing records — with no connection at all, and the system reconciles later.
That is a meaningfully harder problem, because it means accepting writes without server validation and resolving what happens when two devices change the same thing.
Identifiers must be generated on the device
The most common early mistake is relying on server-generated sequential ids. If a record cannot be created without a server round trip, the application is not offline-capable.
Generate identifiers client-side — UUIDs or ULIDs. ULIDs have the practical advantage of sorting chronologically, which matters more than it sounds when reconstructing an audit trail across devices.
Decide the conflict policy deliberately
Two devices will eventually edit the same record while both are offline. There is no universally correct resolution, so the policy has to be chosen per data type.
Last-write-wins is simple and acceptable for low-stakes fields. Append-only structures avoid conflict entirely and suit event capture — delivery attempts, inspection readings, stock movements. Explicit user resolution is appropriate where the data matters enough to justify interrupting someone.
What does not work is leaving it undefined, which produces silent data loss that surfaces weeks later as a reconciliation problem.
Make sync state visible
Users need to know whether their work has reached the server. Not a spinner — a clear indication of what is pending, what has synced, and what failed and needs attention.
Hiding sync state to keep the interface clean reliably backfires. A driver who cannot tell whether twenty deliveries have uploaded will re-enter them, and now you have duplicates.
Watch battery consumption
An application used all day on an inexpensive phone competes with battery life. Continuous location polling and aggressive sync intervals will drain a device by mid-afternoon, after which the app stops being used regardless of how good it is.
Tune polling frequency to what the use case genuinely requires, batch network calls, and back off aggressively when the device is idle.
Test the failure paths
Offline behaviour has to be tested in the states that actually cause trouble: partial connectivity where requests hang rather than fail, a sync interrupted halfway, a device offline for several days accumulating a large queue, and clock skew between devices.
These are where offline systems break, and they are exactly the cases that never come up in office testing on reliable WiFi.