From POC to production: getting an AI project out of purgatory

The purgatory of POCs

Purgatory is that in-between where a prototype works but never earns the right to go live. It runs on a clean dataset, on three hand-picked cases, in front of a friendly audience. Then comes the awkward question: 'when do we put it in production?' And that is when, often, nobody knows who owns the project, where the data runs, what it will cost per month, or how anyone would notice it going off the rails. The POC did not fail technically. It was built as a demo, not as a system.

The cause is not the tech

When a project stalls, people blame the model, data that is 'not mature enough', the vendor. It is rarely that. The POC's technology is usually good enough. What is missing are four things invisible in a demo but decisive for going live.

• The data: the POC ran on a hand-cleaned extract. In real life your data is scattered, incomplete, badly labelled, and nobody has planned who keeps it up to date. It is the first thing I check (is your data ready for AI).
• Adoption: nobody asked the people who will use the tool what they actually needed. The output is fine, just not inside their workflow.
• Ownership: the POC was one motivated person's baby. Without a clear business owner in production, no one is there to carry it, fix it, improve it.
• Run cost: nobody estimated the monthly bill at real scale. You discover the price when it is too late to turn back.

Scoping a production-ready POC from the start

A production-ready POC is not a bigger POC. It is a more honest one. I scope it on a real use case, with real data (even a little), the real user in the loop, and a measurable definition of 'it works'. The goal is not to prove the AI can do something impressive, it is to prove, on a tiny scope, that the full chain holds: data, model, action, user, cost. That is the starting principle of my method: one case handled end to end, ugly cases included, beats a demo that handles ten cases but only when everything is clean.

The success criteria to set before you code

Before a single line is written, I get it in writing what will trigger a 'yes, we industrialise'. Not a feeling in a meeting: a threshold. Without it, the POC passes or fails depending on the mood of the day, and that is exactly how you stay in purgatory.

• The minimum acceptable quality, measured on real examples: what share of good answers, what error margin you tolerate, on which cases.
• The target gain, quantified: time saved, tickets avoided, delay cut. A ballpark is enough, but it has to exist.
• The maximum monthly run cost, so the gain stays a gain.
• The business owner: who decides, who uses it, who maintains it once live.
• The stop condition: at what point you decide it is not worth it, without it feeling like a drama.

What separates a demo from a production system

A demo shows the best case once. Production holds the worst cases a thousand times, at night, without you.

• Evaluations: a test set on your real cases that tells you whether a new version is better or worse, with numbers. Without them, every change is a bet (measuring an AI agent in production).
• Guardrails: what stops the system doing something irreversible, validates sensitive actions, and fails cleanly. This is the heart of production reliability.
• Observability: knowing, continuously, what the system answers, what it costs, where it gets things wrong. A system you cannot observe is a system you cannot trust.

The run cost to estimate before you sign off

Run cost is what the system costs every month once it is live: model calls, hosting, storage, maintenance. In a demo it is invisible, because the volume is tiny. At real scale it can turn a profitable project into a money pit. I always estimate it before validating a POC: expected volume times the observed unit cost, with margin. The good news is there is almost always fat to trim: on an audited LLM bill I aim for 30 to 70% savings at equal quality, by picking the right model per task, cutting needless calls and adding caching. But that belongs in the scoping, not in a panic six months later.

Adoption: the project that works but nobody uses

This is the most frustrating failure: the system works, the numbers are good, usage stays at zero. Almost always, it is because you shipped one more tool instead of slotting into the existing workflow. Nobody opens a new tab to save thirty seconds. The AI has to come to people, inside the tool they already use, at the moment they need it. That is prepared from the POC: involve the future users, deliver where they work, aim for a gain they feel immediately. A sourced answer in 2 seconds, with 70% less searching, gets adopted without anyone needing convincing. That is the kind of concrete gain I try to make visible in my work.

A path in stages

• Scoping: one use case, quantified success criteria, a business owner, an estimated run cost. Nothing coded yet.
• Honest POC: the full chain on a tiny scope, real data, real user, with evaluations from day one.
• Decision: compare against the criteria written up front. Yes, no, or adjust. No grey zone.
• Pilot: go live on a reduced scope, with guardrails and observability, on real users.
• Industrialisation: extend once the pilot holds, keeping an eye on both cost and usage.

That is the path I offer in a short format with a production-scoped AI proof of concept: a few weeks to know whether a case deserves to be industrialised, instead of committing six months blind. A successful POC is not the one that impresses in a meeting. It is the one where, by the end, you already know how it will reach production.