Dhruv Koladiya
A field-service app we built a while back — technicians logging job completions, capturing photos, and updating inventory from customer sites — taught us more about offline-first design than any amount of reading on the subject had. The client's technicians work in basements, rural areas, and buildings with poor signal constantly, and an app that assumed a stable connection was going to fail them daily, not occasionally.
The mindset shift that actually mattered
The real change wasn't a specific technical trick — it was treating “no connection” as the normal case to design for, and “connected” as the bonus state, rather than the other way around. Every feature got designed to work fully against local, on-device data first, with syncing to the server happening whenever a connection became available, rather than every action requiring a live round trip to a server that might not be reachable.
That meant rethinking data structure early — the app needed a local database that mirrored what the server held, with a clear, deterministic sync process for reconciling changes made offline against whatever had changed on the server in the meantime. Getting that reconciliation logic right, especially for cases where the same job got updated both offline on the device and separately in the office system, took real design work upfront that a connection-always-available app would never have needed.
What broke before we got it right
Our first version handled the common case fine but fell apart on edge cases — a technician who went offline mid-job, made several updates, then came back online to find a conflicting update had been made from the office in the meantime. The app needed to surface that conflict clearly rather than silently picking one version and discarding the other, because silently discarding a technician's offline work is exactly the kind of trust-breaking bug that makes field staff stop trusting the tool.
We ended up building a simple, visible conflict-resolution flow — flagging conflicting updates for a quick manual review rather than trying to auto-resolve every case cleverly. It's a less elegant solution than a fully automated merge would be, but it's far more trustworthy, and trust from the people actually using the app in the field turned out to matter more than technical elegance.
What we build differently now
Every field-facing app we build since starts with the offline data model and sync strategy as one of the first design decisions, not something bolted on after the online version works. It's more upfront effort, but it's far cheaper than retrofitting offline support into an app that was built assuming a live connection — which is close to what we had to do the first time, and it cost weeks we wouldn't have needed to spend with the right starting assumption.
