A 30-day AI proof of concept that produces a decision, not a demo
The purpose of a proof of concept is to produce a decision cheaply. Time-boxing it to a month forces the scope discipline that makes that possible.
By Quality AboveAll · · 8 min read
- Define the go or no-go criteria in week one, before anyone can be attached to the outcome.
- Build the thinnest thing that tests the risky assumption, not a small version of the final product.
- End with a written recommendation, including the honest option of stopping.
Week one: scope, baseline and criteria
Pick one task with one user group. Measure how it is done today: time, volume, error rate. Then write the decision criteria explicitly, what accuracy, time saving or acceptance rate would justify continuing, and get agreement on them before anyone has an emotional stake.
Assemble thirty to fifty real examples with expected outputs while you are at it. This becomes your evaluation set and it is the artefact that makes the final week's decision defensible. Readiness questions are covered in AI readiness assessment.
Week two: build the thin version
Build only what tests the assumption you are least sure about, usually whether the model can perform the core task acceptably on your real inputs. Skip authentication, polish, edge cases and scale. A script an engineer runs is a perfectly valid proof of concept.
Resist the pull toward building a small version of the finished product. Every hour spent on interface work during a proof of concept is an hour not spent learning whether the idea works, and it makes the sunk-cost pressure worse if the answer turns out to be no.
A proof of concept is an experiment with a deadline. If it starts acquiring a login screen, it has stopped being one.
Week three: run it against reality
Score against your evaluation set and, more importantly, put it in front of the people who do the task. Their reaction to real outputs surfaces objections no metric captures, and it does so while changing course is still cheap.
Record the failures carefully, not just the rate. Understanding whether errors cluster in one category or scatter randomly determines whether a narrower scope would succeed, which is often the most valuable output of the whole exercise.
Week four: decide and write it down
Compare results against the week-one criteria and write a short recommendation: proceed, proceed with a narrower scope, or stop. Include the measured numbers, the cost estimate at real volume, and the risks you found.
Stopping is a successful outcome. Spending four weeks to avoid a six-month project that would not have worked is exactly what a proof of concept is for, and teams that treat it that way make better decisions than teams for whom the only acceptable answer is yes.
What comes after a yes
A green light starts the production work, which is a different and larger project: evaluation infrastructure, guardrails, permissions, cost controls and monitoring. The proof of concept has told you the core assumption holds, not that the feature is nearly built.
Set that expectation with stakeholders explicitly, because a convincing prototype creates the impression that most of the work is done. The gap is mapped in pilot to production, and the cost picture in what an AI project costs.
Frequently asked questions
Is 30 days realistic?
For a single well-scoped task with data you already have, yes. If scoping alone takes three weeks, that is a signal the use case is not clear enough to build against yet.
Who should be involved?
One or two engineers, the owner, and the people who do the task today. Keeping it small is what makes the timeline achievable.
What if results are borderline?
Look at where errors cluster. A narrower scope that performs well is usually a better outcome than proceeding with a broad feature that is mediocre everywhere.
Want to test an AI idea properly before committing a budget to it? A free 30-minute consultation will scope a proof of concept with real decision criteria.
