SpeakYield - voice-first agri-commerce platform for Indian farmers

This one came out of a government hackathon problem statement, but the problem itself is real and ugly: a smallholder farmer in Maharashtra selling onions knows yesterday's price at exactly one mandi, usually from the same commission agent who's also buying from them. They can't see the market 40km away, can't see what a processor or exporter would pay, and often sell right after harvest at the seasonal low because they need cash now, not because it's the best time to sell. Every step of that chain - price, buyer trust, quality grading, transport, payment - quietly leaks money out of the farmer's pocket.

I built SpeakYield to close that gap, and built it voice-first because the people this is for often can't or won't use a text-heavy app. A farmer can literally say "I want to sell 12 quintals of onion, I need ₹40,000 right now" in Marathi/Hindi, and the app:

Parses that into a structured request and reads it back for confirmation before anything commits - nothing moves on a guess

Shows every nearby buyer's price as net-in-hand, after transport, commission, and fees - not the misleading headline mandi rate

Recommends sell-now / split / hold based on the farmer's actual cash need, not just a price chart

Ranks competing buyer offers by what the farmer actually banks, weighted by the buyer's payment-reliability history

Runs the full deal lifecycle — offer, logistics, milestone payments, dispute filing — on one transparent, tamper-evident record

What I built: the full stack — Next.js/TypeScript frontend, FastAPI backend, the voice pipeline (speech-to-text → LLM intent parsing with strict schema validation → text-to-speech read-back), the buyer-matching and net-price ranking engine, and the deal/ledger system. Solo project, ~12 commits from architecture to a working two-sided prototype (farmer view + buyer view), with CI, linting, and end-to-end tests.

Stack: Next.js, TypeScript, FastAPI, Python, LLM-based voice intent parsing, PostgreSQL/Redis (production design)

I like this kind of problem specifically because it's not "build a CRUD app" — it's translating a messy, high-stakes, low-trust real-world transaction into software that has to work for someone with a ₹6,000 phone and patchy network, not a power user.

If you need someone who can take a genuinely fuzzy problem (multi-party trust, real-time matching, voice/AI interfaces) and turn it into a working product fast, that's exactly this.