Pilot, Prototype, or MVP? What Founders Should Build First

Founders use pilot, prototype, and MVP as if they mean the same thing.

They don’t. And the confusion is expensive.

One team says it needs an MVP when it really needs a prototype — so it spends months engineering software just to learn the workflow is wrong. Another runs a pilot when it needs a product people can use repeatedly — so it proves interest but not repeatability. A third builds a polished prototype, gets positive feedback, and mistakes that for market validation.

Different artifacts answer different questions. Pick the wrong one and you don’t just waste time — you learn the wrong thing.

Our rule: don’t start by asking what you can build fastest. Start by asking what uncertainty matters most.

---

Table of Contents

• The plain-English difference
• A risk-based decision framework
• When to build a prototype first
• When to run a pilot first
• When to build an MVP first
• Three real examples
• The mistake founders keep making
• FAQ

---

The plain-English difference

Prototype

A prototype is a low-cost representation of the product experience.

It might be a Figma flow, a clickable mockup, or a rough no-code simulation. It looks enough like the product for people to react to it, but it’s not meant to operate as a real business system.

Use it to test:

• whether users understand the concept
• whether the workflow makes sense
• whether the interface is clear
• whether the solution fits the user’s mental model

A prototype is for learning fast without committing to engineering too early.

Pilot

A pilot is a limited real-world rollout.

It involves real users and a real operating environment, but doesn’t require a fully productized system. Parts can still be manual — spreadsheets, existing tools, human support behind the scenes.

Use it to test:

• whether people will adopt the workflow in real life
• whether the process works inside the actual business
• whether compliance, operations, or management will support it
• whether the outcome creates measurable value at small scale

A pilot is less about software polish and more about whether the solution survives contact with reality.

MVP

An MVP is the smallest real product that delivers the core value and can produce meaningful learning from live usage.

It’s not a demo. It’s not a fake backend forever. It’s a working product — just intentionally narrow.

Use it to test:

• whether users come back
• whether they’ll pay
• whether the core flow works end to end
• whether the product can be delivered with enough consistency to scale

An MVP is the right move when the question is no longer “does this make sense?” but “does this work as a product?”

At a glance

	Prototype	Pilot	MVP
What it is	Low-cost product simulation	Limited real-world rollout	Smallest working product
Answers	”Does this make sense?"	"Does this work in reality?"	"Will people use and pay for this?”
Users	React to mockups	Use it in live operations	Use it as a real product
Engineering	None or minimal	Partial (manual behind the scenes)	Full (narrow but functional)
Cost	Low	Medium	Higher
Risk it removes	Desirability, usability	Adoption, operational fit	Repeatable value, willingness to pay
Fidelity	Looks real, doesn’t work	Works partially, some manual	Works end to end

---

A risk-based decision framework

Pick the artifact that removes your biggest risk first. Not your second-biggest. Not every risk at once. The biggest one.

The default sequence isn’t always prototype → pilot → MVP. Sometimes you skip one. Sometimes you start with a pilot. The right order depends on what you most need to learn.

Here’s how to map common risks to the right first artifact:

Risk type	First artifact	Why
Desirability risk	Prototype	Test if users understand and want the concept
Workflow-fit risk	Prototype → Pilot	Validate the flow, then test it in context
Adoption risk	Pilot	Real environment, real stakeholders, real friction
Technical feasibility	Narrow MVP	Prove it works, even if ugly
Willingness to pay	MVP or commercial pilot	Need real commercial signal
Operational complexity / compliance	Pilot	Can’t simulate regulation in a prototype

---

When to build a prototype first

Build a prototype first when the biggest unknown is desirability or usability.

That usually means one of these is true:

• users struggle to describe what they need
• the workflow is new or still fuzzy
• every stakeholder imagines a different product
• you expect major UX changes after the first few user reactions
• the cost of engineering the wrong flow is high

If your current debate is mostly about screens, roles, steps, or handoffs — you probably need a prototype before anything else.

A good prototype should help you answer:

• Can users complete the core flow without explanation?
• Where do they hesitate or get confused?
• Which steps feel unnecessary or unclear?
• Does the solution feel better than the current workaround?

If those are your real questions, an MVP is overkill.

What research says

According to the Nielsen Norman Group, prototyping before development catches up to 80% of usability issues before a single line of code is written. That’s not a small thing — fixing a design error in prototype costs 1x; fixing it in production can cost 100x.

---

When to run a pilot first

Run a pilot first when the biggest unknown is adoption in the real environment.

A product can look great in a prototype and still fail once it hits actual operations. This happens more often than founders expect — McKinsey research notes that 70% of enterprise transformations fail, mostly due to people and process resistance, not technology.

