An applied ML engineer who costs systems before building them and instruments them before shipping. Most of my work starts with someone unable to explain what their system just did, or unable to say what it can honestly claim in market.

that's me, Shreyan ✦
I did my M.Tech at Vellore Institute of Technology and started out as a software engineering intern at Dell Technologies. That is where production stopped being an abstraction: code other people depend on, running while you are asleep, failing in ways the test suite never suggested.
Two startups after that, back to back. Founding engineer at AkosMD in healthtech, where a wrong answer is a clinical one and nobody is impressed by a good average. Then applied ML and product at Mindstone Maven on the fintech side, including the ESOP workflow that went to SBI Cap Trustees.
The same problem showed up in both.
Systems performed beautifully in a notebook and behaved unpredictably once real users arrived, and nobody had instrumented the gap. So I started costing systems layer by layer before any code was written, and wiring them so behaviour and spend are visible from the first commit.
These are not two jobs. What a product can honestly claim in market is decided by what it actually does under test, so the evaluation and the go-to-market argument are the same piece of work seen from either end. I spend real time on that side now, on positioning, pricing, distribution strategy, and warm introductions into networks I have spent years inside. Founding Claude Developers India was not a marketing exercise, but 820+ builders is a network, and I use it on behalf of the people I work with.
I also write. Technical articles for Weights & Biases, and responsible AI policy including a certification framework sent to MeitY and NASSCOM. The fastest way to understand something is to run the experiment and publish what happened, including the times it did not work.
builders in Claude Developers India, founded and run by me
technical articles, each from an experiment I ran myself
tests across cc-habits, twelve of them security suites
Roughly in the order I lean on them when a decision is hard.
A model picked without its per-unit cost is a bill you have not read yet. The stack gets chosen against a cost model, not against a leaderboard.
If the data cannot tell you whether the fix worked, the fix is a guess. I would rather show you the measurement than ask you to believe me.
A result showing that an approach does not work is worth as much as one showing it does, and it is far cheaper to learn early. Sometimes the honest deliverable is a diagnostic instead of a build.
Three things done properly beat ten done halfway. If a piece cannot be made reliable yet, it ships marked experimental or it does not ship.
A system nobody can buy is a hobby. The route to the buyer deserves the same rigour as the architecture, and I work on both ends of it.
It has before. When something here stops being true I would rather say so in the open than defend it.
Tell me what is broken, or who you are trying to reach, and I will tell you plainly whether it is worth a call.