Offline-first apps: designing for the India your field team actually works in

An app that works on the office Wi-Fi and fails in the field isn't finished — it's untested. Field teams work in basements and highway dead zones, on mid-range Androids with 40% battery. Offline-first isn't a feature you add; it's the architecture you start with.

The pattern that works: a local database (SQLite/Hive/Drift) as the primary read and write surface, with a background sync layer that queues changes and reconciles when connectivity returns. Every write gets a client ID and timestamp; the server, not the client, resolves conflicts by rule — last-write-wins is only safe when you've decided which fields it's safe for.

Design the sync for partial failure: a day of offline work syncing over 2 bars of signal means chunked uploads, resumable transfers and idempotent operations — the same record syncing twice must not double-count. This is unglamorous engineering that determines whether field staff trust the app in month two.

Test like the field: airplane-mode mid-form, kill the app mid-sync, let a 4-hour queue drain on a 2G connection. If your demo can't survive those three, your delivery app is a demo. The teams that do this testing ship apps field staff actually use — the others get screenshots instead of data.