Prototype vs MVP: What Should Founders Fund First?

Use six evidence gates to decide whether to fund a clickable prototype or a coded minimum viable product first.

Choose a prototype when your biggest unknown is the user journey: who acts, what they need to understand, and whether the proposed flow solves the right problem. Choose an MVP when the journey is credible but you still need evidence from working software, real data, integrations, permissions, payments, or day-to-day operations.

The two milestones are not smaller and larger versions of the same thing. A prototype is a learning instrument. An MVP is an operating product with a deliberately narrow promise. Funding the wrong one can produce polished screens that prove nothing, or production code built around an untested workflow.

This decision sits after early problem interviews and before a full product build. If the problem itself is still uncertain, start with how to validate a product idea. If you already know an MVP is the right milestone and need to choose its first feature, use the MVP feature-prioritisation guide.

Prototype vs MVP in one table

A useful prototype may look realistic without being deployable. A useful MVP must be deployable, supportable, and measurable, even when its scope is small. GOV.UK advises teams to make prototypes only as complex as needed to test an idea and to avoid spending time making them work like a finished service. That is the right boundary for the prototype stage.

The six evidence gates

Treat each gate as a question that must have a clear answer. If the first three gates are weak, funding code usually creates more assumptions, not more evidence. If the first three are strong but the last three contain material unknowns, a coded MVP is often the honest test.

1. Specific user and problem evidence

A prototype is the safer first milestone when the team cannot name the primary user, the triggering situation, the current workaround, and the consequence of the problem in plain language. Screens cannot rescue a weak problem statement, but a short prototype test can expose whether the proposed sequence matches how people actually think and work.

Move toward an MVP only when the team has repeated evidence from a defined user group, not general enthusiasm from friends, colleagues, or a broad survey. The evidence does not need to predict a market. It needs to justify testing one narrow promise with working software.

2. The next costly assumption

Write one sentence: "The next milestone must tell us whether..." If the sentence ends with understand, prefer, notice, trust, or complete this flow, a prototype can often answer it. If it ends with pay, return, sync, calculate, approve, route, recover, or operate, you probably need an MVP or a focused technical test.

Google Ventures frames a sprint prototype as a way to test a realistic facade before committing to a build. The value comes from choosing the question first, then making only enough of the experience to answer it.

3. Usability risk or system behaviour

Use a prototype for usability risk: navigation, language, information order, empty states, handoffs, and whether the core task is understandable. Use an MVP for system risk: account state, permissions, payments, notifications, data quality, integration failure, offline work, audit history, or human support load.

Some projects need a technical spike before either milestone. An unfamiliar API, hardware dependency, model behaviour, or legacy data source may require a small feasibility test that has no customer interface. Do not disguise that risk test as an MVP. Name the technical question, time-box the test, and decide what result allows product work to continue.

4. Learning that requires real data

A prototype can simulate a booking, approval, recommendation, report, or payment. It cannot show whether real records arrive on time, permissions hold across roles, a failed transaction recovers safely, or staff can resolve an exception. When the important learning appears only after data changes state, an MVP is usually required.

Use controlled data when customer or operational information is sensitive. An MVP still needs an explicit data boundary, access roles, deletion path, and fallback. Narrow scope does not make real consequences harmless.

5. An observable milestone result

For a prototype, define tasks and observations before testing. Examples include whether a user can find the next step without help, explain what will happen after submitting, and identify the information needed to continue. Record confusion and workarounds, not compliments.

For an MVP, define the user group, core event, baseline, observation window, support route, and decision rule. An event such as account created is rarely enough. The core event should represent the promised outcome, such as a manager approving a real request, a customer completing a booking, or an operator resolving an exception. Atlassian describes an MVP as the simplest version that can be released to validate an idea through feedback. The release and feedback parts distinguish it from a screen demonstration.

6. Operating ownership

A prototype needs an owner for test recruitment, facilitation, observation, and synthesis. An MVP needs more: release ownership, analytics, access control, incident handling, customer communication, data correction, and a route for improvements. If no one can own those duties, working software may create noise instead of learning.

For a non-technical founder, this gate is also a partner test. Ask who owns the repository, environments, credentials, monitoring, documentation, and release decision. The broader founder guide explains how to structure a product relationship when you do not have an internal technical lead.

A compact funding rule

Do not score the rows and average the result. Find the earliest unresolved evidence state. That is the next milestone. A polished prototype does not cancel a technical blocker, and working code does not cancel weak user evidence.

Map the first build milestone.

Three examples

