Most MLOps writing assumes you have a platform team, a Kubernetes cluster someone else maintains, and a budget line for observability. A three-person team has none of that. What it has is a model that works in a notebook, a spreadsheet of experiments nobody can reproduce, and a nagging suspicion that the version running in production is not the version anyone tested. The five tools below close those gaps without turning your week into infrastructure work. All are open source, all run on a single VM or a laptop, and each one solves a problem you will hit within the first month of putting a model in front of real users.

What a small team actually needs to solve

Before comparing tools, name the problems. For most teams of two to eight people, the real failures are mundane:

• Reproducibility. Someone reports a suspicious prediction, and no one can reconstruct which data, code and parameters produced the deployed model.
• Packaging. The model exists as a pickle file in a chat message, and serving it means rewriting preprocessing by hand.
• Delivery. Retraining is a manual ritual that depends on one person remembering the right order of commands.
• Monitoring. Accuracy looks fine because nobody has measured it since launch.

Feature stores, distributed training and a full model governance suite can wait until you have a second model in production and someone whose job is keeping it there.

MLflow for tracking runs and keeping a registry

MLflow is the sensible first install. Point it at your training script, log parameters, metrics and artifacts, and you get a searchable history instead of forty untitled notebooks. Its tracking API is language-agnostic, with autologging for several popular frameworks, and the model registry gives you a named, versioned artifact you can promote rather than a file path someone hardcoded.

Start with the local UI, then move to a small server with a database backend and an object-store artifact location so two people can log to the same place. For a churn classifier, the payoff is concrete: you can sort 60 runs by validation AUC, see that one preprocessing change accounts for most of the improvement, and hand that exact artifact to whoever deploys it.

If a result cannot be reproduced from a logged run plus a versioned dataset, treat it as a rumour, not a result.

DVC for versioning data and pipelines

Git is excellent at code and terrible at a 12 GB CSV. DVC fixes the gap: you run dvc init, add a dataset, and Git tracks a small pointer file while the bytes live in a remote such as S3, MinIO, Google Drive or an SSH box. From there, a dvc.yaml file describes stages — clean, featurize, train, evaluate — and dvc repro reruns only what changed. Committing the pipeline definition means a teammate can check out last month's code, pull the matching data, and rerun the experiment.

One habit worth forming early: record the data version alongside the MLflow run, even if it is just a commit hash in a tag. That single link answers most "what changed?" questions later. Also watch disk usage; DVC caching can quietly fill a laptop.

BentoML for packaging and serving

BentoML turns a trained model plus its preprocessing into a service with a stable API. You describe the model and dependencies, wrap prediction logic in a service class, and get a local server for testing plus a container build for deployment. The parts you would otherwise write yourself — request validation, batching, health endpoints, artifact versioning — are handled, which matters when your serving code is maintained by the same people who train the models.

The honest caveat: if your team already serves models well through FastAPI, KServe or TorchServe, switching gains you little. BentoML earns its place when serving is currently a hand-rolled Flask app that nobody wants to touch.

Evidently for monitoring and drift detection

Labels arrive late or never. So monitor the things you can observe today: input feature distributions, missing values, out-of-range values, and the distribution of predictions themselves. Evidently generates reports from a reference dataset and a current batch, covering data drift, data quality and model performance once labels do show up. Run it on a schedule, write the output to a dashboard, and alert only when a metric crosses a threshold you set deliberately.

Two practical tips. First, define the reference window as the data your model was validated on, not the whole history. Second, be conservative with alerts — a channel that fires every morning gets muted within a week, and then you have no monitoring at all.

Prefect for orchestration without a platform team

Once retraining runs weekly and actually matters, you want retries, scheduling and a visible run history. Prefect lets you decorate ordinary Python functions as tasks and flows, add retries and caching, and deploy on a timer without adopting Airflow's scheduler-and-DAG model. If your pipeline is three steps and runs monthly, a cron entry and a well-tested script are fine — this is a tool to adopt when manual runs start failing quietly.

Putting the five together

A sequence that works for a small team without a big-bang migration:

1. MLflow. Log every training run and register the model you actually deploy.
2. DVC. Version datasets and pipeline stages; link runs to data versions.
3. BentoML. Serve the registered artifact with validation and batching included.
4. Evidently. Capture production inputs and predictions, then run weekly reports.
5. Prefect. Wrap retraining and reporting in flows with retries and alerts.

All five use permissive open-source licenses, so there is no procurement conversation before you try them. Budget instead for a small always-on machine, backups of your artifact store, and credentials kept in a secret manager rather than a repository file. If you handle personal or regulated data, check with whoever owns compliance before pushing datasets or model artifacts to a hosted storage service.

Start narrow and keep it boring

Pick two tools, not five. A reasonable target for the first month: a new teammate clones the repository, reproduces last quarter's best run, and redeploys that exact model in under an hour using only what is checked in. If they can do that, you have versioning, tracking and deployment working well enough for real use. Add monitoring once the model serves live traffic, and orchestration once retraining happens often enough to be worth automating. Write the rollout steps down as you go — the runbook you wish you had is usually the best documentation your team will produce.

Photo: cookieone / Pixabay