Weekend 1: A Mandi Price Explorer for Uttar Pradesh

The first prototype of the Mridula Initiative is live at mandi-price-explorer.adityaksingh.dev: a Mandi Price Explorer for Uttar Pradesh. Choropleth of modal prices by district, time series, filters by commodity and date range. Built over a weekend with Python, Next.js, D3, Supabase, and Vercel.

What follows isn't a how-to. It's a note on why I picked this problem, what surprised me, what I cut, and the one question I can't answer from Bengaluru.

Why mandi prices

If you're trying to understand rural livelihoods in India, agricultural prices are close to the center of the picture. The price at which a farmer sells onions or potatoes at the local APMC mandi is not just a number — it's the difference between a profitable season and a season that drives a family further into debt. Mandi prices drive crop planning decisions for the next cycle, lending decisions by traders, and policy decisions in state capitals.

For someone like me, sitting in Bengaluru building software for US healthcare, it's a domain I have almost no native context for. So the first project of this initiative had to be a learning exercise: get my hands on real data, see what's there, see what isn't, and start building intuition.

I picked Uttar Pradesh because it's where my family is from. Kanpur is my parents' town. Prayagraj is the city I spent parts of my childhood in. Building something that included those names felt like the right place to start.

The surprise: the data is actually there

Here's what I expected when I started: that getting clean, current mandi price data would be the hard part of the project. That it would be locked behind PDF uploads, scanned forms, or scraping some half-broken state portal.

Here's what actually happened: I went to data.gov.in, found the Variety-wise Daily Market Prices Data of Commodities dataset, registered for an API key, and got back 1,500 data points for a single day across Uttar Pradesh — tomato, onion, potato, garlic, and dozens more commodities, broken out by district and mandi.

The districts I'd grown up imagining as cut off from technology were there, in the response payload, with modal prices updated daily.

I want to be careful not to overstate this. One day's data does not make a clean dataset. I haven't yet looked at gaps, lag, accuracy, or what happens during monsoon or harvest peaks. Patterns will emerge — or fail to — over weeks, not hours. But the fact that the pipe exists at all, that someone in the Indian government has gotten this far in making agricultural price data publicly queryable via API, is something I didn't know and probably should have.

What was actually hard

Not the data. Not the visualization. The two genuinely annoying parts were:

1. Getting the API key. The data.gov.in registration flow is buried, the documentation is sparse, and the path from "I want to use this dataset" to "I have a key that works" took longer than I'd like to admit. If you're trying to do something similar, budget an evening for this and don't be discouraged.
2. Rate limits. Once I had the key, I hit rate limits faster than I expected. This forced architectural decisions early — caching, scheduled syncs into Supabase rather than live API calls, and being careful about what the frontend actually needs to fetch. Useful constraint, in retrospect.

The choropleth itself was straightforward once I had a GeoJSON of UP district boundaries. D3's join model handles this cleanly and I won't bore you with the code.

What I cut

Plenty:

• Tests. Zero. This is a v0 prototype. If this evolves into something I actually maintain, tests come first.
• Proper infrastructure. Supabase free tier, Vercel free tier, no monitoring, no alerting. Good enough to be online; not good enough to be reliable.
• More than UP. The same API returns data for every state. I deliberately stayed in one state for v0 — the goal was depth in a place I have some connection to, not breadth across India.
• Trader-side views. Modal price is one of several prices the API returns (min, max, modal). I picked modal for the visualization because it's the most representative of typical transactions. The trader-facing variants might matter more for different users. I don't know yet.
• A historical archive view. Right now you see what's there. Trends, seasonality, year-over-year comparisons — all that comes in a later iteration if the project earns it.

What I learned

A few things, partial and tentative:

• The Indian government has done more on open agricultural data than the version of me from a month ago believed. I owe them an updated mental model. Whether that data is used is a separate question, which is the one I really care about.
• Modal prices for the same commodity vary significantly between districts in the same state on the same day. This is intuitive but seeing it on a choropleth makes it concrete. A farmer in district A getting ₹18/kg for onions while a farmer in district B gets ₹26/kg is the kind of disparity that should drive a question: why? Transport cost? Quality? Buyer concentration? Market access? I don't know yet, but the visualization at least lets the question be asked.
• Building public, even at the prototype level, changes how you write code. Knowing that the URL is real and people might land on it made me care about the empty state, the mobile rendering, and what happens when the API is slow in a way I wouldn't have if it were running on localhost. Small thing, but real.

The question I can't answer from Bengaluru

Here's the one I'm leaving with:

Is this kind of data visualization actually useful to the people in those districts? And if not in its current form, what would it take to make it useful?

The data is published openly by the government with the stated intent of making it useful. But there's a long path between "data is queryable via API" and "a farmer in Hardoi makes a better decision because of it." The intermediate links — extension officers, FPO managers, cooperative leaders, agritech apps, kisan call centers, WhatsApp groups — are where the value either gets created or lost.

I can build prettier dashboards from Bengaluru. I can't answer this question from here. I'll need to talk to people who work with farmers in UP — NGOs, NABARD field officers, anyone working on FPO infrastructure — and listen. That conversation phase comes after a few more prototypes, when I have enough built that I'm not just showing up empty-handed.

What's next

The SHG Loan Rules Chatbot. Hindi-first, RAG over RBI and NABARD lending guidelines, evaluation-first. Different problem, different shape — and a more interesting test of whether language models can usefully translate dense regulatory text for the people it's actually written about.