Why we ship small: our week-long MVP process
1. Start with one problem
Most products fail because nobody wanted them, not because a feature was missing. The fastest way to learn is to build the smallest thing that solves one problem for one kind of user, then watch what they do with it.
2. Cut the scope on purpose
List every feature you imagined, then sort them into three groups: needed to solve the core problem, nice to have, and later. Only the first group goes in the MVP. A useful test: if removing a feature does not stop a user from completing the main task, it waits.
- One user type.
- One main flow, start to finish.
- Simple design, using proven components.
3. What a week looks like
- Day 1: agree the single problem and the flow.
- Days 2–4: build the flow and the minimum design.
- Day 5: test it end to end and fix what breaks.
- Days 6–7: release to a small group and collect feedback.
A week is a target for a tightly scoped product, not a promise for every idea. Bigger ideas are split into several small releases.
4. What comes after the MVP
Real usage decides the next step: which features get built, which get dropped, and what needs to be rebuilt properly. The MVP is code you are happy to improve, not a throwaway — but it is built to learn first and scale second.
5. Questions people ask
Is a week-long MVP realistic for every project?
Will we have to rebuild it later?
Want to talk about your project?
Describe your idea in a few messages — you'll get a clear answer and a fixed quote.
Chat on WhatsApp