The signal drops. The work doesn't stop.
A supervisor on a factory floor, a collection agent in a village, a waiter at the back of a busy restaurant, a delivery driver in a basement car park: all of them use apps in places where the network comes and goes. If the app freezes, shows a spinner or loses what they just typed, they stop trusting it and go back to paper.
Offline-first design treats a lost connection as normal rather than exceptional. The app keeps working, saves what people do on the device and syncs with the server when the connection returns.
What "offline-first" actually means
It doesn't mean every feature works without internet forever. It means:
- Reads come from the device first. The screen shows the latest data the phone has, immediately, then refreshes when it can.
- Writes are saved locally first. When someone records an order or a reading, it's stored on the phone at once and queued for upload.
- Sync happens in the background. When the connection returns, the queue is sent and the latest changes are pulled down.
- People can see the state. A small indicator shows what's waiting to sync, so nobody wonders whether their work was saved.
Decide what must work offline
Not everything needs to. Go screen by screen and decide:
- Must work offline: recording an order, a delivery, a collection, an attendance mark, a reading.
- Should show cached data offline: customer lists, price lists, today's tasks.
- Can require a connection: payments, reports across the whole business, admin settings.
Be explicit with users about the third group, with a clear message rather than a silent failure.
The hard part: conflicts
If two people change the same record while offline, whose change wins? There's no universal answer, but there are good patterns:
- Append rather than overwrite. Record events, such as "5 units sold", instead of totals, such as "stock is 45". Events from different phones can be combined safely.
- Last write wins, for simple fields. For things like a phone number, the most recent change is usually right.
- Ask a person, for important conflicts. When two edits genuinely clash, show both and let someone decide.
Never record the same thing twice
Weak networks often deliver a request, then fail to deliver the reply. The phone retries, and the server receives the same order twice. Give each action a unique ID created on the phone, and have the server ignore any ID it has already processed. This one habit prevents a whole category of duplicate orders, double payments and phantom stock.
Tools that help
You don't need to build sync from scratch. Mobile databases with built-in offline support, and cloud databases such as Firestore that cache data on the device and queue writes, handle much of the plumbing. For web apps, service workers can cache the app itself so it opens without a connection. What the tools can't do is decide your conflict rules or your offline scope. That's design work, and it needs to be done deliberately.
Test it like the real world
Most apps are tested on fast office Wi-Fi, which hides every one of these problems. Instead:
- Use network throttling and airplane mode in every test session.
- Switch networks mid-action, such as during a save.
- Leave a phone offline for a day of real use, then reconnect it.
- Test on the low-cost Android phones your users actually carry.
Why it's worth the effort
Offline-first takes more thought up front. But it's often the difference between software people rely on and software they work around. When the app never loses their work, people stop keeping a paper backup, and that's when the real benefits start.
Building an app for the field, the shop floor or the road? See our mobile apps service.
