I build software that has to survive contact with real users and real data — backend services, data pipelines, and the machine learning systems that sit between them. Most of my time goes into the unglamorous half of that work: making models reproducible, making pipelines restartable, and making sure the thing that worked in a notebook still works at three in the morning six months later.
My background is in computer science at IIT Roorkee, followed by product engineering at CommonFloor, where the problems were concrete: search and ranking over a large listings catalogue, recommendation quality, and the infrastructure needed to keep both fed with fresh data. Consumer marketplaces are a good teacher. The dataset is messy, users are impatient, and every latency regression shows up in a metric someone cares about.
Since then the work has stayed in roughly the same territory — applied machine learning attached to production systems rather than research for its own sake. I care about the seam between the two: the point where a model stops being an experiment and becomes something an on-call engineer has to reason about.
Service design, API contracts, data modelling, and the caching and queueing layers that keep read-heavy systems responsive under load.
Ranking and recommendation, text classification and embedding-based retrieval — with evaluation harnesses built before the model, not after.
Batch and streaming ingestion, feature stores, and the schema discipline that stops silent data drift from quietly degrading a model.
Deployment, monitoring, shadow traffic, and rollback paths. A model without a rollback path is a deployment risk wearing a lab coat.
Most engineering failures I have watched up close were not caused by picking the wrong algorithm. They were caused by solving a problem nobody had actually defined, or by building for a scale that never arrived. So the first pass on anything is usually subtraction: what is the smallest system that answers the question, and what evidence would tell us it is wrong?
The interesting constraint in applied ML is rarely accuracy. It is latency budget, cold-start behaviour, training–serving consistency, and what happens when the upstream data source changes shape without telling you. A model that is two points better offline and cannot be retrained on a schedule is worse than the one it replaced. I would rather ship a simple baseline with a working retraining loop and monitoring, then earn complexity one measured improvement at a time.
That also means being honest about when machine learning is the wrong tool. A great many ranking problems are solved adequately by a handful of well-chosen heuristics and a good index. Reaching for a model before exhausting that is how teams acquire a maintenance burden in exchange for a rounding error.
Backend and data-platform work, applied machine learning attached to a product surface, and technical review of existing systems — particularly where a prototype needs to become something maintainable.
Primarily Python and JVM languages on the backend, standard relational and document stores, message queues for asynchronous work, and the usual Python scientific and ML stack for modelling and evaluation.
Yes — mostly notes on things that took longer to debug than they should have, which tends to be the most useful thing to publish.
