Rhythm Jain.
← All work

Kheto: a fire alert is only useful if farmers believe it.

Indian farmers get fire alerts at the state level — a blaze 3 km away looks identical to one 80 km off. So they panic at everything, or stop trusting alerts entirely. I owned Kheto end to end: problem discovery, competitive research across five alternatives, the PRD, every scope call, and the build itself. Now in closed beta on Google Play, where I recruit and talk to testers to validate it against real fire events — 25+ so far.

ROLE
Solo · product & build
TIMELINE
2024 – present
STATUS
Closed beta, Google Play
STACK
Flutter · Firebase · NASA FIRMS · Gemini

The problem

Every burning season, stubble and crop-residue fires spread across north India. The data to warn farmers exists — NASA's FIRMS satellites detect active fires worldwide within hours — but the alerts that reach farmers are state-level. One notification covers an entire state: a fire 80 km away looks identical to one 3 km from your field. So farmers do the rational thing — they panic at every alert, or they stop trusting alerts altogether.

None of the five existing tools I studied could answer the only question that matters: is this fire actually a threat to my farm, right now, and what should I do about it? Weather apps treat fire as a news item, not a proximity problem; the dashboards that carry the raw data are English-only and built for analysts, not for someone standing in a field.

Kheto fire map with active fire detections around the farm location and an alert radius drawn.

The fire map — every active detection inside the radius the farmer sets, refreshed on each satellite pass.

Defining the product

Before any code: competitive research across five alternatives, two user personas, a full PRD, and a screen-by-screen flow. Twelve candidate features were scored for the MVP — and most of them lost. The cuts were the point. A mandi-price tracker looked attractive but had nothing to do with the core promise, so it went to the backlog.

What stayed was the thing no competitor had: a fire-relevance score that weighs the vegetation and wind between a fire and the farm, the distance, and the fire's intensity — not "is there a fire nearby" but "does this one actually threaten you" — plus an advisor that turns that into an action, in the farmer's own language.

The decision log

  1. 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.

  2. 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.

  3. 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.

  4. 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.

    25+ active testers and a feedback loop tight enough to validate against real fire events.

Where it stands

  • Active closed-beta testers 25+
  • Features scoped for the 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; add Indian languages and voice input to the advisor; 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.