MLOps for small teams: what actually matters

Start from the failure, not the platform

Large companies build ML platforms because they run hundreds of models. A small team has a handful. The goal is not to copy their tooling. It is to prevent the failures that actually hurt: a model that cannot be reproduced, a silent data change, a deploy that cannot be rolled back, and a model that decays unnoticed.

Google engineers described this well in the paper Hidden Technical Debt in Machine Learning Systems: the model code is a small part of a real system, and much of the cost hides in data dependencies, configuration and feedback loops.

The essentials

1. Everything in version control

Code, configuration, and the exact training command. If you cannot rebuild last month's model from the repository, you do not have a process yet.

2. Version your data

Keep a dated snapshot, or a hash, of every training dataset. A data versioning tool helps, but even a dated folder with a manifest beats nothing.

3. One repeatable training script

A single command that goes from raw data to a saved model and a metrics file. Set random seeds and record library versions.

4. Track experiments

Log parameters, metrics and the data version for each run. A spreadsheet is a fair start; an experiment tracker is better once you have more than a few runs.

5. A model registry, even a simple one

A named place where models live with a version, the metrics and the data used. "Production" should be a label on a version, so rollback means moving a label.

6. Automated tests

• Unit tests for feature code.
• A data check that fails loudly on missing columns, odd ranges or a sudden change in volume.
• A model check: the new model must beat or match the current one on a fixed held-out set before it can ship.

7. Deploy in a container

A container image pins the environment, so what you tested is what runs. Keep the serving code thin and versioned.

8. Monitor what matters

At minimum: request volume, errors, latency, and a check of input data against training data. Where labels arrive later, compare predictions with outcomes. Decide in advance what triggers a retrain or a rollback.

What can wait

• Feature stores, until several models share the same features.
• Kubernetes-scale orchestration, until a single server or managed service is genuinely not enough.
• Fully automated retraining, until you trust your data checks and evaluation gate.
• Custom platforms. Buy or borrow first.

A sensible order

1. Version code and data.
2. Make training one command.
3. Add a gate that compares a new model to the current one.
4. Containerise and deploy with a rollback path.
5. Add monitoring and a review habit.
6. Only then automate more.

The habit that matters most

Write down who owns each model, where it runs, how to roll it back and what "healthy" looks like. Small teams lose most time not on missing tools but on knowledge that lives in one person's head.

Quick summary

Reproducible training, versioned data, a gate before deploy, an easy rollback and basic monitoring cover most of the value. Add tooling when a real problem justifies it.