AI MVP vs prototype: what should you build first?

Founders often ask for an MVP when they actually need a prototype. Others spend weeks polishing a prototype when the real uncertainty is whether anyone will use or pay for the product. AI adds another option: a technical proof of concept that tests whether a model can perform the core task with acceptable quality and cost.

These builds are not stages that every product must complete in order. They are different instruments. Choose the one that answers your most expensive unanswered question.

The short definitions

Prototype

A prototype represents the experience. It may be a sequence of designed screens, a clickable interface, or a partially functional front end. It helps people understand and react to the workflow without requiring production infrastructure.

Proof of concept

A proof of concept tests technical feasibility. For an AI product, it may run representative inputs through one or more models, retrieval methods, prompts, or processing pipelines and compare the results against an evaluation set.

Concierge test

A concierge test delivers the proposed outcome manually or semi-manually. Users experience the value while the founder performs work behind the scenes. This tests demand and workflow before automation.

Minimum viable product

An MVP is a usable product release. Real users can complete the core journey and generate behavioral evidence. It needs enough reliability, interface quality, data handling, and support to make the learning credible.

Choose a prototype when the workflow is unclear

Build a prototype if you need to answer questions such as: Do users understand the concept? Which information do they need before trusting the output? Where should review happen? Does the proposed flow match the way the task is performed now?

A prototype is especially useful when multiple stakeholders imagine different products. Seeing the same screens forces vague agreement into concrete discussion.

Do not use a prototype to claim that the AI works. A polished simulated result can validate the interaction while hiding model failures, latency, cost, or data limitations.

Choose a proof of concept when the AI is uncertain

Build a proof of concept if the central question is technical: Can the available models produce acceptable results on our real inputs? Can retrieval find the correct source? Can an image workflow preserve the product attributes that matter? Can the task run within the latency and cost limit?

The proof should use a representative evaluation set, not a handful of examples selected because they work. Define scoring criteria before comparing approaches. Record failure patterns as carefully as successes.

A proof of concept may have an ugly interface or no user interface at all. That is acceptable when the purpose is to reduce technical risk. It becomes a problem when teams mistake feasibility for product value.

Choose a concierge test when demand is uncertain

If you do not know whether users care enough about the outcome, provide it manually. A founder can collect the input through a form, perform the analysis with existing tools, review the result, and deliver it in a familiar channel.

This approach reveals what users submit, how much clarification they need, which parts of the result matter, whether they return, and whether the outcome is worth paying for. It also creates examples that can later become an evaluation set.

The risk is hidden labor. Track the time and judgment required for each result. If the service works only because an expert spends three hours repairing every output, automation may be harder than the customer experience suggests.

Choose an MVP when behavior is the question

Build an MVP when you have enough confidence in the problem, workflow, and technical path to test a real product. The remaining questions are behavioral: Will users complete the task without hand-holding? Will they return? Does the product fit into the next step of their work? Will they pay, invite a teammate, or provide the data required?

An AI MVP needs more than a model call. It requires input handling, understandable waiting and error states, output review, corrections, basic privacy controls, usage measurement, and a route for support. These elements make the test believable.

A practical decision sequence

1. If the problem itself is uncertain: conduct interviews or run a concierge test.
2. If the experience is uncertain: test a prototype with representative users.
3. If technical quality or economics are uncertain: run a proof of concept on real data.
4. If user behavior and demand are uncertain: build a focused MVP.

You may combine methods. A small AI project can pair a technical proof with a clickable prototype, then conduct a concierge pilot before committing to a production MVP. The important rule is to keep each test tied to a specific decision.

What each build should contain

A useful prototype brief

Primary user, scenario, key screens, tasks to test, assumptions being examined, and a research script. Keep fake data realistic and label simulated AI behavior internally.

A useful AI proof brief

Representative dataset, expected output, evaluation criteria, unacceptable failures, approaches being compared, latency limit, cost limit, and privacy constraints.

A useful MVP brief

Primary user, painful job, end-to-end workflow, real inputs, human review boundary, success metric, first audience, launch support, and explicit exclusions. The 12-decision AI MVP framework covers each item.

The expensive mistake: combining all uncertainty

The worst first build tries to discover the market, invent the workflow, solve unknown AI behavior, integrate five systems, and launch a production platform at the same time. When users struggle, the team cannot tell whether the problem, experience, model, or implementation is at fault.

Separate uncertainties where possible. A week spent proving that a model fails on the critical input can prevent months of interface work around an impossible promise. A simple concierge test can reveal that customers want a reviewed service rather than an automated dashboard.

The decision rule

Write down the next decision in one sentence: “After this test, we will decide whether to...” Then choose the least expensive artifact that can produce credible evidence for that sentence.

That may be a prototype. It may be 30 manually delivered reports. It may be a benchmark script. It may be a real MVP. The maturity of the artifact matters less than the quality of the decision it enables.