The line between a prototype and an MVP
Clients ask for an MVP and mean a prototype, or the reverse. The gap between the two is where scope creep is born.
Hammad Iqbal
Software Engineer
"Let's just build an MVP" means something different depending on who's saying it. Getting specific about which one you're building, before writing code, avoids most of the scope disputes that show up later.
- A prototype proves the idea. An MVP proves the business.
- They have different tolerances for shortcuts — a prototype can hardcode data; an MVP can't.
- Naming which one you're building up front prevents the 'wait, this needs to actually work?' conversation at week six.
A prototype answers 'does this make sense?'
A prototype's job is to validate a flow, a layout, or an idea in front of real users or stakeholders. It can hardcode data, skip auth, and fake the parts that aren't the point. Its success metric is a decision, not uptime.
An MVP answers 'will people actually use and pay for this?'
An MVP is a smaller, real version of the product. It needs real accounts, real data persistence, and error handling for the paths a paying user will actually hit — because the whole premise is that people will use it for real. Cutting corners here doesn't save time; it just moves the cost to the first week after launch, with real users watching.
Naming it early changes the estimate
When a client says 'MVP' but means 'prototype,' the estimate they're expecting and the one that's accurate are very different numbers. Asking directly — 'is this for internal validation, or will real customers depend on it working?' — takes thirty seconds and prevents a scope argument three weeks in.
Before scoping, agree on which one you're building. The tolerance for shortcuts, and the estimate, follow from that answer.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.