Why I built MLOps.dev.
It started with a factory in Bengaluru. A computer vision model — months of training, nights of tuning, 94% accuracy on the benchmark — deployed to 12 industrial cameras via a Python script someone wrote in an afternoon. Three weeks later, no one knew what version was running on which camera. Drift had crept in on six of them. Nobody had an alert. Nobody even knew to look.
"I spent more time managing deployments than improving models. That's when I realised the infrastructure was the real problem — not the ML."
I'm a builder with a background in ML engineering and systems design. I've shipped models to edge hardware across manufacturing, retail, and healthcare. Every single time, the operational layer was an afterthought — bash scripts, cron jobs, and prayers that the device would reconnect to sync the update.
The cloud-native MLOps tools — great for data centres, useless for the edge. Kubeflow doesn't run on a Jetson Nano. MLflow doesn't care if your device goes offline for six hours in a factory basement. The edge has fundamentally different requirements, and nobody was building for them.
So I started building MLOps.dev — not as a side project, but as the company I wish had existed when I needed it. An open-source agent small enough to run on any ARM board. An offline-first sync protocol that works at 2G speeds. A drift detection system that fires before your users notice. Infrastructure that meets the real world where it actually is.