MLOps before you have any ML

A client wanted a model platform. They had one model, trained once, on one person's laptop.
A client wanted us to build an ML platform from scratch. They had a single model sitting on one data scientist's laptop. The model had been trained once. Nothing was versioned or documented. It ran, but nobody knew exactly why or how it worked.
The actual first milestone was not a platform at all. It was trivial-sounding but revealed the gap: reproducing that training run on a different machine. Not running it. Reproducing it exactly. Same data, same seed, same result. That took three days of investigation to untangle.
Once training was repeatable, versioning mattered and became essential. We set up data versioning so datasets could be tracked. We versioned the random seed and the code snapshot. Those two things resolved more production incidents than any sophisticated deployment orchestration would have.
After six months we had four models. After a year, seven models. By eighteen months there were eleven models and two teams building them. At that point an actual platform made sense. Before that it would have been overengineering the solution.
The pattern proved consistent across every project we worked on: start by making training runs reproducible and debuggable. Add data and code versioning so you can track what changed between experiments. Only then add orchestration and deployment infrastructure, when manual processes have genuinely become the limiting factor.
The lesson is structural and applies everywhere. You do not build MLOps for where you are today. You build it for where you are going. But you do not build it too early. That wastes engineering time on infrastructure that solves problems you do not have yet.