Blog · DEC 5, 2023 · 4 min read

Designing Offline-First Software for Tier-3 India

In Tier-3 India, treating connectivity as guaranteed is the single most common design mistake in field software, and it's avoidable.

By Team Medismo•Engineering

Software teams building for Indian field users tend to design for the network they have in their own office: fast, stable, always on. Then they ship to a rep working a Tier-3 district where 4G coverage is intermittent, and wonder why adoption stalls in exactly the territories that matter most for coverage.

What "offline-first" actually requires

Offline-first isn't a feature toggle bolted onto an existing app, it's an architectural decision made before the first screen is designed. It means every write happens to a local store first, with sync as a background concern rather than a blocking one. It means conflict resolution is designed deliberately, last-write-wins is rarely correct for something like inventory or call logs, rather than left to whatever the database default does. It means the app has to be honest, visually, about what's synced and what's pending, so a user isn't left guessing whether their work actually saved.

The mistakes that show up repeatedly

  • •Blocking form submission on a live network call, so the entire entry is lost if the connection drops mid-save
  • •Treating "offline mode" as a degraded read-only state instead of a fully functional one
  • •Syncing large media, photos, signatures, synchronously instead of queuing them for background upload
  • •No visible indicator of sync status, so users can't tell if their data actually reached the server
  • •Assuming device clocks are reliable enough for conflict resolution, they frequently aren't, especially on older Android devices common in field kits

Why this matters more in India than most markets

Roughly a third of India's mobile data traffic still runs on 3G-equivalent speeds or worse in non-metro geographies, and battery-saving behavior on budget Android devices aggressively kills background processes, including sync services, unless an app is explicitly built to survive it. A product that works flawlessly in a Bangalore office and falls over in a Bharuch taluka isn't an edge case away from working, it was designed for the wrong environment from the start. Fixing that after launch is a rewrite, not a patch.

offline-firsttier3mobile