---
title: "Prototype or MVP: What Should You Build First?"
description: "Build a prototype first when key product assumptions are uncertain; build an MVP when you need a live, usable product to learn from real use."
category: "UX & Redesign"
question: "Should I build a prototype or an MVP first?"
datePublished: 2026-10-15
dateModified: 2026-10-15
readingMinutes: 5
status: published
author: "UXPro Design Studio"
authorType: "Organization"
editorialProcess: "Prepared with AI assistance and checked against the listed sources."
authorUrl: https://uxpro.ca/about
canonical: https://uxpro.ca/blog/mvp-prototype-before-development
image: https://uxpro.ca/covers/mvp-prototype-before-development.webp
license: "Quote freely with a link to the canonical URL."
---

# Prototype or MVP: What Should You Build First?

## Key facts

| Fact | Value |
|---|---|
| Prototype | A model used to explore or test an idea; it may be paper, clickable, or coded. |
| MVP | A deliberately limited live product that real users can use to address a core need. |
| Build first | Prototype when the main uncertainty is about the experience or solution; move toward an MVP when a real service can safely answer what remains unknown. |

**Build a prototype first when you still need to learn whether a product idea or workflow makes sense. Build an MVP when you have enough evidence to put a small, real product in front of users and learn from actual use.** A prototype is a learning model; an MVP is a live product. Choose based on what you do not know and the cost of being wrong.

## What is the difference between a prototype and an MVP?

A [prototype](/glossary#prototype) is a sketch, linked screens, or coded simulation that makes an idea concrete enough to test. An MVP, or [minimum viable product](/glossary#mvp), is a first version people can use to complete a limited core task. It needs the privacy, security, accessibility, support, and reliability that task requires. “Minimum” means narrow scope, not unsafe or unfinished service. Teams use “MVP” differently, so agree what it means for your project.

Nielsen Norman Group describes a prototype as a hypothesis and notes that fidelity can vary in interactivity, visuals, and content. A realistic prototype can help test a detailed workflow; a lighter one is quicker to change. Match the fidelity to the question you need to answer. [Read NN/g’s prototype guidance](https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/).

## When should you build a prototype, and when an MVP?

| Build a prototype first when… | Build an MVP when… |
|---|---|
| The task, flow, content, or product rule is unclear. | The core task and first release scope are clear enough to operate. |
| A wrong assumption could cause costly rework. | You need evidence from real use, repeat visits, or transactions. |
| Showing or simulating the experience can answer the question. | The answer depends on real data, integrations, or repeated use. |
| You need people to react before committing to a build. | You can support real users and meet their privacy, security, and accessibility needs. |

This is a decision aid, not a universal sequence. You might prototype a risky interaction while engineering checks an integration. GOV.UK recommends prototypes that fit the question and testing risky assumptions before deciding what to take toward a live service. [See its prototype](https://www.gov.uk/service-manual/design/making-prototypes) and [alpha guidance](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works).

## Which assumption should you test first?

Write down the decision and the assumption that could change it. “Will people use this?” is broad. “Can a customer compare two options and understand the total cost?” gives you an experience to test.

For comprehension or navigation, a sketch may be enough; complex mobile interactions need a more realistic flow. If an external system must return data, add a technical check: a screen cannot prove an integration works. Questions about repeat use or transactions may need a constrained live release, if you can support it responsibly.

### Hypothetical example: planning a group trip

Imagine an app that helps friends agree on dates and trip costs. Can each person enter availability and a private limit, then understand which option fits? A clickable prototype could simulate those steps. Ask a participant to add possible weekends, compare options, explain an estimate, and say whether the group has agreed. Observe where they hesitate. This may reveal usability problems; it cannot prove adoption or estimate accuracy.

Tandem is a [UXPro studio concept](/work/tandem) that provides a visual reference: its people, trips, and costs are invented, and nobody has used or tested it. This example is hypothetical as well. It illustrates a question a prototype could explore, not evidence of demand or a Tandem result.

## How do you test a prototype with users?

Give participants a believable goal without naming the controls: “You and your friends are trying to find a weekend that works. Show me what you would do next.” Watch what they expect. Avoid explaining screens, since that can hide problems.

Before sessions, agree on the research question, relevant participants, and prototype sections to test. Use accessible tasks and include people with different access needs where relevant. GOV.UK recommends realistic, neutral tasks and observation. [Read the testing guide](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing). Separate observations from interpretations. Usability sessions can uncover usability issues; they do not establish market size or forecast business performance.

## When is it time to build the MVP?

Move toward an MVP when the core task is clear, prototype work has reduced key experience risks, and a live release can responsibly answer what remains. Keep the first scope small enough to support. Plan how it will handle real data, account access, errors, security, privacy, accessibility, support, and measurement.

Prototype code may not have production security or performance. GOV.UK warns teams not to copy prototype code straight into a live service. Carry forward the research and design decisions, then build and review production behaviour for the product’s needs.

## What should the handoff to developers include?

Give the team the prototype, research question, task script, findings, open assumptions, and recommended next step. Add annotated flows and error or empty states for developers. Label simulated behaviour so screens are not mistaken for working features.

If evidence supports a release, translate the chosen flow into scope and acceptance criteria with engineering. If it does not, revise or stop before more build cost accumulates. UXPro can help through [UX and UI design](/services/ux-ui-design) or [mobile app design](/services/mobile-app-design).

## FAQ

### Is a prototype the same as an MVP?

No. A prototype explores or tests an idea and may simulate parts of it. An MVP is live and usable, with limited scope. Agree what each deliverable can do.

### Can I launch a prototype to real customers?

Only if it has the privacy, security, accessibility, reliability, and support needed for real use. Restrict a research prototype so people do not mistake it for a live service.

### How do I know when to move from a prototype to an MVP?

Move forward when the core task and first release scope are clear, with a credible plan for serving real users. You need to know which uncertainties a live release can responsibly answer.

### What should a prototype handoff include?

Include the prototype, research question, findings, open questions, first-release scope, and annotated flows developers need. Label simulated behaviour and unresolved decisions.

## Next step

Write your riskiest assumption in one sentence, then choose the smallest test that could change your next decision. That gives design and engineering a useful brief, whether the answer is a few screens, a technical check, or an MVP.

## Sources

- [UX Prototypes: Low Fidelity vs. High Fidelity](https://www.nngroup.com/articles/ux-prototype-hi-lo-fidelity/) (accessed 2026-10-15)
- [Making prototypes](https://www.gov.uk/service-manual/design/making-prototypes) (accessed 2026-10-15)
- [Using moderated usability testing](https://www.gov.uk/service-manual/user-research/using-moderated-usability-testing) (accessed 2026-10-15)
- [How the alpha phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-alpha-phase-works) (accessed 2026-10-15)