An MLOps platform is a set of tools and workflows that automate the lifecycle of a machine learning model, covering data versioning, experiment tracking, CI/CD for training pipelines, model registry, deployment, and post-deployment monitoring in one coordinated system. Whether a company needs one depends less on model count and more on how often models change and how much retraining and redeployment happens; a company shipping one model a year can often get by with notebooks, Git and manual deployment, while a company running dozens of models or retraining weekly loses significant engineering time to manual handoffs and inconsistent environments without a platform. Typical open-source building blocks include MLflow for experiment tracking and a model registry, Airflow or Dagster for pipeline orchestration, and Kubernetes for serving, while managed options like SageMaker, Vertex AI and Azure ML bundle these into one product at a recurring cost. The real signal that a platform is overdue is when data scientists spend more time on deployment plumbing than on modeling, or when nobody can reproduce which data and code produced a model in production. Nanobase AI assesses model velocity and team size before recommending a lightweight open-source stack or a managed platform, rather than defaulting to either.
The real question is not "yes or no" but "which tier"
Framing this as binary leads teams to either over-invest in a platform they cannot staff or under-invest and rebuild everything eighteen months later. A more useful question is which of three maturity tiers matches current team size, model count and retrain cadence, since each tier has a stack that fits it and two that do not. A full platform for a two-model team wastes budget on unconfigured features; a fifteen-model, weekly-retrain operation on notebooks wastes engineering time on repetitive plumbing.
The three tiers and what triggers each
| Tier | Team & model profile | Retrain cadence | Recommended stack |
|---|---|---|---|
| 1. Notebooks + Git | 1-3 data scientists, 1-3 models | Quarterly or less | Git for code, a shared document for experiment notes, manual deploy via a documented script |
| 2. Lightweight open source | 4-15 engineers, 4-15 models across a couple of product teams | Monthly | MLflow for experiment tracking and registry, Airflow, Dagster or Prefect for orchestration, Docker plus basic Kubernetes for serving |
| 3. Full platform | 15+ engineers, 15+ models or many LLM applications | Weekly or continuous | A managed platform such as SageMaker, Vertex AI or Azure ML, or a fully self-service open-source stack with approval gates and multi-tenant serving |
Team size and retrain frequency predict platform need far more reliably than raw model count alone, since two models retrained daily under strict compliance review need more automation than twenty models that barely change.
Signals you have outgrown your current tier
Beyond engineers spending more time on deployment than modeling, watch for these:
- A new model takes longer to reach production than to build, because there is no repeatable deployment path.
- Two environments drift apart because configuration lives in someone's terminal history, not version control.
- Rolling back a bad release requires manual intervention rather than a tested procedure.
- On-call engineers get paged for model issues because there is no automated health check or rollback trigger.
Any one of these signals is stronger than model count alone, since each represents engineering time lost to plumbing rather than modeling.
A short checklist before you buy or build anything
- Count models in production and how many times each was retrained or redeployed last quarter.
- Trace how a model moves from notebook to production endpoint today, counting every manual handoff.
- Check whether you can answer "which code and data produced the model serving traffic now" in under five minutes.
- Confirm whether compliance obligations, including EU AI Act high-risk duties from 2 August 2026, require an audit trail today's setup cannot produce.
- Estimate the engineering headcount actually available to operate a platform, since even an open-source tier carries real maintenance cost.
A checklist that comes back mostly clean means the current tier is still correct, whatever a vendor's sales pitch implies.
Build versus buy shifts by tier, not by preference
At tier 2, an open-source stack usually wins on cost and flexibility because the team is small enough to operate it directly. At tier 3 the calculus changes: a managed platform trades a recurring fee for reduced operational burden, which matters when staff cannot run Kubernetes-based infrastructure around the clock. The buy-versus-build decision only becomes worth debating once a team reaches tier 2 or 3; below that, either option is over-engineering. See the fuller trade-off in buying an MLOps platform versus building one from open source.
Frequently asked questions
Is a small startup with two models wasting time worrying about MLOps platforms?
Generally yes, if retraining happens rarely. A tier-1 setup with Git and a documented manual deploy script fits that scale, and adding a platform earlier mostly adds configuration overhead without solving a real bottleneck. The conversation becomes worth having once model count or retrain frequency climbs.
Can we move from tier 1 to tier 2 without a full re-architecture?
Yes, if the underlying code is already reasonably modular. Introducing MLflow for tracking and a registry, plus an orchestrator for scheduled pipelines, can typically be layered onto an existing codebase incrementally, model by model, rather than requiring a rewrite of training or serving code.
Does relying on cloud LLM APIs instead of self-trained models change which tier we need?
It shifts the workload rather than eliminating it. Teams calling hosted APIs skip training-pipeline concerns but still need prompt versioning, cost tracking and evaluation infrastructure, which maps to a similar tiering exercise focused on LLMOps concerns instead of classic retraining cadence.
How long does it typically take to stand up a tier 2 stack?
For a team with existing containerized services, integrating MLflow and an orchestrator typically takes a few weeks rather than months, though the timeline depends on how much of the current deployment process is manual and still needs scripting.
How Nanobase AI helps
Nanobase AI evaluates a client's actual model count, team size and retrain cadence before recommending a stack, rather than defaulting to a lightweight toolkit or an expensive managed platform. We have implemented both tiers directly, wiring MLflow-based tracking into existing CI/CD pipelines for growing teams and standing up self-service platforms for organizations running many models. Explore our solutions or check the FAQ for common questions on scope and timeline.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.