BETTAn MVP (minimum viable product) isn't an unfinished version of your final product — it's the smallest version that lets you validate whether anyone will actually use it. Most projects that drag on past 8 weeks fail for one reason: they try to solve too much before knowing if it's worth solving.
Weeks 1-2: Discovery and scope
Before writing code, we define three things: the core functionality (the single reason someone would use the product), what's explicitly out of scope, and how success will be measured. If you can't write the core functionality in one sentence, the scope isn't ready yet.
- One user flow, not five. Pick the shortest path between the problem and the solution.
- Define what "functional" means before you build — not after.
- Document what you decide NOT to build. It's as important as what you do build.
Weeks 3-5: Building the core
This is where the stack matters. For most web MVPs we recommend static generators or lightweight frameworks with server-side rendering only where it's needed — not microservice architecture for a product that doesn't have a single user yet. The rule: technical complexity should be proportional to how certain you are about the problem.
We work in one-week sprints with a working demo at the end of each. If something can't be demoed, it doesn't count as done.
Weeks 6-7: Polish and edge cases
This phase is usually underestimated. Error handling, empty states, form validation, and performance on slow connections aren't "extras" — they're the difference between an MVP someone can use unassisted and one that only works in the demo.
Week 8: Controlled launch
Launch to a small, real group before launching to everyone. Instrument the product to see what users actually do, not just what they say they'll do. That data is what decides whether the project graduates from MVP to product.
Common mistakes that extend the timeline
- Adding full authentication, roles, and permissions when simple access would validate just as well.
- Designing for scale before you have a single real user.
- Changing scope mid-sprint without adjusting the timeline.
A well-executed MVP doesn't feel unfinished — it feels focused. That's the goal of the 8 weeks: not building less for the sake of it, but building exactly what's needed to make the next decision with real data.