Pilots, proofs of concept and production: the three stages
Three words used interchangeably that mean different things, with different budgets, durations and exit questions. What each stage is for.
The short answer
Proof of concept, pilot and production are used as if they were synonyms, and they are three different things with different purposes, budgets, durations and exit questions. A proof of concept proves that an idea can work at all: days, sample data, no real users, thrown away afterwards. A pilot proves that it works for real people on real data at small scale, measured against a baseline: weeks, with a decision date. Production proves that it keeps working: integrated, monitored, owned, budgeted, supported. Each stage ends with one question, and the projects that lose their way are the ones that skipped a stage or never asked its question.
The three stages
| Proof of concept | Pilot | Production | |
|---|---|---|---|
| Purpose | Can this work at all? | Does it work for us, measurably? | Does it keep working? |
| Data | Sample, often cleaned | Real, current | All of it, changing |
| Users | None, or the builders | A small group of real users | Everyone eligible |
| Duration | Days to two weeks | Four to eight weeks, fixed | Ongoing |
| Measurement | Does the output look right? | Metrics against a baseline, evaluation set | Monthly quality sample, business scorecard |
| What is built | Throwaway | Enough to run safely at small scale, with a person at the gate | Integration, monitoring, guardrails, procedures |
| Exit question | Is the real data good enough to try a pilot? | Who owns it in production and what does it cost per month? | Is it still worth running, per the scorecard? |
| Typical mistake | Polishing it into a product | Extending it indefinitely | Never budgeting it |
What skipping a stage costs
- Skipping the proof of concept: a pilot is built around an idea that could not work, discovered after weeks instead of days.
- Skipping the pilot: real data and real users meet the system for the first time in production, and the lessons are learned publicly.
- Treating the pilot as production: the system runs for months with no owner, no monitoring and no budget, until it fails or fades.
- Skipping the production project: the pilot is “switched on for everyone” without integration, procedures or training, and adoption collapses.
Running them in sequence
Proof of concept in a week: does the model handle five of your real cases sensibly? If yes, ask whether the real data, at volume, is good enough for a pilot; if it is not, the next project is data, not AI. Pilot for six weeks with a baseline, an evaluation set, a person at the gate and a decision date. At the date, answer the ownership and cost question. If the answers exist, run the production project: integrate, monitor, train, launch, then measure on the scorecard. If they do not, stop with a written lesson. Both outcomes are progress.
What this means for you
Use the three words precisely and budget all three stages. Let the proof of concept be fast and disposable, the pilot measured and time-boxed, and production a real project with an owner and a monthly line. Ask each stage’s exit question and act on the answer. Projects run this way either reach production properly or stop cheaply, and both are better than the third option, which is neither.
Frequently asked questions
Can we go straight from proof of concept to production?
For something internal, low-stakes and simple, sometimes. For anything customer-facing, money-adjacent or touching many people, no: the pilot is where you learn what real data and real users do to the idea, at a scale where mistakes are cheap. Skipping it moves that learning into production, where mistakes are expensive and public.
How long should each stage take?
Proof of concept: days to two weeks. Pilot: four to eight weeks, with a decision date fixed at the start. Production: ongoing, with a launch project of a few weeks to add integration, monitoring, procedures and training. Longer proofs of concept and open-ended pilots are two reliable ways for a project to lose its way.
What is different about production?
Everything that was optional before becomes required: integration with the systems everyone uses, monitoring and alerts, a named owner, a monthly budget, guardrails tested adversarially, procedures rewritten, staff trained, and a way to pause it. The technology is often the same as the pilot. The discipline is not.