AI Proof of Concept Cost: Scope, Evidence and the Gap to Production

A proof of concept exists to answer one question cheaply: can this approach work here. It becomes expensive when it acquires a user interface, additional data sources, edge case handling, and an audience — at which point it is an unplanned project with none of the governance a planned one would have. This guide covers keeping it small and conclusive, drawing on FISTA Solutions' AI enablement work. It complements ai pilot cost and ai proof of concept guide.

What is a PoC actually for?

Answering a feasibility question. Can this approach reach the accuracy this task requires, on our data, within the constraints that will apply.

It is not for building something usable, demonstrating capability to stakeholders, or exploring what might be possible. Those are different activities with different scopes, and conflating them is why proofs of concept expand until they resemble products.

Element	In a PoC	Deferred
The feasibility question	Yes	—
Real data	Yes	—
Measured result against criteria	Yes	—
Production permission model	Assessed	Built
User interface	Minimal or none	Yes
Error handling and edge cases	No	Yes

Why is scope creep the main cost driver?

Because each addition looks small. A simple interface so stakeholders can try it. A second data source since the first was incomplete. Handling for the case someone mentioned. None is unreasonable and together they change the nature of the exercise.

The discipline that works is writing the question down, agreeing it, and treating anything that does not serve it as out of scope — including things that would make the result more impressive.

Why does data access determine the schedule?

Because approvals, extractions, and permissions take longer than building. Data owners must agree, privacy review may be required, and the extraction itself may need engineering from a team with other priorities.

Beginning that conversation on day one, in parallel with everything else, is the single most effective scheduling decision. PoCs planned on engineering estimates slip before any engineering begins.

What is the difference between evidence and demonstration?

Evidence is a measured result against criteria stated beforehand: this approach achieved this accuracy on this labelled set at this cost and latency. It can be discussed, challenged, and acted on.

A demonstration is something that worked when it was shown. It persuades people who wanted to be persuaded and convinces nobody else, which means it does not support a decision. See what is an evaluation rubric.

How large is the production gap?

Usually larger than the PoC itself. Permissions and entitlement filtering, integration with real systems, error handling, evaluation running in operation, monitoring, incident response, and support are all absent from a PoC and all required in production.

Estimating that gap at the point the PoC succeeds — rather than treating production as an increment — is what prevents the pattern where organisations accumulate successful proofs of concept and deploy none.

What should the PoC deliberately not prove?

Scale, reliability, and completeness. Those are production concerns and attempting them in a PoC consumes the budget that was meant to establish feasibility.

What it should establish about production is whether any constraint makes the approach infeasible — a permission model that cannot be satisfied, a latency requirement that cannot be met, a residency rule that rules out the provider. Those are feasibility questions and belong in scope.

How long should it take?

Weeks. A PoC running for months has become a project, and its findings arrive after the decision they were meant to inform has been made another way.

What should you do first?

Write the feasibility question and the criterion for answering it in one sentence each, and have the sponsor agree them in writing. If that cannot be done, the exercise is not ready to start and running it will produce a demonstration rather than an answer.

What happens when a PoC fails?

It has done its job, cheaply. A proof of concept that establishes clearly that an approach will not reach the required quality on the available data has saved the cost of a build, and that outcome should be treated as a success rather than as a write-off.

Organisations that treat PoC failure as failure create pressure to declare success, which produces optimistic conclusions and expensive builds on foundations nobody believed in. Making the negative outcome acceptable is what keeps the exercise honest.

Who should run it?

A small team with the capability and the access, working closely with whoever owns the process. A PoC run entirely within a technology function produces a result the business cannot evaluate; one run with the people who do the work produces a judgement about whether the output is actually usable, which is the question that matters.

How FISTA Solutions helps

FISTA Solutions scopes proofs of concept to a single agreed feasibility question, starts data access on day one, produces measured evidence against stated criteria rather than demonstrations, assesses production constraints that could make the approach infeasible, and estimates the production gap honestly before declaring success, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 47% efficiency gains.

To prove feasibility without building an unplanned project, message FISTA on WhatsApp, or read ai pilot cost.