What an MVP is not
The most common mistake we see 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?
In the first meeting of every MVP project we settle one question: which assumption will this product test? Scope follows from the answer. For DrapeAI 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 real 4-week timeline
| Week | Work | Output |
|---|---|---|
| Week 0 | Scope meeting, assumption definition | 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
MVP delivery includes the list of out-of-scope features and a suggested priority order. That list gets reordered against validation results — real user behaviour usually differs from pre-MVP assumptions. Later releases continue in 1-2 week sprint cycles.