Skip to the main content

5 min readPublished Last updated

Prototype or MVP: What Should You Build First?

Written by UXPro Design Studio. Kitchener, ON. Prepared with AI assistance and checked against the sources listed below.

Should I build a prototype or an MVP first?

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.

A prototype journey from a question through a test screen to a product decision.
Key facts
PrototypeA model used to explore or test an idea; it may be paper, clickable, or coded.
MVPA deliberately limited live product that real users can use to address a core need.
Build firstPrototype when the main uncertainty is about the experience or solution; move toward an MVP when a real service can safely answer what remains unknown.

What is the difference between a prototype and an MVP?

A prototype is a sketch, linked screens, or coded simulation that makes an idea concrete enough to test. An MVP, or minimum viable product, 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.

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

Table · scrolls sideways

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 and alpha guidance.

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 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. 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 or mobile app design.

What people ask next

The questions this guide gets asked after it has been read. Each answer is on the page, so the FAQ markup and the visible text are the same words.

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.

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.

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.

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

Next step

What to do with this.

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.

What you get

We read your site by hand and reply with written findings.

No turnaround time is published yet. We would rather say nothing than publish a window we have not tested.

Written by

UXPro Design Studio

UXPro Design Studio · Kitchener, ON

Prepared with AI assistance and checked against the sources listed below.

Sources

Terms in this guide

Usability testing, Prototype, Minimum viable product — defined, with sources, in the glossary.

For AI agents

Read as Markdown — the same guide as plain text, served as text/markdown. The feed for every published guide is at /blog/rss.xml.