What a prototype is
A prototype is a set of designed screens linked together so you can tap or click through them as if they were the real thing. Nothing is stored and nothing is processed; it only looks and behaves like the product.
Prototypes range from paper sketches to high-fidelity designs that are hard to tell apart from a finished app. For investor meetings and user testing, a clickable, high-fidelity prototype is usually the right level: real enough that people react to the product rather than to the sketchiness.
What it proves: that people understand the product, that the flow makes sense, and that the idea is concrete enough to discuss.
What it doesn't prove: that people will use it repeatedly, or pay.
Time: typically weeks, not months, because there is no backend, no data and no infrastructure.
What an MVP is
Eric Ries, who popularised the term in The Lean Startup, defines a minimum viable product as the version of a product that lets a team collect the most validated learning about customers with the least effort. The emphasis is on learning, not on being small.
In practice, for most software startups, an MVP is a working first version: real accounts, real data, the core feature done properly, and nothing else.
What it proves: whether people actually use it, come back and pay.
What it costs: more time and money than a prototype, because it has to work, be secure and be maintained.
Time: commonly a few months for a first version, depending on how many kinds of user, integrations and business rules it has.
Side by side
| Prototype | MVP | |
|---|---|---|
| What it is | Linked designs that behave like the product | Working software people use |
| Real users and data | No | Yes |
| Answers | Do people understand and want this? | Will people use it and pay? |
| Good for | Investor meetings, early user tests, scoping | Launch, retention, revenue |
| Typical time | Weeks | Months |
| Can be thrown away cheaply | Yes | Less so |
Which do you need first?
Start with a prototype if:
- you need to raise money and have nothing investors can see;
- you are not yet sure what the product should do;
- you want accurate estimates for the build, because a prototype forces the decisions that set the size of the work.
Go straight to an MVP if:
- you have already validated demand, for example with pre-orders or signed pilots;
- you have a specification and designs you trust;
- you have the funding to build and run it properly.
Consider something smaller than either if you haven't spoken to customers yet. A landing page with a sign-up form, a manual service run by hand, or a few conversations can teach you more in a week than a prototype can.
The usual path
For non-technical founders, the common sequence is: write the idea down, build a clickable prototype, use it to raise and to test with users, then build the MVP from the specification the prototype helped you write. Each step makes the next one cheaper and less risky.