Shipping an ML MVP in Four Weeks
by Florian Renard, Founder / CEO
Four weeks is enough to put a working machine-learning feature in front of real users — if you treat the deadline as a design constraint rather than an ambition. This is the playbook we run on rapid ML engagements, week by week, including the parts where we deliberately do less than you'd expect.
Week 1: Shrink the problem until it fits
The first week is spent making the problem smaller, not starting the model. We pick a single metric that defines success, a single slice of users who will see the feature, and the dumbest baseline that could possibly work — often a heuristic with no ML at all. The baseline matters twice: it's the fallback if the model disappoints, and it's the bar the model has to beat to earn its complexity.
We also decide what we will not build: no custom training infrastructure, no novel architectures, no speculative features. Four-week projects die of scope, not of difficulty.
Week 2: Data before model
Most of week two is data work: getting a representative sample, labelling a few hundred examples well (usually ourselves — founders labelling data is the fastest alignment mechanism ever invented), and building the evaluation harness. By Friday we want a pretrained or API model wired to real data with a real score, however mediocre.
Week 3: Integrate ugly, iterate fast
The model goes into the product in week three — behind a feature flag, with the heuristic baseline as fallback. Integration always surfaces the true requirements: latency budgets, weird inputs, the difference between offline accuracy and online usefulness. Daily iterations against the week-2 harness beat any amount of upfront modelling.
Week 4: Harden and hand over
The last week is production discipline: monitoring on both model quality and system health, load testing, a rollback path, and documentation the client's team can actually operate from. We ship to the user slice chosen in week one, watch the metric, and write down what the next four weeks should be — because an MVP that works always earns a sequel.
Why this works
Nothing here is clever. The speed comes from three refusals: refusing to train what we can reuse, refusing to build what the baseline makes unnecessary, and refusing to polish what users haven't validated. ML projects overrun when the model is the product; they ship on time when the product is the product and the model is an employee on probation.