Blog · FEB 5, 2025 · 3 min read

Building Offline-First From Day One, Not as an Afterthought

Half of India's pharma territories don't have reliable data, so FieldVoice had to work with zero bars, not just weak ones.

By Team Medismo•Engineering

Somewhere around week four of scoping FieldVoice's architecture, we made a decision that shaped almost everything after it: the product would be designed offline-first, with connectivity treated as a bonus state rather than the default assumption. Most enterprise software gets this backwards, build for the connected case, then patch in a "works offline" mode later that is really just a longer loading spinner and a promise to sync eventually.

Why retrofitting offline support doesn't work

We looked hard at that retrofit path before rejecting it. The problem is architectural, not cosmetic. An app designed assuming a live connection tends to treat the server as the source of truth for everything, validation rules, reference data, even basic state, which means the moment connectivity drops, large parts of the app simply stop functioning correctly, or worse, fail silently and lose the input. Bolting "offline mode" onto that later means rebuilding the data layer anyway, just with more existing code to work around.

So we started from the constraint instead. A field rep's day in a large share of Indian territories, rural UP, parts of Bihar, hill districts, even patchy pockets inside otherwise well-connected states, includes stretches of zero or unreliable signal that can run for hours. Any assumption that connectivity is available at the moment a rep wants to log a visit is an assumption that will fail regularly, not occasionally.

  • •Voice capture and local transcription happen entirely on-device, no network required
  • •Structured data extraction runs against a local model first, refined against the server copy once connectivity returns
  • •Every record gets a durable local identity the moment it's created, so a sync conflict later is a merge, never a loss

The engineering cost of this decision is real. Conflict resolution when the same record gets edited both offline and by a sync-in-progress server copy is genuinely hard, and we have rewritten that logic more than once. But the alternative, a rep standing in a clinic with no signal, watching a spinning icon, unsure if the visit they just described was captured at all, was never acceptable to us as a starting point.

Offline-first is not a feature we plan to add once the core product is stable. It is the assumption everything else in FieldVoice's architecture had to be built to survive, because the alternative treats a rep's actual working conditions as an edge case, when for a large share of the field force, it is simply Tuesday.

offline-firstfieldvoiceengineering