Pilots are especially useful when the solution touches:

• multiple departments
• approval chains
• regulated data or workflows
• manual operational handoffs
• frontline teams with entrenched habits
• enterprise environments with more than one decision-maker

A good pilot should help you answer:

• Will people actually use this in a live setting?
• What breaks operationally?
• Who resists, and why?
• What approvals or controls are needed?
• Does the solution create enough value to justify wider rollout?

If your main risk is real-world execution, a prototype is too abstract and an MVP may be too early.

---

When to build an MVP first

Build an MVP first when the biggest unknown is repeatable product value.

That usually means the concept is already clear, the workflow is relatively standard, and the main question is whether a narrow working product can earn real usage.

An MVP makes sense when:

• the problem is already well understood
• the value only becomes real when the system actually works
• users can adopt it without heavy organizational change
• you need real usage or payment signals, not just positive interviews
• the main challenge is productizing a focused solution, not imagining it

A good MVP should help you answer:

• Do users come back after first use?
• Will they pay, renew, or expand usage?
• Does the core experience hold up in production?
• Which features actually matter once the product is live?

If you mainly need commercial or retention evidence, go straight to MVP.

The validation sequence

Most products go through a natural sequence — but not always in the same order, and not always completing every step:

The key insight: you can skip steps, but you can’t skip learning. If you jump to MVP without validating the concept, you’re gambling — not building.

---

Three real examples

1. Internal procurement workflow

The pain is obvious. Teams already complain about scattered requests and slow approvals. But nobody agrees on the exact flow.

Best first artifact: Prototype

Why: the main risk is workflow fit, not market demand. The team needs something concrete to react to before code hardens the wrong process.

2. Enterprise AI assistant in a regulated industry

Leadership likes the idea, but legal, compliance, and operations all have concerns. Success depends on trust, controls, and real-world behavior.

Best first artifact: Pilot

Why: a prototype won’t prove operational viability, and a full MVP may be too expensive before approvals are clear.

3. Niche SaaS tool for branch reporting

Managers already use painful spreadsheets. The problem is clear. The real question is whether a focused tool creates repeated usage and enough value to pay for.

Best first artifact: MVP

Why: the workflow is already familiar. The learning only becomes meaningful when the product works end to end.

---

The mistake founders keep making

The biggest mistake is building the artifact that feels most impressive rather than the one that teaches the most.

That usually looks like this:

• building an MVP before the workflow is clear
• calling a clickable demo “validation”
• running a pilot without defining what success looks like
• treating pilot users as proof of scalable demand
• using engineering effort to answer a question that interviews or prototypes could answer faster

CB Insights found that 42% of failed startups cite “no market need” as their top reason for failure. Not funding. Not competition. Not bad timing. They built something nobody wanted — often because they started building before they understood what to learn.

That’s why we keep pushing teams toward evidence before build, not build before clarity. If you haven’t identified the main risk yet, you’re probably choosing the wrong first artifact.

---

FAQ

What is the difference between a pilot and an MVP?

A pilot tests whether a solution works in a real-world environment with real stakeholders and operational constraints. It can involve manual processes behind the scenes. An MVP is a working product — narrow but fully functional — that tests whether users will repeatedly use and pay for it. Pilots answer “does this work in reality?” MVPs answer “will people use and pay for this?”

Should I always start with a prototype?

No. If your biggest risk is adoption in a complex environment (like a regulated enterprise), start with a pilot. If your biggest risk is whether people will pay for a working product, start with an MVP. Prototype first only when the concept, workflow, or usability is still unclear.

How long should a pilot run?

Long enough to see real behavior patterns — typically 4 to 8 weeks. Anything shorter risks capturing novelty effects rather than genuine adoption. Define success criteria before the pilot starts: what metrics, what thresholds, what decisions you’ll make based on the results.

Can I skip prototype and pilot and go straight to MVP?

Yes — but only if the concept is already clear and the main risk is commercial viability. If you’re uncertain about the workflow, user mental model, or operational fit, skipping to MVP usually means building the wrong thing faster.

What if my pilot fails?

That’s valuable. A failed pilot tells you exactly where the friction is — whether it’s the workflow, the stakeholders, or the value proposition. Document what failed, why, and what assumption it broke. Then decide: pivot the approach, run another pilot with changes, or kill the concept entirely. Failed pilots are cheaper than failed products.

---

What to do next

If you want a more disciplined way to choose your first artifact, start with our Blueprint methodology or read why 80% of products fail before they launch. The point is always the same: learn the right thing early.

A prototype, pilot, or MVP isn’t a badge of seriousness. It’s a tool.

The question isn’t which one sounds more advanced.

The question is: what do you need to learn next?

That’s the thing you should build first.