Kheto: a fire alert is only useful if farmers believe it.
Hyperlocal fire alerts for Indian farmers, built on NASA FIRMS satellite data, live weather, and a Gemini-powered advisor. I owned everything from problem discovery to Play Store submission. Now in closed beta with 12+ active testers.
The problem
Every burning season, stubble and waste fires spread into standing crops across north India. The data to warn farmers exists (NASA's FIRMS satellites detect fires worldwide within hours), but it lives in English-language dashboards built for researchers, not for someone standing in a field deciding whether to act.
Existing weather apps treat fire as a news item, not a proximity problem. None of the five alternatives I studied could answer the only question that matters: is there a fire near my farm, right now, and what should I do about it?
The fire map: every detection within the farmer's chosen radius, updated from each satellite pass.
Defining the product
Before any code: competitive research across 5 alternatives, user personas, a full PRD, and screen-by-screen user flow mapping. Twelve candidate features went through RICE scoring; most of them lost.
The scoring forced honest answers about reach and confidence. A mandi-price tracker scored well on reach but had nothing to do with the core promise, so it went to the backlog. The personalised advisor stayed: it's the layer that turns satellite data into an action a farmer can take, in their own language.
The decision log
-
Ship the alert engine silently
The call: in MVP, the fire-risk engine logs its predictions without surfacing a single alert to users.
Why: a false alarm costs a farmer a day of panic; a missed fire costs the harvest. False negatives in fire safety destroy trust in rural communities permanently, and I had no validation dataset to know my error rate.
The silent period builds the dataset that decides when alerts are trustworthy enough to show. Trust is the product; the feature waits.
-
Inject context into the AI advisor automatically
The call: the Gemini-powered advisor receives crop type, farm location, and live fire proximity with every question; the farmer never has to explain their situation.
Why: the users I designed for won't write paragraphs of context into a chat box. If the advisor answers generically, it's a gimmick; if it knows there's a fire 8 km east, it's a tool.
A personalised farming advisor that no competing product offered at launch.
-
Language before features
The call: onboarding starts with language selection, and every surface works in the farmer's own language, before adding any secondary feature.
Why: the entire failure of existing tools is that the data never crosses the language and literacy gap. Shipping an English-first MVP would have rebuilt the same wall.
The app is usable by the actual target user, not just by reviewers on the Play console.
-
Closed beta over a public launch
The call: submit to Google Play as a closed beta with hand-recruited testers instead of going public.
Why: the alert engine's validation period (decision 01) only works if I can talk to every user when a real fire event happens and check what the app should have told them.
12+ active testers and a feedback loop tight enough to validate against real fire events.
Where it stands
- Active closed-beta testers 12+
- Features RICE-scored for MVP 12
- Alternatives studied 5
- Fire-data refresh cadence ~6 hrs
What's next
Graduate the alert engine from silent to live once the validation dataset covers a full burning season; expand the tester cohort regionally; and instrument advisor conversations to learn which questions farmers actually ask. The roadmap should come from them, not from me.