Prototype vs MVP: what should you build first?

A prototype is a model built to answer a question about a product. An MVP, or minimum viable product, is a first usable version that delivers a coherent piece of value in real conditions. The right starting point depends on what you need to learn. If you are unsure whether a flow makes sense, a prototype may be enough. If you need to understand repeated use, you may need a working product.

Neither label tells you what is included. A prototype can range from a rough sequence of screens to a realistic coded experience. Teams use “MVP” for everything from a narrow live service to an unfinished version of their whole roadmap. Agree the question, the users and the expected operating conditions before agreeing the label.

1. What can a prototype help you decide?

Use a prototype when the decision depends on something you can represent and observe. Can someone understand a new workflow? Can they find the next action? Does the proposed information structure match how they think about the task? Build only the detail those questions depend on.

A clickable flow might answer a navigation question. A working browser prototype may be better for an interaction that depends on real content, resizing or complicated states. A technical proof of concept can investigate an integration separately. Choose the form after identifying the risk, rather than treating the most polished prototype as the most useful one.

Be explicit about what is simulated. A convincing payment screen does not prove payment processing works. A dashboard filled with sample data does not prove the integration is reliable. Keep a short list of these limits beside the prototype so a successful demonstration does not become accidental evidence for claims it never tested.

2. What makes an MVP viable?

An MVP needs to let its intended users finish a meaningful task. That may be a much smaller task than the eventual product will support, but it needs an end. A tool that collects a request and leaves someone to wonder whether it was received has not completed the experience.

• A defined user and a narrow reason to use the product.
• A complete core flow, including the necessary failure and recovery states.
• Appropriate security, access controls and data handling for real use.
• A way to identify failures and help the people affected.
• A meaningful measure of use and a plan to act on what you learn.

You can reduce scope without ignoring these responsibilities. A restricted pilot, fewer integrations or a manually supported step can make a smaller launch workable. Tell users what is available and who handles the gaps. A manual operation is a design choice to manage, not evidence that the product is already automated.

3. How do you decide which to build next?

Write the decision in one sentence. Then ask what evidence would change your mind. If the answer is “watch people try the proposed setup”, prototype it. If it is “see whether teams return to use this every week”, a single demonstration cannot answer it. You need a setting where recurring use is possible.

Sometimes neither is the next step. If you do not know who has the problem or whether they want to solve it, begin with conversations and the current workflow. GOV.UK’s discovery guidance makes room for stopping after investigating a problem. Commercial teams need that option too. Learning that an idea should not be built is a useful outcome.

4. What should you keep after a prototype test?

Keep the observations, the revised decisions and the unresolved questions. Keep reusable code only after reviewing whether it meets the needs of the production system. Prototype code is often deliberately constrained; preserving every shortcut can cost more than rebuilding the small part that was proven useful.

At Refract, the product sprint ends with a prototype, user feedback and a plan for the next build. That gives the team a concrete basis for deciding whether to invest further, reduce the scope or change direction. The objective is a better decision about the product, including the decision to wait.

5. Questions

Can a coded prototype become the MVP?

Sometimes. Review its architecture, accessibility, security, data handling and operating limits before relying on it in production. A convincing demonstration does not establish production readiness.

Does an MVP need every planned feature?

No. It needs a coherent task that delivers value to its intended users. Cut optional scope before cutting the states and support needed to complete that task safely and reliably.

Can you test demand with a prototype?

It can help people understand and respond to a proposition. Positive feedback on a demonstration does not establish willingness to pay, retention or repeat use; choose additional evidence for those questions.