AI Proof of Concept

The terms get used loosely, so it is worth being precise about what you are buying. A proof of concept answers a single, sharp question — will this approach work on our data, for this task, well enough to matter? — as cheaply and quickly as possible, usually with a narrow slice of real data and a handful of users. A pilot is the next step: taking something that has proven the concept and running it in a limited but genuinely live setting to see whether it holds up in real workflows, with real edge cases, over real time. The mistake we see constantly is businesses commissioning a full build when a two-to-four-week proof of concept would have answered the make-or-break question for a fraction of the cost. The whole value of a POC is that it is designed to fail fast and cheap if the idea does not hold, so you find out before, not after, you have spent the serious money.

POC purgatory is the state where a pilot neither dies nor ships — it just lingers, gets extended, absorbs a bit more budget each quarter, and never faces a real decision. It is the single most common failure mode in corporate AI, and the cause is always the same: no success criteria and no kill criteria were agreed at the start, so there is nothing to measure the result against and no honest moment to stop. We prevent it structurally. Before a single line is written we agree, in writing, exactly what “it worked” means — a specific, measurable threshold — and exactly what “it did not” means, the point at which we recommend stopping. We time-box it and fix the cost. And we design the readout as a genuine go/no-go, where “no” is a legitimate, valuable outcome rather than a failure to be spun. A POC that cannot end is not a POC, it is an open-ended expense.

It has to be specific, measurable, and set before you see the results, because a metric chosen afterwards is just a story you tell about whatever happened. “The model feels good” is not a metric. “Correctly extracts the invoice total on at least 95% of a held-out set of 200 real invoices, with every error being a safe under-read rather than an over-read” is. The best metrics are tied to the actual business decision the system will drive, include a quality bar that reflects the real cost of being wrong, and are measured against real data the model has not seen, not a cherry-picked demo. A good metric also states what happens at the boundary: what accuracy is good enough to proceed, what is a clear stop, and what is the grey zone that needs a judgement call. Agreeing that up front is uncomfortable and it is exactly what stops a POC drifting.

This is so common it is almost the default outcome, and it is usually because the POC proved the wrong thing. A pilot run by data scientists on a clean, curated dataset, in a notebook, with no integration and no real users, can absolutely prove that a model can do a task. What it does not prove — and what actually determines whether it ships — is whether it works on messy production data, whether it connects to the systems your staff already use, whether the accuracy holds at real volume, whether anyone will change their workflow to use it, and whether it can be run and maintained without the person who built it. A proof of concept that ignores the path to production proves feasibility in a vacuum and then hits every one of those walls at once. We scope POCs to test the risky, production-relevant question, not the easy academic one, precisely so a success is a success that can graduate.

Several situations, and we will point them out rather than sell you a POC anyway. If the capability is already well proven for your exact use case — the task is common, off-the-shelf tools do it reliably, and the only real question is configuration — a POC is just a slow way to buy something you could adopt directly. If the honest blocker is not feasibility but your data, your process or your systems, then a POC of the AI proves nothing useful; the work is upstream and a POC will just confirm the AI cannot see data that is not there. If the thing you would learn will not change your decision either way, there is no point running it. And if the use case is so small that the POC costs more than just building the whole thing, skip straight to building. A POC is a tool for buying down a specific, expensive risk. Where there is no such risk, it is overhead.

Most are scoped to roughly two to four weeks and priced as a fixed-cost engagement, so you know the number and the end date before it starts — that fixed box is half the point. The exact figure depends on how much data wrangling and integration the honest test requires, which we establish up front rather than discovering halfway through. Before any POC, the initial consultation is free and often the most useful step: a good proportion of the time we conclude that a POC is not the right next move — the capability is already proven, or the real problem is upstream — and we say so. Where a POC is warranted, it is deliberately far cheaper than a full build, because its entire job is to tell you whether that build is worth commissioning. If it proves the concept, we can build it; if it does not, you have spent a small, fixed amount to avoid a large, open-ended one.