Offline-first survey runner for field data collection

Field researchers, agricultural extension workers, and humanitarian data collectors regularly operate in environments with unreliable or absent connectivity. When their survey tool hits server problems — which multiple users describe happening 'several times a week' — they lose data mid-collection. One complaint is blunt: 'the offline mode is almost unusable and leads to data loss.' This isn't a Wi-Fi preference issue; it's a structural mismatch between cloud-first survey tools and environments where the network is the exception, not the rule.

The gap persists because the dominant survey vendors are built around the live, connected use case — real-time response dashboards, live audience polling, instant result displays. Offline is an afterthought bolted on because enterprise buyers asked for it, not because the product was architected around it. The result is an offline mode that stores responses locally but fails silently on sync, has no conflict resolution when a form updates mid-deployment, and provides no visibility into which devices have synced and which haven't.

What field teams actually need: survey forms that work identically offline and online with no behavioral difference, a sync queue visible to the team lead that shows exactly which devices have unsent responses and how old they are, and a branching logic engine that runs entirely on-device without phoning home. Users describe 'closing work unexpectedly' and 'freezing in the middle of use' — the kind of data loss that, in a field research context, can invalidate an entire day's work that cost hundreds of dollars to execute.

This is a business because field data collection is a recurring operational workflow — NGOs, government health programs, and agricultural survey firms run these deployments repeatedly across months or years. A failed sync doesn't just annoy someone; it corrupts a dataset that took days to collect, and the organization has to send enumerators back into the field. The cost of unreliability is concrete and measurable, which means the willingness to pay for something that genuinely works offline is real.

What to build

Build a mobile-first survey runner where all form logic, branching, and response storage run entirely on-device via SQLite, with a sync dashboard the field supervisor sees in a browser showing each enumerator device's last sync time, pending response count, and any form version conflicts — no data ever lost to a server outage.

Where to start

Start with NGOs already using KoBoToolbox or ODK who are frustrated with sync failures but don't have the internal dev capacity to self-host — they want the reliability of an offline-first architecture without the IT overhead, and they'll switch for a product that makes sync status visible.

The hard part

Form logic for serious field research — skip patterns, calculated fields, cascading dropdowns from large reference datasets — is genuinely hard to run reliably on low-end Android devices, and getting it wrong on even one question type breaks trust with buyers who've been burned before.

How it makes money

Annual license per organization, priced by number of active enumerator seats — roughly $8-15 per enumerator per month, with a flat fee for the supervisor dashboard, matching NGO procurement budget cycles.