The Analyst I Built for Myself

My job, most days, is turning raw noise into something useful. Thousands of alerts from SolarWinds, Cisco, Aruba, ThousandEyes. AIOps correlates it, ServiceNow turns it into something a human can actually act on. I'd never thought to apply that outside of work until I found myself losing evenings to the NSE website, staring at tables of numbers that told me nothing.

The problem wasn't a shortage of data. It was the same problem I deal with at work every day: numbers without interpretation are just noise. Every evening after market close, the NSE site has indices, movers, gainers, losers, sector swings — all accurate, none of it assembled into an answer to the one question I actually wanted answered: what happened today, and should I care?

That's what became market-research.mandar.me.

Once I saw it as an integration problem, the rest came together fast. A data source producing structured output on a schedule, a person who needs a summary instead of a spreadsheet, and a pipeline in between. I'd built that shape before, just with alerts and an AIOps platform instead of market snapshots and an LLM.

First requirement: it had to run itself. Fetch the data at market close, run the analysis, publish the report, no one babysitting it. I've learned the hard way that any process depending on a human to remember to run it eventually doesn't get run.

The architecture stayed deliberately small — a Python backend, a lightweight database, a Next.js frontend, no orchestration layer I didn't need. I've worked with enough complex infrastructure to know complexity is tempting and usually unnecessary. The real question is always what's the smallest thing that reliably gets the job done, and here the answer was genuinely simple.

The part I enjoyed most was the prompt. Ask a model to "analyse" raw numbers and you get something generic back. Give it a structured brief instead — index performance, top movers, sector patterns, outliers — and ask it to reason across them, and it reads like an actual morning research note. The difference isn't the model. It's how carefully the input gets assembled before it reaches the model.

I've spent two decades making enterprise systems talk to each other, and that discipline barely changes with the domain: figure out what one system produces, what the next one needs, and build the bridge. What struck me building this wasn't how different it felt from my day job. It was how similar.

The tools are new. The thinking isn't.

You already know how to build it. You just haven't pointed it at your own problem yet.