Agritech app development: a 12-language farmer app on Google Play
Avio Kisan Setu is an Android-first agriculture product for Indian farmers — live on Google Play, shipping in twelve languages, with tutorial and scheme content that can be read aloud to someone who cannot read it. An active client engagement, and a usable example of what a first version should and should not contain.
- Our role
- Product and delivery engineering
- Sector
- Agriculture · India
- Platform
- Android, live on Google Play
- Languages
- Twelve, end to end
Public feeds, on their own schedule
- Government wholesale price data
- Weather for the farmer's own coordinates
- State and central scheme listings
Language and literacy in the data model
- Twelve languages stored per row, not per string file
- Text-to-speech for content that cannot be read
- Stale prices marked, never silently shown as current
One Android phone, often offline
- Today's rate before selling
- A personal crop register
- Which scheme applies, in their language
The feed sets the ceiling on what the app can honestly promise. Everything above is built around that constraint rather than hiding it.
Our role is operating and technical: the application code is written by the client's own engineering contributors. What the app does is keep records and deliver information — a personal crop register, live wholesale market (mandi) prices, local weather, government scheme listings and video tutorials. It sells nothing.
The hard part is not the feature list. The person holding the phone may not read the language the software was written in, may not read at all, and is on a slow connection — while the most important data source, a government price feed, is inconsistent and rate-limited. Almost every decision follows from those three facts.
Twelve languages is a data-model decision, not a translation job
Twelve languages is the requirement that gets satisfied cheaply and then costs for years. Here every piece of content carries its own translations, one row per language, read back in the language the user asked for. A thirteenth language is content entry, not a rebuild.
A missing translation is not a blank screen: the app asks for the chosen language, falls back to English, and only then says plainly that nothing exists in that language yet. Bulk machine translation refuses to run until an English original exists, so nothing is translated from a translation.
Translating the text does not reach a farmer who cannot read
A government scheme document is dense administrative prose. Translated into Odia it helps a farmer who reads Odia and does nothing for a farmer who does not read. Tutorial and scheme content is generated as audio in every language, at a deliberately slow speaking rate, because the listener has to act on what they hear.
Right-to-left layout is switched on so Urdu renders correctly rather than approximately. That switch and that speaking rate are the two smallest changes on the project, and they decide whether whole language cohorts can use the product at all.
The price feed sets what the app can honestly promise
Live wholesale prices come from the government's daily open-data feed. It is the right source and a hostile one: ten records a response, strict rate limits, prices arriving as text with separators, field names that vary between records. Reading it defensively, and stopping the crawl once there is enough, is most of the real work.
Nothing is cached locally. Prices change daily, so a farmer never sees a stale number, and every lookup costs a round-trip to the provider. There is no offline mode: the interface is bundled on the device and works without a signal, but content needs the network, and a failure says so instead of showing yesterday's price.
What transfers to your build
- If you will ever support a second language, put translation in the data model on day one. Retrofitting is the expensive part.
- Decide what a missing translation does before one is missing. An explicit fallback beats a blank screen that reads as a bug.
- Bound a crawl by what you need, not what the provider will serve. Knowing when to stop asking is the feature.
- Ship the intent register before the marketplace. Payments are not a feature; they are a second product with its own compliance surface.
Common questions
What does it take to build an agriculture app for Indian farmers?
Three constraints drive most of the cost, and none is the feature list. Language: a single-language build will not reach the audience, so translation belongs in the data model, and the layout has to handle right-to-left script for Urdu. Literacy: text alone excludes part of the user base, which makes spoken content a functional requirement. Data: the useful information comes from public sources that are slow, rate-limited and inconsistent. The rest is an ordinary Android app.
How do you get live mandi prices into an app?
The primary public source is the Government of India open-data portal's daily commodity price feed. Plan for its limits: ten records per response, strict rate limits, prices as text with thousands separators, field names that vary between records. A workable design crawls with a hard page cap, stops once it has enough distinct values, validates every field on the way in, and normalises state and district names against a list you control.
Does an agritech MVP need to work offline?
Usually not, and it is claimed far more often than it is built. Real offline support means a connectivity listener, a local cache, a write queue and a conflict policy — a subsystem with its own bugs. What rural products actually need is cheaper: bundle the interface on the device, preload one large page instead of many small ones, and distinguish a dead network from a server rejection. Add the queue when usage proves it.
Should a marketplace app launch with payments in the first version?
Rarely. Payments bring compliance, settlement, refunds, disputes and a support obligation a first version cannot absorb, and they delay the evidence you actually need: that people will use the product. A better first version captures intent — what a seller has, how much, at what price, when it is ready. When that register fills with real listings, you have both the case for building the transaction and the specification for it.
The decisions on this engagement — translation in the schema, bounded consumption of a hostile public API, and a first version that registers intent instead of processing payments — are the same ones we work through on MVP development projects.