The muddled distinction
Three words that show up in almost every kickoff of a new solution: prototype, MVP, first version. Three words that get used interchangeably as if they're synonyms.
They're not. And the difference determines whether you have something in production six weeks from now, or whether you're still revising Figma screens six months from now.
Prototype
A prototype is a hypothesis with a face. It exists to answer early questions: does this flow feel logical? Do users understand the point-of-sale? Is this interaction even feasible in the time available?
A prototype doesn't have to work. The data can be fake. The buttons can only respond visually. Edge cases are excluded. It's a cartoon of a product, not the product itself.
Speed is the whole point. A week is a lot.
MVP
An MVP is a product that ships with the minimum feature set. Not "a prototype with data." A product. It runs in production, it accepts payments if that's relevant, it has a database you won't throw away tomorrow and that you won't have to migrate every iteration.
The difference isn't in feature count. It's in state posture. An MVP can ship with one feature if that one feature solves something users will pay for. A prototype that simulates ten features is still not an MVP — nobody can actually use it.
The question most projects run aground on isn't "what should be in?". It's "what's deliberately not going into v1?".
First version (v1.0)
A first version is an MVP that has learned. It's what emerges after the first fifty real users, after the first support tickets, after the first edge case nobody anticipated.
An MVP and a v1.0 can share the same codebase, but they have different parents. The MVP was born from hypotheses; v1.0 from facts.
The trap
The typical trap — which I see more often than any other — is a team saying "we're building an MVP" while in reality building a prototype-with-database. Six weeks of building, two weeks of QA, one week of soft launch, and when the first user reports a real bug it turns out:
- The data model breaks with more than one tenant
- Auth works only for the happy path
- Payments were never tested in production
- There's no analytics installed
- There's no rollback plan
That's a prototype masquerading as an MVP. Not too little done — the wrong thing done.
The only distinction that matters
One question, in week two of building: is it going live, or isn't it?
If the answer is yes and you have time left: you're building an MVP. Cut features so you actually hit your deadline.
If the answer is no and the project keeps going: you're building a prototype. Be honest about it, and keep the scope short. Downsizing is cheaper than rebranding.
At Thomas Foundry I make that check explicit in week two. It sometimes leads to an awkward conversation. It never leads to an awkward launch.