MLOps Explained: Life After the Model Is Built
Last updated:
The model is roughly a fifth of the job
A data scientist spends six weeks building a demand forecast for a 60-person wholesaler. It scores well on last year's data. Everyone is pleased. Three months later nobody trusts it, the numbers have quietly drifted, and the person who built it has moved on to another project.
That story is so common it barely counts as a cautionary tale. The model was fine. What was missing was everything around it: a reliable way to get fresh data in, a way to know when the forecasts went wrong, and a clear owner for fixing them. That surrounding work is what people mean by MLOps.
The name borrows from DevOps, and the idea is the same. Code that runs once on someone's laptop is a prototype. Code that runs every night, gets tested, gets monitored and can be rolled back is a system. A model is no different, except that it can break without any code changing at all.
What MLOps actually covers
Strip away the vendor diagrams and there are six jobs. Every production model needs each of them done somehow, even if some are done by a person with a spreadsheet.
| Job | What it means | Smallest version that works |
|---|---|---|
| Data pipeline | Getting the same inputs, cleaned the same way, every time | A scheduled script with checks on row counts and nulls |
| Packaging | Turning a notebook into something that runs anywhere | A Python package or container with pinned library versions |
| Serving | Getting predictions to the place they are used | A nightly batch job writing to a database table |
| Monitoring | Knowing when predictions or inputs look wrong | A weekly report comparing predictions to outcomes |
| Retraining | Refreshing the model on newer data | A documented script someone runs each quarter |
| Versioning and rollback | Knowing which model made which prediction, and reverting | Saved model files with dates and a config switch |
Notice that none of the right-hand column needs a paid platform. We would rather see a business run those six things well with plain tools than buy a platform and do two of them.
Why machine learning needs its own operations
Ordinary software fails loudly. A bug throws an error, a page does not load, someone rings support. Machine learning fails quietly. The model still returns a number. It is just a worse number than last month, and nothing in the logs says so.
- The world changes under the model. Customer behaviour, prices, suppliers and seasons move, and a model trained on the past slowly stops describing the present.
- Data breaks upstream. A field gets renamed in the CRM, a unit changes from kilograms to grams, and the model keeps predicting on nonsense.
- Training and live code diverge. The feature was calculated one way in the notebook and slightly differently in the live system. This one is embarrassingly common.
- Nobody owns it. The model sits between the data team and the software team and each assumes the other is watching.
Every one of those is an operations problem rather than a modelling problem. A better algorithm fixes none of them.
How much MLOps does a small business need?
Less than the conference talks suggest. The right amount depends on how often predictions are made, what a wrong one costs and how quickly the underlying world changes.
- A monthly churn score reviewed by an account manager needs a batch job, a saved model file and a quarterly accuracy check. That is about it.
- A pricing model touching thousands of orders a day needs automated monitoring, alerts, a tested rollback and a retraining schedule.
- A fraud or credit model making decisions about people needs all of the above plus logging of every prediction and an explanation trail, and probably attention to the EU AI Act if you trade in Europe.
We sometimes talk clients out of a model entirely at this point. If the operations burden looks heavier than the value, a set of well-chosen rules may do the job; we wrote about that trade-off in machine learning versus a rules engine.
A sensible order to build it in
- Make the training run reproducible from a clean checkout, with data pulled by code rather than by hand.
- Use one shared function to calculate features for both training and live predictions.
- Deploy the simplest serving pattern that meets the need, usually batch.
- Log every prediction with the model version and the inputs used.
- Join predictions to real outcomes and report accuracy on a schedule.
- Only then automate retraining, and put a human approval step before a new model goes live.
Teams tend to start at step six because automated retraining sounds impressive. Without steps four and five you have no way to tell whether the retrained model is better, so you are automating a coin toss.
Where MLOps goes wrong
The most expensive failure we see is over-building. A company with one model buys a feature store, an experiment tracker, a pipeline orchestrator and a model registry, then spends a year integrating them. The model itself gets less attention than the tooling.
The second is under-owning. A model gets deployed as a one-off project with no named person responsible for its accuracy. It works until it does not, and the first sign is a sales director asking why the forecast was so wrong.
If you cannot name the person who would notice this model getting worse, you do not have a production model. You have a scheduled guess.
If you are weighing up specific tools, our note on an MLOps stack for mid-sized companies goes through them. This post is deliberately about the jobs rather than the products.
How we approach it
When SpiderHunts takes on a machine learning project, the operations plan is written before the model is chosen. We agree who owns accuracy, how outcomes will be measured, how often the model will be refreshed and what the fallback is when it is switched off. Then we build the model to fit that plan.
It makes for a less exciting kick-off meeting. It also means the model is still in use a year later, which is the only result that matters.
Frequently asked questions
What is the difference between MLOps and DevOps?
Do we need an MLOps platform?
Who should own a model in production?
How long does it take to set up MLOps for one model?
Got a model that works on a laptop but nowhere else?
Tell us what it predicts and where the answer needs to go. We will sketch the smallest set of MLOps pieces that would keep it working, and say plainly which ones you can skip.