Six weeks is not a slogan: it is a design constraint. When the deadline is fixed, the conversation changes from “what else could the product include?” to “what is the minimum that proves this works?”. That second question is the one that validates businesses.
This is how we structure a fixed-deadline MVP — and, more importantly, the criteria for deciding what makes it in and what waits.
Why 6 weeks and not 6 months
An MVP has a single job: producing real learning with real users. Every extra week of development before first user contact is a week of untested hypotheses, paid at development rates.
Six weeks is plenty for a dignified product that does one thing well. It is not enough for three user roles, an exhaustive admin panel and configurable notifications. That is exactly the point.
What to cut without fear
- The second use case. If the product is “for restaurants, and also clinics”, the MVP is for one of the two. Whichever has the sharpest pain.
- The admin panel. In the early weeks, the admin is you with database access. It hurts less than it sounds.
- Settings and preferences. Pick the defaults yourself. If users ask to change them, congratulations: you now have users asking for things.
- Social login, dark mode, native apps. All of this comes after the question “does anyone want this?”.
- “Essential” integrations. There is almost always a manual version that works: a CSV, an email, a provisional Zapier.
What never gets cut
This is where cheap MVPs get expensive:
- The payment flow, if the business is charging money. Validating a paid business with a free product validates a different business.
- Basic accessibility and performance. It’s not (only) ethics: labelled forms, correct contrast and a fast site convert better — and in the EU this is now regulated territory.
- Analytics from day one. If you don’t measure activation and retention from week one, the 6 weeks don’t produce learning: they produce software.
- A serious deployment. Continuous deploys, a real domain, backups. It costs a day at the start and saves the launch weekend.
Inside the 6 weeks
| Week | Focus |
|---|---|
| 1 | Locked scope, core flow on paper, architecture and base design |
| 2–4 | Building the core flow, demo every Friday |
| 5 | Integration, real data, polish on the critical path |
| 6 | Testing, accessibility, deployment and handover |
The weekly demo is not ceremony: it is the mechanism that stops scope from growing silently. What isn’t shown on a Friday tends not to exist.
The mistakes that burn the most time
- Building for “everyone”. An MVP with three audiences is three MVPs done badly.
- Chasing visual perfection before the flow. First make the task completable; then make it lovable.
- Exotic technology. A boring, proven stack lets you concentrate risk where it belongs: in the business.
- Not talking to users during the 6 weeks. The development calendar does not pause the discovery calendar.
Ready to build?
Signs that you are: you can describe your first user by name, you know which action of theirs would validate the idea, and you have a way to reach 10 people like them in launch week.
If that’s you, our startup MVP service is exactly this: locked scope, 6 weeks, a demo every Friday and code that is yours from day one. Tell us your idea — we reply within 24 h.