Building Seed Track: Designing for Villages with No Network

Seed companies run production through networks of contracted growers. Field officers visit those growers to check sowing, isolation, crop stages and harvest. Much of this was recorded in notebooks and typed into spreadsheets later — if at all.

When we set out to build Seed Track, our first step was to spend time with field officers in their working day. This is what we learned, and how it shaped the product.

What the field taught us

• Network coverage disappears exactly where the work is.
• Officers visit many fields a day, often on two-wheelers, with a phone as their only tool.
• Farm boundaries are irregular, and walking every one is not always possible.
• Managers struggle to verify which visits actually happened, and when.
• Growers are wary of how their information will be used.

Decision 1: Offline-first, not offline-tolerant

An app that ‘handles’ being offline is different from one designed to work offline by default. We store data in an encrypted local database on the phone, let every workflow complete without a connection, and sync in the background when coverage returns. Conflicts — two edits to the same grower record — are flagged for review on the web portal rather than silently overwritten.

Decision 2: Three ways to map a field

Area is calculated from the final boundary, and the method used is stored with the record so managers know how it was captured.

Decision 3: Verification without suspicion

Every visit carries GPS location, a server-verified timestamp after sync, and photos taken in the app at the time of the visit. Managers can see visit coverage by officer and area. We designed this so it supports good officers — showing their effort — rather than feeling like surveillance.

Decision 4: Consent in the grower’s language

Onboarding includes a clear notice, shown or read out in the local language, explaining what is collected and why. Consent is recorded on the device. Optional fields such as government ID numbers are only collected if the company needs them, and are masked on screen.

Decision 5: The web portal is for decisions

Officers capture; managers decide. The portal shows programme progress, fields lagging behind expected crop stage, isolation risks, pending visits and seed distribution — so attention goes where it is needed.

Sync is a product feature, not plumbing

Early prototypes treated sync as something that should be invisible. Field officers told us otherwise. They wanted to know, at a glance, what had been uploaded and what had not, because their manager would ask. So sync status became a visible part of the app: a count of pending records, the time of the last successful sync and a clear warning if something failed.

We also learned to sync in small pieces, photos last, so that critical records get through on weak connections even when large images cannot.

Designing for low-end phones and harsh conditions

• High-contrast screens readable in direct sunlight.
• Large touch targets that work with dusty or wet fingers.
• Photos compressed on the device before upload.
• Minimal typing: pick-lists, defaults and voice-friendly fields.
• Battery-aware GPS use during long walks.

What changed for managers

The biggest shift was not the app itself but the conversation it enabled. Instead of asking officers whether they had visited a list of growers, managers could see which fields were behind their expected crop stage and which had not been visited recently, and plan the week from that. Officers, in turn, could show their work with evidence. Field operations moved from reporting activity to managing outcomes.

What we would tell anyone building field software

• Ride along for a full day before writing requirements.
• Test on low-end phones with full sun on the screen.
• Minimise typing; use pick-lists, photos and GPS.
• Make sync status obvious, always.
• Plan for officers changing territories and phones.