“Can we have this done in 8 weeks?” is one of the first questions almost every founder asks me. The honest answer is: yes, but only if you’re willing to keep the MVP genuinely minimal. Most 8-week plans fail not because the team works slowly, but because the scope quietly grows from an 8-week plan into a three-month plan without the deadline ever getting updated.
Here’s what actually fits in 8 weeks, what definitely doesn’t, and why honest cutting is what makes the deadline true rather than a marketing promise.
What fits in 8 weeks
A realistic MVP focuses on one thing and does it properly. That means:
- One core user flow. One problem you’re solving, one path from start to finish. If you describe the product as “it does X, and also Y, and a bit of Z”, it’s no longer an MVP.
- One authentication method. Email and password, or a single login option (like Google), not both at once and not a third one “we’ll add later”.
- A simple but functional admin view. Often it’s enough to be able to edit things directly in the database, or have a minimal admin panel for the bare essentials, not a fully featured dashboard.
- Basic design, not a design project. A clean, clear interface built on off-the-shelf components, not a custom design system from scratch.
- Manual processes wherever automation isn’t critical. If something happens twice a month, it can be done manually in the first version and automated later, once you know it’s actually needed.
What definitely doesn’t fit in 8 weeks
These sound small but are actually separate projects:
- Multi-tenant architecture with complex billing. If you plan to sell different plans to different clients with different levels of access, that’s a system of its own, not an add-on feature.
- Native mobile apps. A web-based MVP that works well on a phone too is achievable in 8 weeks. Building, testing and submitting separate iOS and Android apps is not.
- Heavy integrations with third-party systems. Accounting software, warehouse management, or some legacy internal system without a decent API each take weeks of their own, because most of the time goes into dealing with the other system’s quirks, not your own code.
- Complex permission and role systems. “Admin sees everything, team lead sees their team, a client sees only their own data, but some clients also have sub-accounts” is a feature in its own right, and testing it takes longer than designing it.
- Full automation and edge-case coverage. The point of an MVP is to test a hypothesis, not to cover every possible scenario. Rare cases can go through manual handling for now.
Why cutting scope is what makes the deadline real
“Done in 8 weeks” from a lot of development shops actually means “done in 8 weeks if you don’t change anything and agree with everything we decide.” A real deadline works the other way: you and the developer decide together what gets left out first, and only then is the deadline trustworthy, because the scope is fixed rather than open-ended.
If your list keeps growing by “just one more thing”, that’s a sign someone needs to say what goes into the next version instead of the first one.
How 8 weeks actually plays out
- Week 1: agreeing on scope in writing, locking in technical choices.
- Weeks 2–5: building core functionality, weekly demos to avoid surprises at the end.
- Weeks 6–7: polish, testing, first real-user trials.
- Week 8: launch and monitoring, not adding new features yet.
If you have an idea that needs a fast, honest MVP rather than an endless development project, see how I build web apps. Write to me with a couple of sentences about what your product does, and I’ll tell you honestly whether 8 weeks is realistic and what would make it into the first version.