How to scope an AI proof-of-concept so it ends in a decision
Published
Decide what the PoC is for before you decide what it does
The person holding the budget is not asking for a prototype. They are asking whether to commit to a full build. A proof-of-concept that does not answer that question is an expense with a screen recording at the end of it.
So scope for the output that counts: a decision someone can defend in a room. Three things make a decision defensible. A system that ran on real inputs. An honest read on what it takes to scale it. And the people who have to sign off having watched it run and asked the hard questions.
Everything below is about protecting those three from the thing that eats them, which is a scope with no end condition.
Define done as a number, before anything is built
Most PoCs that turn into science projects were never given an end. They were given a direction. Direction extends forever. The model can always be a little better next week, and there is always one more edge case worth handling.
Agree on the threshold upfront. What accuracy, on which document set, judged by whom. What throughput. What result means yes, and what result means no.
That second half is the one people skip. If no outcome would stop the project, you have not defined a test. The threshold does not have to be production-grade. It has to be specific enough that two people looking at the same output agree on whether it was met.
Run it on your data, not on the sample you would send a vendor
The demo file is the one that already works. It is clean, it is representative, and somebody chose it. Real inputs are the scanned page, the spreadsheet with three header rows, the contract where the clause that matters sits in an appendix nobody indexed.
A prototype that only works on the curated sample has proved that the curated sample exists.
Scope the PoC around the smallest slice that puts the risky assumption in contact with real data. Not the whole workflow. The one part where, if it fails, the idea is wrong. If you already know the OCR works, do not spend two weeks proving the OCR works.
Make the scale-up plan part of the deliverable
A proof-of-concept that reports only success is a sales document. The useful version reports where it struggled, and it is worth writing that requirement into the scope before the work starts:
- where the gaps were, and which of them are structural rather than a matter of more effort
- what stays fragile once volume goes up
- an effort estimate to get from prototype to production
- what it will cost to run, at your volume
That document is what the budget holder actually reads twice. The prototype convinces the room. The scale-up plan is what survives the room and gets argued about in the finance meeting a week later.
Then have the team watch it run live rather than watch a recording. People find the objection that matters when they can ask the follow-up question.
Why weeks is realistic, and where the speed stops
Two to four weeks is a workable window for this shape of work, and the reason is unglamorous. AI coding agents produce most of the mechanical volume under an engineer’s supervision, and the engineer reviews, corrects, and owns every line that ships. On one of our internal demos, built for ourselves and not for a client, we measured about two hours of agent wall-clock time against a human estimate of roughly 19 to 24 hours for the same scope.
Be careful with that ratio. It holds for plumbing, glue, and well-covered patterns. The parts that need judgement still take a person the time they take. The speed comes out of the mechanical volume, not out of skipping the thinking, and anyone quoting a blanket multiplier across a whole project is quoting a marketing number.
The commercial shape follows the same logic. A PoC is small and well defined, which is exactly the condition under which a fixed scope is honest: you can describe the finished thing before it exists, and estimate against it. Fuzzier work belongs in a paid Discovery (3–5 days, $1,500–3,000, priced upfront) that produces artefacts and a costed plan. A fixed price on something nobody has scoped yet is a promise about a thing neither side can describe.
Scoped this way, a PoC ends where it should. A room full of people who have seen the thing run, and who can now say yes or no for reasons they can put in a sentence.
If you want that run on your own documents, that is our AI proof-of-concept service.