Do I Need a Prototype Before an MVP?

I have an idea for a scheduling tool for physiotherapists. One developer says start with a proof of concept, another a prototype, a third straight to an MVP. Where do I actually start?

Start where your riskiest unknown is. A proof of concept asks if it can be built, a prototype if users get it, an MVP if they'll pay.

All three developers named a build. Most ideas start before any code: with the people who have the problem, and a plan of what to build first.

So before picking between the three, name what you don't know yet about your scheduling tool. For a booking app, it's rarely the tech.

PoC, Prototype and MVP Answer Different Questions

Each of the three developers is right, about a different question. The stages also differ in how long they take and what happens to their code.

Throwaway Code Isn't an MVP lays out the stages. A proof of concept and a prototype take days to a week, and their code is thrown away once they answer. An MVP takes weeks, and its code becomes the product.

So the open question picks the stage, not the budget, and not the developer who sounds surest. For your scheduling tool, the first open question may come before all three.

Ten People Come Before Any Code

The first unknown is usually the problem itself. Validation asks whether it's real before anyone builds for it.

The test I trust is behavior, not opinion. Find ten physiotherapists who have the scheduling problem and would pay to solve it. Then name the core feature in one sentence.

How to know an idea is worth building goes deeper. The free lean canvas and feature priorities tools help with both steps.

My own ideas go through the same gate. A cheap test comes first, like a landing page where a stranger leaves an email. Only an idea that then gets real commitment, money or a signed intent, earns a build.

Discovery Says What to Build

Validation says the problem is real. A discovery phase comes next, before a build: what to make, what it risks and what it takes.

A design sprint and a tech discovery answer different questions. A design sprint tests the idea with users: sketches, a clickable mockup, reactions from real people.

A tech discovery answers the build: what to make, and with what. One can follow the other.

Neither needs to end in a long report. A small real thing tests more than a long document does. So the answer is often a short brief and a small build.

Sometimes the plan turns up a question nobody can answer on paper. That's the one case for a proof of concept.

Prove the Tech When It's Unknown

A proof of concept is worth it only when the risk is technical. Think of an AI result nobody has measured, or an integration nobody has tried.

It's the smallest build that shows the riskiest part works. It isn't for users, and its code is meant to be thrown away.

I ran one on an AI feature that fills documents. The first attempt lost every merged cell and checkbox on the way through. Once the architecture was right, it worked with two AI providers.

Then a question about where the data goes stopped it. The wall showed up before the build, which is the point.

Your scheduling tool can be built: a booking app is known work. Whether physiotherapists want it is the open part.

So it's a question for a prototype, not a proof of concept. Unless your tool needs something nobody has tried, the first developer's proof of concept answers the wrong one.

A One-Week Prototype Can Say Don't Build

With the tech settled, the next question belongs to the physiotherapists. A prototype answers it with one flow they click through: sign up, do the one job, see the result. Payments and edge cases wait for the MVP.

AI tools now build a working prototype in minutes, so the clicking is cheap. Deciding what to leave out still isn't.

A prototype is meant to be thrown away. Its decisions aren't.

Mine is the exception: I build it on the real stack, with the next steps in mind. The big choices get made at prototype level, in lo-fi. The MVP is the hi-fi version of the same picture, like a progressive JPEG coming into focus. A yes carries the code into the MVP, and its decisions with it.

A prototype can fail, and that's part of what it's for. If users don't want it, you've spent a week, not a build.

A discovery plan can end the same way. When the answer is don't build, the plan says so, and why.

Saying no is part of the job. Worth Building names the worse outcome: perfect execution of the wrong idea.

A yes moves the idea to the third developer's answer.

An MVP Is What Someone Pays For

An MVP is the smallest product a paying user needs, on code that becomes the product. Six weeks is the honest length for it, with the scope cut to fit the time. What an MVP costs follows from those weeks.

The first version holds what a paying physiotherapist needs: sign-in, payments and the core feature. Everything else waits for feedback.

Find the Core sorts the rest. Build the core, add the minimum that makes it usable, and buy or defer everything generic.

Then launch it. Users change the roadmap, and past six weeks, building without them is guessing. That's why done means live, and why I'd launch before it feels ready.

An MVP tests whether anyone will pay. A full build is for founders who already know, with first customers, a waitlist or pre-sales. Their launch starts the product instead of testing it.

So the third developer is right once the ten physiotherapists from earlier want to pay.

What Shut-Down Startups Got Wrong

The order matters because missing demand kills startups. In a March 2026 report, CB Insights read the post-mortems of 431 venture-backed startups that shut down since 2023.

Of the 385 with a known reason, 43% cited poor product-market fit. Only running out of money came up more often, at 70%.

A build is the most expensive way to learn that nobody needs the product. Ten conversations are the cheapest.

How I Run Each Stage

I start with research, before I ask a single question. My reply to a brief says what to build first, and often that's a small build instead of a long report.

When the risk is technical, the proof of concept goes first. It runs inside a one-week prototype, before the rest of the flow. I revise work that isn't right until you're satisfied.

The MVP runs six weeks, paid by the week, toward real users in week six. After launch, SaaS development carries the build on in the order users show. The price is on the homepage.

You can also pause, or hire a team and take a handover. The bills that keep running are a question of their own.

What the Founder Should Do Now

Name your riskiest unknown first. For a scheduling tool it's rarely the tech. It's whether physiotherapists have the problem and would pay, and that starts with ten of them, before any code.

Then ask each of the three developers which question their first step answers, and start at the stage that answers yours.

Whichever stage comes first, name its question before you pay for it. When the question is answered, the stage is done.