Offline-first is a design decision, not a feature

Every field service app we have been asked to rescue failed the same way. It worked in the office, it worked in the demo, and it lost data the first time a technician walked into a plant room with no signal. The agency that built it was asked to "add offline support" and quoted a rewrite, because it was one.

What offline-first means

The app writes to a local database first, always, and syncs to the backend when it can. Not "caches some data for reading". Every job, form, photo and signature is durable on the device the moment the technician taps save, and the sync layer is responsible for getting it to the server later.

That decision shapes everything beneath it:

• Data model. Records need client-generated identifiers, timestamps from the device and a version, so the server can merge them.
• Conflict rules. What happens when a dispatcher reschedules a job while a technician is editing it offline? The rules are agreed with the business in discovery, written down and tested. Ours were: the technician wins for the job record, the dispatcher wins for the schedule.
• Sync queue. Operations queue in order, retry with backoff, and surface failures to the user in plain language rather than silently dropping.
• Photos. Stored locally, compressed, uploaded in the background, never blocking the form.

Why it cannot be added later

A read-cache app assumes the server is the source of truth and the device is a window. An offline-first app assumes the device is a source of truth and the server merges. Those are different data models, different identifiers, different APIs and different tests. Changing one into the other touches every screen.

What it costs up front

Three extra weeks on a twelve-week build, in our experience, and most of that is the conflict rules and the sync tests. The mobile estimator on our Mobile page adds it as a toggle so you can see the effect on the timeline.

What it buys

A technician who never thinks about signal. A dispatcher who sees completed jobs within minutes of the device reconnecting. And a product team that never has to write the "we lost your data" support macro.