What an MVP is not
The most common mistake is building a full product under the name MVP. The result ships neither fast nor validates anything. An MVP is not:
- A full product with features left out. An MVP is not a shrunken version of the product; it is a separate product that tests one assumption.
- A low-quality product. Scope narrows, quality does not. Users do not forgive a crashing app because it is an MVP.
- A product without design. An MVP's design can be simple, but it must be usable.
- A product that does not scale — true, but only in a limited sense. Scalability can wait; the data model and authorization cannot.
The first question: which assumption are we testing?
Before any work starts, settle one question: which assumption will this product test? Scope follows from the answer. For DrapeAI's first version the assumption was: "Will users find trying clothes on their own photos convincing enough?" The single flow needed to test that was obvious.
A written list of what stays out of the MVP is the most practical tool against silent scope growth.
A 4-week timeline
| Week | Work | Output |
|---|---|---|
| Week 0 | Scope and assumption | Single main flow + out-of-scope list |
| Week 1 | Flow design and data model | Clickable flow, schema |
| Week 2 | Main flow development | Build installable on a test device |
| Week 3 | Integration and completion | End-to-end working flow |
| Week 4 | Testing, fixes, launch | Product live in store / on the web |
This timeline applies to single-flow projects that need no account system or can be handled with managed infrastructure. For projects with multiple main flows, 8-12 weeks is realistic.
What can and cannot wait
| Decision | In the MVP | Reason |
|---|---|---|
| Data model | Must be right | Most expensive decision to reverse |
| Identity and authorization | Must be right | Adding later means rewriting |
| Scalability | Can wait | There are no users yet |
| Caching | Can wait | You do not optimise before load exists |
| Admin dashboard | Usually can wait | Manageable by hand early on |
| Multiple languages | Can wait | Validation in one market is enough |
After the MVP
Keep the out-of-scope list after launch, in a suggested priority order, and reorder it against what real users do: their behaviour usually differs from pre-MVP assumptions. Later releases can then follow in 1-2 week cycles.
Questions
- What does MVP mean?
- An MVP (Minimum Viable Product) is a working product that tests the riskiest assumption in a product idea with the least possible development. Its purpose is not to ship a small version of the product but to validate an assumption with real users.
- Can an MVP really ship in 4 weeks?
- Yes, if scope is narrowed to a single verifiable flow. The first version of DrapeAI, our virtual try-on app, shipped this way in 4 weeks. The time is won by clarifying what stays out of the MVP, not by adding people. For projects with multiple main flows, 8-12 weeks is realistic.
- Which MVP decisions cannot be changed later?
- The data model and the identity/authorization structure are the two most expensive to change afterwards and must be right even at MVP stage. By contrast, scalability, caching and admin dashboards can be deliberately deferred.