Most ML teams ship one model in their first year. The notebooks pile up. The models work in eval. Production is a perpetual next quarter. We've helped a dozen teams break this cycle — and the answer isn't better engineers, it's a smaller first goal and a sharper definition of done.
The thirty-day rule
We give every ML engagement a fixed budget: thirty days from kickoff to a model serving real traffic behind a feature flag. Not a perfect model. Not the model the team is most excited about. The model that's most likely to land cleanly inside thirty days.
The constraint forces decisions. You pick a smaller scope. You skip the framework debate. You accept that 'baseline + observability' beats 'best in class without monitoring' every time. Once the first model lands, the second is twice as fast — because the platform is already there.
What goes in the platform
Training: Airflow or Prefect, one of them, picked by the team's existing skills. Model registry: MLflow, even if you outgrow it later. Inference: a service behind your standard API gateway, not a custom stack. Observability: latency, drift, per-tenant cost — from day one.
Anything cleverer than this is a debt your second model can pay for. The first model just needs to ship.
Why teams resist
Most resistance to the thirty-day rule comes from research-trained ML engineers who associate 'shipping early' with 'shipping bad.' The honest counter is that a baseline model in production teaches you more in a week than a perfect model in a notebook teaches you in a quarter. Every team we've worked with — without exception — has agreed in retrospect.
Want this kind of work on your project?
One conversation, honest pricing, recommended engagement model — within a business day.
Keep reading
All articlesHow we estimate software projects (and why most estimates are wrong)
Every estimate is wrong. The useful ones are wrong in known ways. A practical method we've refined across 50+ engagements — and the failure modes we learned to spot first.
The unreasonable effectiveness of plain SQL
ORMs are fine. Until they aren't. After a decade of building data layers on every framework we could find, we keep coming back to plain SQL — and the patterns that make it pleasant.
Why we don't write microservices anymore
We split into microservices because it was 2019. Then we spent three years feeling the cost. Here's what we learned, and how we structure backends in 2025.