“We need an MVP” can mean three different things. A plan of what the product will do. Something real people can use once to see if they come back. Or a first version built to last, with authentication, roles, payments and integrations. Mixing them up is how teams spend months building the wrong one.
This article separates the three: the scope, the working prototype and the MVP. What each one is, what you can do with it, and which belongs before a round and which after.
Scope: The Plan You Can Show
A scope is a document. It contains the skeleton of every flow in the product, written down and not working: what the user does, in what order, and what they see at each step. It sets the boundary of the first release, what’s inside and what’s deliberately left out, and maps the roles and integrations the product will need.
A good scope ends with a fixed quote for the build, because once the boundary is written down, the work can be estimated properly.
What you can do with it: show the plan to investors and to your own team, decide what to build first, and get a reliable estimate. What you can’t do with it: put it in front of users.
The skeleton of the flows belongs here, in the scope. A clickable mockup of those flows is still the scope, presented visually. The prototype starts where something actually runs.
Working Prototype: One Loop, Live
A working prototype is deployed on a real domain. It covers one loop: the user arrives, does the main thing the product is for, and sees the result. From the outside it looks like a product. Inside, everything except that loop is cut: no roles, no payments, simplified data.
What you can do with it: give it to real people and watch whether they come back. That’s the whole point. It answers the question a scope can’t, whether anyone wants this badly enough to use it twice.
A prototype is often what a company needs before a raise, when the product idea is clear and the evidence of demand isn’t yet. It costs less than building the wrong product in full.
MVP: The First Version Built to Last
An MVP is the same core loop plus everything a real product needs: authentication, roles, payments and real integrations, written so it can keep growing. The code is the foundation for what comes next.
What you can do with it: sell it, onboard paying customers and build on it. This usually comes after a signal, once the prototype or early customers have shown the loop works.
What separates the three is what you can do with the result.
A scope is a plan, a prototype answers whether anyone wants it, and an MVP is what you sell.
Which One You Need
Before a raise, with an idea and no product. A scope, and often a working prototype on top. The scope gives investors a credible plan. The prototype adds evidence.
Before a raise, with early users. A prototype of the loop you’re betting on, if the current product doesn’t show it yet.
After a raise or a clear signal. An MVP, starting from a scope if you don’t have one.
If you already know the market and have customers waiting. Skip the prototype and go from scope to MVP. Testing demand you already have only adds a stage.
Whatever you build, the experience inside it is also part of the brand. Clear flows, an interface that holds together and a design system from the first screen save rework later. For a product that already exists and feels off, a UX audit is a better first step than any of the three.
If the raise is close, the product is one item on a longer list. The rest is in Before a Funding Round: Which Brand Fixes Matter and Which Can Wait.
FAQ
What’s the difference between a prototype and an MVP?
A prototype covers one loop with everything else cut, to see if people come back. An MVP adds authentication, roles, payments and integrations, and is built to keep growing.
Is a clickable mockup a prototype?
A clickable mockup shows the flows without working. It’s a way to present the scope. A working prototype runs on a real domain with real people using it.
Do we need a prototype before an MVP?
Only if demand isn’t proven yet. With customers already waiting, going straight from scope to MVP is usually the better use of time.
Why write a scope before the build?
Because the scope is what makes a fixed price for the build possible. Without a written boundary, any estimate for an MVP is a guess.
Conclusion
Write the scope first, build a prototype when you need evidence, and build the MVP when you need a product to sell. If you’re deciding which one comes next for your company, tell us what’s coming up.
