Building an Economic Slowdown Monitor for India (and Everything That Went Wrong Along the Way)

I wanted to build something that would actually push my skills — not another “top 10 Netflix movies” dashboard. So I picked a project with an obvious trap built into it: take the classic “recession risk dashboard” idea, but build it for India instead of the US.

I didn’t realize how much that one decision would change everything.

The US has FRED. It has the NBER, a body that literally tells you the exact start and end date of every recession since 1857. Clean APIs. Decades of tutorials. India has none of that. I found this out the hard way, and it turned into the most valuable part of the project — more valuable, honestly, than the dashboard itself.

I checked around first for prior art. Most Indian-economy projects I found do one of two things: plot a single existing indicator over time, or forecast one number (usually GDP) with a time series model. I couldn’t find anything that combined multiple macro indicators into one composite risk score — and nothing that dealt head-on with the fact that India has no official body to even validate that kind of index against. That gap became the whole project.

The First Wall: There’s No “Correct Answer” to Check Against

My plan was simple on paper. Pull a handful of indicators — inflation, industrial output, unemployment, forex reserves, the rupee’s exchange rate, GDP — combine them into one score, and check if that score spikes during known bad periods.

Except “known bad periods” turned out to be a genuinely hard thing to define. In the US, you’d just download NBER’s recession dates and backtest against them. India has no equivalent. No agency has ever said “India was in a recession from this date to that date.”

So I stopped calling it a recession model. I renamed it, honestly, to a Slowdown Risk Monitor, and picked three historically agreed-upon stress events — the 2013 Taper Tantrum, the 2016–17 Demonetization, and 2020 COVID — as reference points instead of ground truth. It’s a small wording change. It matters more than it sounds like it should, because it forces you to stay honest about what your model can and can’t claim.

The Second Wall: India Doesn’t Have a FRED — But It’s Getting There

I assumed I’d be stuck scraping PDFs off government websites. Instead I found something better: an official Python client, published directly under the Ministry of Statistics’ own GitHub account, wrapping their live data API.

This was a genuine find. It meant I could pull inflation, industrial production, and unemployment data with actual code instead of manually downloading spreadsheets.

It also meant I was using something genuinely early and rough around the edges. The package’s own documentation admitted some calls fail intermittently, even with correct parameters. I hit that more than once. I ended up wrapping almost every single fetch call in retry logic and error handling, because I couldn’t assume a clean response, ever.

The Bug That Actually Taught Me Something: Wrong Data, Zero Errors

Here’s the failure mode that cost me the most hours, and also the one I learned the most from.

When you forget to specify a filter on these APIs, they don’t throw an error. They just quietly hand you a plausible-looking wrong answer.

My first CPI pull looked completely fine. Real numbers. Real dates. Nothing crashed. It took actually opening the data and reading it row by row to notice the problem: I was pulling Rural sector data, mixed with sub-categories like “food” and “fuel,” when what I actually needed was the national “All India, Combined, General” headline number. The API hadn’t rejected my incomplete request. It had just picked something and handed it to me like it was exactly what I asked for.

The fix became a habit: always call the metadata endpoint first — the one that lists every valid filter value for a dataset — before ever pulling real data. Once that became automatic, entire categories of bugs just stopped happening. Simple lesson. Expensive to learn.

The Bug That Almost Shipped: -47% Inflation

This one’s my favorite, because it’s subtle enough that it could have made it into the final dashboard unnoticed.

India recently changed CPI’s base year — from a 2012 reference point to a 2024 one. That means the index numbers before and after the switch sit on two entirely different scales, like measuring temperature in Celsius for one period and Fahrenheit for the next, with no conversion formula written down anywhere I could access.

The first time I calculated year-over-year inflation across that boundary, my chart showed inflation cratering to negative 47 percent. Obviously, wildly wrong. India has never had deflation anywhere near that.

The honest fix wasn’t to force a number in. It was to explicitly blank out those specific months, with a note explaining why: comparing across the base-year switch isn’t mathematically valid without an official linking factor I didn’t have access to.

A gap labeled “no data” is more honest than a confident, wrong number. That’s a bigger lesson than anything about pandas syntax.

The “Bug” That Wasn’t a Bug: A Slowdown That Looked Like a Recovery

After building the composite index, something looked backwards. Right after correctly spiking during the 2016 Demonetization event, the index dropped to its lowest point in the entire 13-year series — like the crisis had suddenly resolved itself.

Digging into the actual numbers, the real story emerged: inflation had genuinely crashed after demonetization, a real effect of the sudden cash shortage. My model was treating any drop in inflation as automatically good news. But unusually low inflation can itself be a warning sign — deflationary pressure, collapsing demand — not proof that everything’s fine.

This wasn’t a coding mistake. It was a real gap in how I’d modeled the relationship between inflation and risk. Catching it, instead of just accepting a chart that looked reasonable, was one of the more useful moments in the whole build.

Some Gaps Just Are What They Are

Not everything strange in the data turned out to be a bug I introduced. Some of it is just how Indian public data actually exists:

• The unemployment survey only goes back to 2017 — earlier employment data used a completely different methodology, so there’s no clean way to stitch it further back.
• The older CPI series is missing January and February data, every single year, in the national headline view. That gap was already there in the source.
• The most recent one to two months of almost every indicator are usually unavailable — not a broken pipeline, just governments publishing on their own schedule, same as anywhere else in the world.

I documented all of this directly in the dashboard, including a visual flag on months built from incomplete data, rather than quietly hoping nobody noticed.

What I’d Change Next Time

If I rebuilt this, I’d:

• Weight indicators by how early they’ve historically moved before past slowdowns, instead of treating all four equally
• Model inflation as risky in both directions — too high or too low — instead of just one
• Try to track down MoSPI’s official CPI linking factor, so the base-year gap could actually be closed instead of blanked out

None of these are huge. Each one is a real design decision, which is exactly why I didn’t rush to bolt them on late.

Try It

Live dashboard: https://indias-economicslowdownmonitor.streamlit.app/

Full code + data pipeline + a much longer written breakdown of every limitation: https://github.com/chaitanyaamayekar/INDIAN_ECONOMIC_SLOWDOWN_MONITOR

If you’re building something with public data — Indian or otherwise — here’s the one thing worth taking from this: check what your API actually returns, not what you assume it returns. Every bug that cost me real time was never one that crashed. It was always the one that looked fine.