Voice-First Farm Ledger

A farmer running groundnut, bajra and castor across a few plots sees costs arrive in dozens of small streams over four or five months. Seed. Hired ploughing and rotavator work. Gypsum. Fertiliser. Ten or more days of labour. Sprays. Pipe fittings. The petrol to fetch the spray. The digger and thresher at harvest. Transport. Commission at the mandi.

Half of them are tiny, and they scatter across a notebook, his memory, the input dealer's credit book and a cold-storage receipt. When open-market rates routinely fall below the minimum support price, not knowing which crop made money and which lost it means finding out too late to change anything.

The funded agritech ecosystem clusters around advisory, marketplaces and scheme access. The operational and financial layer is the gap. This app is not competing with those products — it is competing with a ten-rupee notebook and WhatsApp voice notes, which are extremely good at what they do.

That framing drove every design decision. A notebook wins because writing one line takes three seconds. Any app that needs twenty taps to log a fertiliser purchase loses, regardless of what it does afterwards.

Entries are captured by speaking, in the farmer's own language. Speech recognition and parsing both have on-device fallbacks, so the app keeps working where there is no signal — which is most fields.

The whole application is offline-first. Entries are recorded locally and synchronise when a connection returns, because an app that needs connectivity to record a cost will not be there at the moment the cost is incurred.

The sharper pain sits inside the ledger. A bhagiya — a share-worker — takes a quarter or a fifth of the produce, in kind or as equivalent cash, net of advances taken through the season.

That calculation is dispute-prone, done from memory at the end of months of small advances, and completely undigitised by every existing app. Handling it properly is the feature that earns the app its place, because it settles an argument that happens every single season.

A Flutter application ships to phones; a FastAPI backend handles sync and lives on a server. They deploy independently, so pushing a server change does not require an app store release and vice versa — which matters when your users update their phone apps rarely, if at all.