MVP vs prototype: what should you build first?

A prototype helps you test an idea or interaction. A minimum viable product, or MVP, lets real users complete a useful task so you can learn from actual use. Build a prototype when the design is uncertain; build an MVP when you are ready to deliver and operate a small product. If the uncertainty is technical, a focused proof of concept may come first.

These are different purchases. A polished demonstration does not necessarily include the data handling, permissions, release process, or support that a working product needs. Before comparing development proposals, name the question you want the work to answer.

Prototype, proof of concept, and MVP compared

The labels vary between teams. Agree the intended result rather than relying on the name in a proposal.

On a narrow screen, scroll the table sideways to read all columns.

Deliverable	Question it answers	What you should be able to observe	What it does not establish
Prototype	Can users understand and complete this proposed interaction?	People try a limited journey; you see where they hesitate or misunderstand it.	Reliable integrations, production operation, or willingness to pay.
Proof of concept	Can a specific technical approach work under the relevant constraints?	A narrow experiment demonstrates a capability, such as reading the required data from a provider.	A complete product or a usable customer experience.
MVP	Can a small working product deliver the intended value to its first users?	Real users complete the core task; you collect feedback and observe use.	Product-market fit, profitable acquisition, or readiness for every future customer.

A prototype can be a paper sketch, a clickable design, or a limited coded interface. Its usefulness comes from what you learn, not how much code it contains. The GOV.UK alpha guidance makes the same practical distinction: test risky assumptions with prototypes rather than treating experimental code as production software.

An MVP can be offered to a small invited group. It does not need every feature, but the people using it need a way to complete the promised task and obtain help when it fails.

Choose the smallest deliverable that resolves the uncertainty

Ask what could make the next development commitment wasteful.

• The need is uncertain: talk to intended users and inspect their current work. Neither a prototype nor an MVP replaces discovering whether the problem matters.
• The interaction is uncertain: use a prototype to test the difficult steps. You may not need to design the entire product to learn where people get stuck.
• The integration is uncertain: run a proof of concept with representative data and realistic access. A successful request to a test endpoint does not prove the whole integration is ready.
• The value in real use is uncertain: consider an MVP with a small, complete journey and a plan to observe what happens after release.

You do not have to buy all three in sequence. If the workflow is already understood and the technology is established, a separate prototype may add little. If a required integration cannot work, building the rest of the product first is the wrong order.

One booking idea, three different scopes

Consider a hypothetical booking product. Customers need to choose an available appointment, receive confirmation, and change the booking if necessary. This is an illustrative example, not an AL+ client result.

A prototype could show appointment selection, the confirmation screen, and the cancellation path. Test whether people understand the choices and whether staff can use the proposed administrative view. The appointments and confirmations can be simulated if that is explained to participants.

A proof of concept could examine the calendar provider. Can the application read availability, create a booking, and recognize a conflicting change using the access the business can obtain? Document what the experiment tested, the environment used, and what remains untested.

An MVP could let a limited group make real bookings for one service at one location. It would also need the relevant rules for time zones, conflicts, cancellation, staff access, and failure recovery. A large reporting dashboard may wait; preventing two people from booking the same slot may not.

The decision is about the uncertainty and the promised outcome. “Only five screens” is not enough to distinguish those scopes.

A brief you can use before asking for a quote

Fill in these six lines. If you cannot answer one, record it as an open question rather than an assumption.

1. User and task: who needs to do what, and what do they do today?
2. Question to answer: what uncertainty must this piece of work resolve?
3. Deliverable: prototype, technical experiment, or a working first release; explain why.
4. Evidence of completion: what behavior or observation would let you accept the work?
5. Scope and exclusions: which users, devices, integrations, and failure cases are included; what can wait?
6. Next decision: what will you do if the result supports the idea, contradicts it, or is inconclusive?

For the booking example, an acceptance statement might be: “An invited customer can book a genuinely available slot, receive confirmation, and cancel it; staff can see the change.” That describes product behavior. “The app has a booking screen” describes an interface and leaves the important work unresolved.

Use the MVP development cost guide to compare estimates for the same deliverable and exclusions.

What an MVP still needs after the feature list is reduced

Small scope does not remove the responsibilities created by real users and real data. Identify which apply before launch:

• Access rules and correct handling of the information the product stores.
• A repeatable release process and control of the repository and service accounts.
• A way to notice failures and recover important work or data.
• A support contact and someone responsible for the next release.
• A plan for collecting feedback that informs a specific product decision.

Those requirements should match the actual release. Do not add infrastructure for imagined scale, but do not omit a recovery path for information you cannot afford to lose. The GOV.UK beta guidance offers a useful model: invite a limited group, learn from real use, and plan the capacity to support that learning.

Can you turn a prototype into an MVP?

Sometimes. First inspect what the prototype actually contains. The interface may be reusable while simulated data, temporary authentication, or local-only setup must be replaced. Code written for an experiment may be cheaper to discard than to make dependable.

Ask the developer to separate reusable work, missing production work, and unresolved assumptions. An AI-built prototype needs the same review; a convincing demo is evidence that the demo works, not that the product is ready for customers.

Discuss the next useful release

AL+ provides MVP development for founders who need one complete first journey and clear ownership after launch. Send the six-line brief, any existing prototype, and your budget or timing constraints.

Email AL+ about your prototype or MVP. We can discuss which deliverable addresses the question you need to answer.