Building Software for Farmers: What the Spec Doesn't Mention

The product was a crop advisory platform. Farmers registered their plot details, location, size, crop type, and received personalised agronomic advice based on weather data, satellite imagery, and historical yield information from comparable plots in the region. The value proposition was clear: better information leads to better decisions leads to better yields. The technology existed. The data was available. The problem was defined.

We were wrong about roughly half of what we thought we knew before the first field research trip.

The Connectivity Assumption

The application was designed as a connected app. Advice was fetched from the backend on demand. Images and charts were rendered from CDN. The assumption, made in a conference room in Pune, was that 4G coverage in rural Maharashtra was sufficient for our use case.

Coverage maps showed 4G in the areas we were targeting. What the coverage maps didn't show: the signal inside a farm building is often different from the signal at the tower, particularly for the older feature phone users who were a large part of our target audience. The signal quality at different times of day varies significantly. During the peak advisory period, morning, when farmers are making decisions about what to do that day, coverage in some areas was consistently poor because of network congestion from urban commuters in nearby towns.

More importantly: a farmer checking the advisory at 5am before going to the field, in an area with inconsistent morning coverage, doesn't wait for the app to load. They look at yesterday's advisory (if it loaded), make a decision, and go. An app that requires active connectivity to be useful is an app that is useless at the moments of highest value.

We built offline support. Not a "you're offline" message, actual offline support. The last-fetched advisory for each registered plot was stored locally. Weather forecasts were cached daily. The advisory engine was replicated on-device for the base case, fetching updates when connectivity was available and functioning autonomously when it wasn't. This added three months to the development timeline and required significant changes to the data architecture. It was not optional once we understood the usage context.

The Literacy and Language Layer

The initial design was text-heavy. Advice was delivered as paragraphs. Guidance was explained in full sentences. The interface used agricultural terminology that was accurate and specific.

Field research revealed several things we had not anticipated. Many smallholder farmers in our target region were functionally literate but not confident readers in either the official regional language or in English. Technical agricultural terms, "foliar application," "integrated pest management," "bioassay", were known to agronomists but not necessarily to the farmers they were advising. Longer text blocks were not read; farmers skimmed to the most concrete instruction.

We rebuilt the advisory delivery around three formats: a single-sentence core recommendation ("Apply 2kg/acre of urea fertiliser before the next rainfall"), a short supporting context (two to three sentences), and a voice note option that read the recommendation aloud in the local language dialect. The voice option had been considered and deprioritised in the initial roadmap as a "nice to have." It became the primary delivery mechanism for roughly 40% of users within three months of launch.

The multilingual requirement was not just translation. Agricultural advice that uses the vocabulary that farmers actually use, local names for crops and pests, local measurement units, references to locally familiar practices, is more trusted and more actionable than advice that has been technically translated but culturally transposed. We worked with local agronomists to review and localise the advisory content in each region, which added cost and time but produced advice that farmers found recognisable and actionable rather than technically correct but unfamiliar.

The Accuracy Metric Problem

We had built our quality assessment around an accuracy metric: how often did the platform's recommendations match what an expert agronomist would have recommended for the same conditions? We were hitting 78% agreement with expert review, which we considered a strong foundation.

A user researcher on the team pointed out that we were measuring the wrong thing. The question wasn't whether our recommendations matched an agronomist's recommendation in the abstract. The question was whether following our recommendations led to better outcomes for farmers, higher yields, lower pest losses, reduced input costs, compared to what they would have done without the platform.

The two metrics do not necessarily correlate. A recommendation that is technically optimal but conflicts with the farmer's experience, resource constraints, or risk tolerance will not be followed. A recommendation that is followed but is optimal for the wrong soil type produces bad outcomes despite our accuracy score. And critically: the farmers who were getting the best results from the platform were, in some cases, doing so by adapting our recommendations rather than following them literally, combining our timing advice with their own input choices, for example. That adaptation was the value, not the literal compliance with the recommendation.

We shifted our primary metric to a survey-based outcome measure: did farmers who used the platform report making different decisions than they would have without it, and did they report those decisions as beneficial? This was harder to measure and less precise than the accuracy score, but it was measuring something that mattered to the product's actual purpose.

Seasonal Data and the False Flat Period

Agricultural data has a strongly seasonal pattern. Usage spikes during the sowing period, during critical growth phases, and during harvest. Between seasons, usage drops significantly. For a product optimisation cycle based on engagement metrics, this creates a dangerous illusion: a feature that launches during the off-season and shows flat engagement isn't necessarily failing, the entire user base may be in a low-engagement period regardless of what the platform offers.

We almost deprioritised the voice note feature after its initial release showed underwhelming engagement numbers. The release had happened in December, which was post-harvest in our primary target region. Three months later, as the rabi crop sowing season began, voice note usage jumped to become the most-used feature by time-in-app. The flat December numbers were not a signal about the feature's value, they were a signal about the season.

Building product intuition in an agricultural context requires understanding the crop calendar of the specific regions you're working in and accounting for it in every measurement and interpretation. An analytics dashboard that doesn't surface the seasonal context alongside the engagement data is actively misleading for a team making product decisions in this domain.

What This Domain Is, Really

Agricultural technology is often discussed in terms of precision agriculture, satellite imagery, AI-powered yield prediction, the technology is real and interesting. What the technology discussion underweights is the human and operational complexity of deploying digital tools in a context where the users have high domain expertise (farmers who have been growing specific crops in specific soils for decades), low tolerance for tools that don't fit their actual workflow, and genuine downside risk if the advice they receive and act on is wrong.

The farmers we were building for were not unsophisticated. They were making complex decisions under uncertainty every season, with limited resources and high stakes. The platform's job was not to replace their judgment, it was to give them additional information at the right moment, in a usable format, in a way that fit their existing practices. Building software that does that well requires spending time with those users before writing much code, revisiting assumptions continuously, and treating user research findings as primary rather than anecdotal. The farmers who got the best results from the platform were the ones who found a way to integrate it into how they already worked. The platform's job was to make that integration possible.