The week-by-week structure behind our 90-day promise, and why most AI pilots never make it to production.
Industry surveys keep finding the same thing: most AI pilots never reach production. Our experience matches that. The models were usually fine. What was missing was a plan that treated production as the goal from the first day rather than a phase after the demo. This is the structure we use to get from a first conversation to a system in daily use inside ninety days.
Why pilots stall
A pilot is designed to answer “can this work?” and it usually can. The trouble is everything the pilot ignored to answer that question quickly: where the data really comes from, who maintains the pipeline, how the output reaches the person who needs it, what happens when the model is wrong. Those questions surface after the demo, and by then the budget and the enthusiasm are spent.
So we do not run pilots. We run short production projects with a narrow scope.
Weeks 1 to 2: Discovery and blueprint
Discovery starts with the decision the model will change and the person who makes it. We interview that person and the people around them, and we look at the data as it is, not as the architecture diagram says it is. Two weeks is enough to find the gaps, the quirks and the one field everyone relies on that turns out to be updated by hand.
The output is a blueprint: a one-page scope with a success metric in the client’s units, the data sources and their owners, the integration point where the output will land, and a fixed price. If the honest conclusion is that the data cannot support the goal yet, the blueprint says what to collect and we stop there. That has happened, and every client it happened to came back later with the data in hand.
Weeks 3 to 4: Baseline and first model
The first thing we build is a measurement of the current method. Then the simplest plausible model, evaluated on a time-based backtest against that baseline. By the end of week four there is a number: the model beats the baseline by this much, or it does not.
This is the earliest possible moment to learn whether the project will deliver, and it is deliberately early. A project that is going to fail should fail in week four.
Weeks 5 to 8: Pipeline, integration, iteration
With a model that works, the work shifts to everything around it. Data refresh on a schedule. Feature computation with explicit as-of timestamps. Retraining. Monitoring of inputs and outputs. And the integration: an API, a nightly file into the ERP, a dashboard, whichever the blueprint specified.
Every Friday there is a demo. Not slides, the actual system, running on this week’s data, shown to the people who will use it. Their reactions change the backlog for the following week. The model itself keeps improving in the background, but by now it is rarely the bottleneck.
Weeks 9 to 12: Production hardening and handover
The last month is about the system surviving without us. We run it in shadow mode alongside the current process, compare, and fix what the comparison reveals. We write the runbook: how the data flows, what the alerts mean, how to retrain, who to call. We pair with the client’s engineers on every part of it until they are making changes themselves.
Launch is quiet by design. The system has been running for weeks. Someone flips the switch that makes its output the one people act on, and the shadow comparison becomes the monitoring dashboard.
What makes it work
Three things, in our experience. A fixed scope with a metric nobody can argue about. Weekly demos of a real system, so surprises are small and early. And a definition of done that includes the runbook and the handover, not just the model.
What it costs
A fixed price agreed in the blueprint, usually in the range a mid-sized company would spend on one senior hire for a year, for a system that keeps working after the ninety days. We are happy to talk about the number on a discovery call, which is where every one of these projects has started.