AI MVP and Rapid Prototyping
Building the smallest thing that answers the question you are actually stuck on — whether it works, whether anyone wants it, or whether the economics hold — with a kill criterion agreed before we start.
Most AI prototypes fail at the handover rather than the build. They demo beautifully on curated examples, everyone is enthusiastic, and nobody can say what was proven — because the question was never written down and there was no threshold at which the answer would have been no.
An AI prototype is a deliberately limited build whose purpose is to answer a specific question before larger investment: whether the capability is technically feasible on your data, whether users want it, or whether the unit economics work. It is scoped to that question and evaluated against a criterion set in advance.
Three questions, three different prototypes
| Question | What we build | How it is judged |
|---|---|---|
| Is it feasible on our data? | A thin technical spike, no interface | Measured accuracy against a defined bar |
| Does anyone want it? | A realistic interface, model possibly faked | Observed user behaviour, not stated enthusiasm |
| Do the economics work? | Instrumented realistic usage | Cost per task at projected volume |
| Can we operate it? | End-to-end thin slice | Latency, failure behaviour, review load |
The second row surprises people. Where the question is desirability, the model can be simulated — a human behind the interface, or a scripted response — and the answer is just as valid for a fraction of the cost. Building a real model to test whether anyone wants the feature is a common and expensive way round.
How we keep it honest
Write the question and the kill criterion first
One question, and the threshold below which the answer is no — agreed and signed before the build. Without it, every prototype concludes 'promising, needs more investment', which is the outcome that costs the most over time.
Use real data, including the awkward cases
A prototype on clean sample data proves nothing about production. We ask for messy, representative examples including the ones that go wrong, because those determine the real accuracy figure.
Test with actual users, and watch rather than ask
People are polite about prototypes and enthusiastic in interviews. What matters is whether they use it when they have a real task, whether they trust the output, and what they do when it is wrong. Stated intent is a weak signal and behaviour is a strong one.
Instrument cost from the first request
Tokens, calls and latency per task, extrapolated to projected volume. Prototypes that are never costed produce approvals that later collide with an inference bill nobody modelled.
Make it disposable, and say so
Prototype code is written to answer a question quickly, not to be extended. We label it clearly, and we say plainly which parts can carry into production and which must be rebuilt — because a prototype quietly promoted to production is a durable source of technical debt.
A prototype that says no has done its job
The cheapest possible outcome is discovering in six weeks that something does not work, rather than in eighteen months. We report negative findings plainly, and a meaningful share of these engagements end with a recommendation not to proceed. That is the value, not a failure of the engagement.
What you get at the end
- A verdict against the criterion you agreed at the start, stated plainly as proceed, proceed with changes, or stop.
- Measured accuracy on your own data, reported by case type rather than as an average.
- Observed user behaviour from real tasks, including where people did not trust the output.
- Cost per task at projected volume, with the levers that would change it.
- What must be rebuilt for production, honestly separated from what can carry forward.
- The working prototype and its code, yours to keep whatever the verdict.
How the engagement runs
The question and its kill criterion are signed off before any code is written.
Question and criterion
The single question defined; the threshold for a no agreed in writing with the sponsor.
Data and setup
Real representative data assembled including awkward cases; evaluation approach agreed.
Build
The smallest thing that answers the question, instrumented for cost and latency from the first request.
User testing
Real users with real tasks, observed rather than surveyed.
Verdict and handover
Findings against the criterion, production rebuild assessment, code and prototype handed over.
What you receive
A clear answer to one question, including when the answer is no.
Working prototype
Yours to keep, with its code, whatever the verdict.
Verdict against the criterion
Proceed, proceed with changes, or stop — stated plainly against the agreed threshold.
Accuracy measurement
On your real data, by case type rather than as an average.
User testing findings
Observed behaviour with real tasks, including where trust broke down.
Cost model
Per task at projected volume, with the levers that move it.
Production assessment
What carries forward and what must be rebuilt, stated honestly.
Is this the right engagement?
Worth being direct. AI MVP and Rapid Prototyping is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- A specific AI feature is proposed and its feasibility is unknown.
- A decision is blocked on evidence nobody has gathered.
- Investment approval requires proof rather than a business case.
- Real users are available to test with.
- You would accept a recommendation not to proceed.
Choose something else if
- The feature is proven and needs building properly. See AI-native SaaS development.
- You want a demo for a pitch rather than an answer to a question.
- No real data or real users can be made available.
- A negative result would not be accepted, which makes the exercise theatre.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
How long does an AI prototype take?
Four to ten weeks depending on the question. A pure feasibility spike can be three or four; adding a realistic interface and user testing takes longer. Anything running past ten weeks has usually stopped being a prototype and become a small product without anyone deciding to.
Do we need a real model to test whether users want it?
Frequently not. Where the question is desirability rather than feasibility, the model can be simulated — a person behind the interface, or scripted responses — and the answer is just as valid at a fraction of the cost. Building a real model to test demand is a common and expensive detour.
What happens to the prototype code?
It is yours, and we tell you plainly which parts could carry into production and which must be rebuilt. Prototype code is written to answer a question quickly rather than to be extended, and quietly promoting it to production is a reliable source of technical debt.
What if the prototype fails?
Then it did its job for a fraction of what finding out later would have cost. A meaningful share of these engagements end with a recommendation not to proceed, which is why the kill criterion is agreed in writing at the start — so a negative result is a conclusion rather than an argument.
How is this different from a proof of concept?
In practice the terms overlap. What matters is the discipline: one question, a threshold agreed in advance, real data, real users, and a verdict rather than a demo. See also AI proof of concept where the framing is a business case rather than a product feature.
Often paired with this
Most clients combine two or three engagements from the AI Product and Experience Design pillar. These are the ones that most often run immediately before or after.
AI Product Strategy
What to build and what it is worth, priced per user and designed around the errors the model will make.
Read more →UX Design for AI Interfaces
Designing for probabilistic output — uncertainty shown usefully, failure paths designed, correction made easy.
Read more →AI-Native SaaS Development
Multi-tenant AI done properly — data isolation, per-tenant cost, evaluation gating releases, pricing that holds.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.