How Long Does an AI Proof of Concept Take? A Two-Week Plan
How long an AI proof of concept takes: a day-by-day two-week plan with pass/fail thresholds, what it costs, and what two weeks cannot prove about production.
An AI proof of concept takes two weeks when the question is narrow, the data is already accessible and someone has written down what "good enough" means. It takes six or more when any of those three is missing, and the extra time is almost never spent on the model. At UZO Lab we run these as fixed two-week sprints, and this post sets out the plan day by day, with the pass/fail numbers we would agree before starting.
One vendor's published guidance puts typical proofs of concept at 2 to 6 weeks, with 12 to 24 weeks more from proof of concept to production. Treat that as one studio's range rather than a standard, but it matches the shape we see: the prototype is the short part.
What question should the sprint answer?
A proof of concept should answer one question of the form "can this system do task X on our real data at or above level Y?" It should not try to answer whether AI is good for the business. Gartner predicted that at least 30% of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating costs or unclear business value. Three of those four reasons are visible before anyone writes code.
Good questions are small and checkable. "Can we pull the payment terms, notice period and renewal date from our supplier contracts with fewer than one error in twenty?" works. "Can AI make our team more productive?" does not.
Before day one: data, a baseline and a pass mark
We would not start the clock until three things exist. Skipping them is the usual reason a two-week sprint becomes a five-week one.
- Real examples. Our default is 50 genuine cases with the correct answer attached, including a few awkward ones. Thirty are used for tuning and twenty are locked away until day eight. Both OpenAI and Anthropic advise building tests from your real task distribution, edge cases included, rather than from invented samples.
- A human baseline. How long does the task take today, and how often is the result wrong? Without this, "92% accurate" means nothing.
- A written pass mark. Anthropic's guidance asks for criteria that are specific and measurable. For example: at least 90% of fields correct, no more than 2% wrong-and-confident, under 20 seconds per item.
Data access is the quiet blocker. If the files live behind a VPN, a procurement process or one person's laptop, fix that first. A prototype sprint that spends its first week waiting for credentials has told you something, but not what you paid to find out.
How long an AI proof of concept takes, day by day
This is the schedule we would propose for a single, well-scoped use case. It assumes one decision-maker who can answer questions within a day.
| Day | Work | Output |
|---|---|---|
| 1 | Access to data, review the 50 examples, confirm the pass mark | Signed-off evaluation set |
| 2 | Simplest possible version: one prompt, one model, no extras | First score on the 30 tuning cases |
| 3 | Add the parts the first score says are missing: retrieval, structured output, or a second pass | Second score |
| 4 | Read every failure and sort into causes | Failure list ranked by frequency |
| 5 | Checkpoint with the client: continue, narrow the scope, or stop | Written go/narrow/stop note |
| 6-7 | Fix the two most common failure causes | Re-scored tuning set |
| 8 | Run the 20 locked cases once | The number that counts |
| 9 | Measure cost and speed per item on a realistic batch | Unit economics |
| 10 | Demo, short write-up, hand over the code and evaluation set | Decision memo |
Two choices in that plan matter more than the rest. The first is running the simplest version on day two: if one plain prompt already clears 80% of the pass mark, the remaining work is targeted, and if it scores 30%, we know by Tuesday that the task or the data needs rethinking. The second is the locked set. Anything tuned against the same 30 cases will look better than it is, so the twenty held back give the only honest estimate. Both vendors' guides also warn against judging by feel; OpenAI calls this "vibe-based evals".
A pass on day eight is a good sign on twenty cases, which is a small sample. It says the approach is worth building properly. It does not say the system will hold at 90% on next quarter's inputs.
Three examples of a sensible first question
A document-heavy services firm might ask whether a model can draft the first-pass summary of an incoming engagement letter, scored against summaries its associates wrote. A product team adding a feature might ask whether ticket text can be routed to the right queue as accurately as the current manual triage. A team whose experimental data arrives as CSV files from instruments might ask whether a script can produce the weekly summary table that someone now builds by hand. Each has an existing human answer to score against, which is why each is a good candidate.
What two weeks can and cannot prove
| Two weeks can show | Two weeks cannot show |
|---|---|
| Whether the approach reaches your pass mark on real examples | Behaviour on inputs unlike the 50 you gave us |
| The most common failure causes | Rare failures; twenty cases will not surface a 1-in-200 problem |
| Rough cost and speed per item | Cost at ten times the volume, with retries and monitoring |
| Whether staff find the output useful in a demo | Whether they still use it after three months |
| Which integrations a build would need | Security review, permissions and audit requirements |
The right-hand column is the production work. Our guide to evals and guardrails for agents in production covers what that involves, and the breakdown of AI MVP costs shows where a prototype sits in the wider budget.
What it costs
Prices checked October 2026. Our AI prototyping and R&D sprint is £2,000 per week, so the two-week version above is £4,000 before any VAT. Model usage during the sprint is usually small next to that; we would estimate tens of pounds for a few hundred test runs, and we measure it on day nine rather than guess. Costs rise if the data needs cleaning first, which is why we ask for the 50 examples before booking.
If a proof of concept quote is far below that, ask what is missing: usually it is the held-out test, the cost measurement, or the handover. If it is far above, ask what the extra weeks are for. A long fixed-scope "discovery" before any model has run is rarely needed; the two-week plan answers most of the same questions with working code.
When you are not ready yet
Wait if any of these is true. You cannot name who will use the output. Nobody can say what the correct answer looks like, so two experts disagree on a third of the cases. The data cannot leave a system you cannot get into. The business case depends on the model being right every time, with no human check. In each case a sprint will produce a demo and no decision.
It may still be worth a smaller piece of work: a day or two spent building the 50-example evaluation set will tell you whether the task is well-defined. If you would rather talk it through before committing, book a free 30-minute workshop and bring one candidate use case.
Sources: Gartner, generative AI project abandonment forecast; OpenAI, evaluation best practices; Anthropic, define success criteria and build evaluations; Team 400, how long an AI proof of concept takes.