Service business customer portal

A team wants customers to request work, select a location, attach evidence, and track status. Start with a prototype if the team is unsure which information customers have at request time or how much status detail they need. Move to an MVP when the journey is understood but the open questions concern scheduling data, customer access, notifications, and staff exception handling.

Operations approval workflow

An operations leader wants to replace email and spreadsheets with a structured approval flow. A prototype can test the request form, approval sequence, escalation language, and exception states. An MVP is needed to learn whether role permissions, source data, reminders, audit history, and real response times work in the operating environment.

AI-assisted product

A founder wants an assistant to turn user inputs into recommendations. A prototype can test the input sequence, result format, explanation, and correction flow with scripted outputs. An MVP is needed when the team must test model behaviour on permitted data, retrieval quality, latency, cost controls, review paths, and what happens when the system should not answer.

What to put in the milestone brief

Keep the brief short enough to support decisions. State the buyer or user, the triggering problem, the core journey, the assumption being tested, the excluded work, the evidence required, and the person who will decide what happens next. For an MVP, add integrations, data boundaries, roles, environments, analytics events, support ownership, and release conditions.

The software scoping guide shows how to define the business problem, users, workflow, outcomes, integrations, and constraints before talking to a delivery partner. Use it after choosing the milestone so every bidder estimates the same test, not a different interpretation of your product.

When proposals arrive, compare their scope, assumptions, architecture, quality controls, ownership, and support before comparing totals. The proposal comparison framework gives one matrix for that decision.

Common mistakes

Treating fidelity as evidence

High-fidelity screens can make an idea feel decided before a single user has completed the flow. Nielsen Norman Group distinguishes low and high fidelity by factors such as visual detail, content, and interactivity. Choose fidelity based on the question. Early structural questions often need rougher work because it is easier to change.

Calling a demo an MVP

A scripted happy path is useful for testing a conversation or raising a design question. It is not an MVP if users cannot use it in the intended setting, if the system cannot preserve important state, or if the team cannot observe and support the outcome. Label the artifact honestly so the next funding decision uses the right evidence.

Building infrastructure for a future scale story

An MVP needs a sound foundation for its actual users and risks. It does not need every future role, region, integration, or automation. Ask what must be true for the first user group to receive the promised outcome safely. Defer the rest until behaviour justifies it.

Skipping the stop condition

Every milestone needs a result that stops or redirects the work. For a prototype, that may be repeated confusion around the core task. For an MVP, it may be low completion, unacceptable operating effort, an unreliable dependency, or evidence that the current workflow is not worth replacing. A learning milestone that can only produce "continue" is a delivery plan, not a test.

How KUMO approaches the first product milestone

KUMO can help founders turn the open question into the smallest credible design or build milestone through product design. The starting point is the evidence the business needs, then the user journey, technical risks, operating boundary, and exit decision.

For an inspectable example of product design and engineering moving into a working product, see the Flickd case study. Use it as evidence of delivery practice, not as a promise that another product will have the same scope or path.

If the next question is clear but the milestone is not, map the first build milestone.

Frequently asked questions

Is a clickable prototype part of an MVP?

It can inform an MVP, but it is a separate artifact. A prototype tests the journey with simulated behaviour. An MVP delivers a narrow outcome through working software. Reusing design components does not make the prototype itself production-ready.

Should a non-technical founder build a prototype first?

Usually, when the user journey or product language remains uncertain. A prototype gives the founder something concrete to test without pretending that data, security, integrations, and operations have been solved. If real system behaviour is the main unknown, pair the design work with a focused technical test.

Can no-code software be an MVP?

Yes, if real users can receive the promised outcome and the team can operate, measure, and support it. The tool does not determine whether an artifact is an MVP. Real use, real consequences, and a defined learning decision do.

When should a prototype be thrown away?

Throw it away when its structure encodes assumptions that testing disproved, or when converting it would preserve weak architecture and hidden shortcuts. Keep the learning, task language, and validated flow. Do not preserve the artifact merely because it looks polished.

What should happen after an MVP test?

Choose among four outcomes: improve the same narrow promise, change the user or workflow, test a different risk, or stop. The decision should follow observed user behaviour, system evidence, support effort, and the original exit rule. It should not follow the amount already spent.

Sources

GOV.UK Service Manual: Making prototypes

Google Ventures: The Design Sprint

Atlassian: Minimum viable product

Nielsen Norman Group: UX Prototypes, Low Fidelity vs High Fidelity

Y Combinator: How to Plan an MVP