MVP development: from idea to launch in 8 weeks
How to build an MVP in about eight weeks: set the scope, test a prototype, build, launch. With a week-by-week plan, a sensible tech stack and the usual mistakes.
In short: An MVP in eight weeks is realistic if the scope is strictly limited to one core flow and decisions get made quickly. A typical plan: one week for goal and scope, one week for design and a clickable prototype, four weeks of development in short iterations, one week of testing with real users and one week for launch. Whatever does not fit into eight weeks usually does not belong in the MVP.
What an MVP is and what it is not
A minimum viable product is the smallest version of your product that lets you test your most important assumption with real users. It has to work and deliver real value, but only for one narrowly defined use case. It is neither a half-finished final product nor a clickable mock-up.
Before development starts, the idea should already have had a first reality check: conversations with potential customers, a landing page, perhaps pre-orders. Our post on validating a startup idea shows how to do that without writing code.
The 8-week plan for your MVP
Week 1: goal and scope
Write down the one assumption the MVP should test and the one flow users will complete from start to finish. Sort every feature into "must have", "can wait" and "not part of this". The result is a short written requirements document. Our article on writing a product requirements document that works shows what it should look like.
Week 2: design and clickable prototype
Wireframes for the key screens, then a clickable prototype, for example in Figma. Show it to a few people from your target group. Anything you find at this stage costs a design change instead of a code change.
Weeks 3 to 6: development in short iterations
Development runs in one- or two-week sprints, with a working version at the end of each. You see progress regularly and can adjust course. Proven, boring technology is an advantage here: a web MVP with Next.js, TypeScript and PostgreSQL, or a mobile app with React Native and Expo, can be built quickly and extended later. Ready-made building blocks for login, payments and email save time that is better spent on the core feature.
Week 7: testing with real users
A closed beta with selected users shows whether the core flow is understood and where people get stuck. In parallel, bugs get fixed, analytics is set up and the legal basics are checked: legal notice, privacy policy and terms where needed.
Week 8: launch and measure
Launch is where the real learning starts. Decide beforehand which metrics will tell you whether your assumption holds: sign-ups, active use, willingness to pay. Collect feedback actively instead of waiting for it.
What stops an MVP from shipping in eight weeks
The biggest time sink is growing scope. Every "small" extra feature brings design, testing and edge cases with it. Slow decisions are just as damaging: if every question waits a week for an answer, the timeline cannot hold. Name one person who has authority to make product decisions.
Another mistake is building for millions of users from day one. Microservices, complex infrastructure and perfection in every detail cost weeks you do not have. Some technical debt is fine at this stage, as long as you take it on deliberately. Our post on technical debt in startups explains when to pay it down.
What happens after launch
Data from the first weeks decides the next step: keep building, rework or change direction. If users come back and are willing to pay, it is time to strengthen the foundation and expand the feature set. We describe how to recognise that moment in MVP vs. full product.
Frequently asked questions (FAQ)
Is an eight-week MVP realistic for every product?
Not for every one. Products with heavy regulation, hardware or many integrations usually take longer. For most web and app ideas with a clearly defined core flow, though, the timeline is achievable.
Web app or mobile app for the MVP?
If your product does not strictly need device features like the camera, Bluetooth or push notifications, a web app is usually faster to build and easier to distribute. A mobile app makes sense when use on the go is central. With React Native you can connect both paths later.
Will the MVP code be thrown away later?
Not necessarily. With a widely used tech stack and a clean basic structure, the MVP code can become the foundation of the later product. Some parts will get reworked as you grow anyway.
What do I need to contribute as a founder?
Mainly time for decisions and access to your future users. You know the target group and the market. The faster you answer questions and give feedback, the better the timeline holds.
Conclusion
The eight-week frame works because it forces focus. If you cut scope hard, decide quickly and test with real users early, you end up with a product you can actually learn from. If you want to build your MVP with a team that works directly with you, talk to us about web development and MVPs.
Related posts
- How to validate your startup idea before writing code
How to validate a startup or product idea without code: customer interviews, landing pages, fake door tests, concierge MVPs and pre-sales. Plus notes on GDPR.
- MVP vs. Full Product: When to Scale Your Development
How to tell your MVP is ready to grow into a full product: real usage signals, technical limits, common mistakes and a step-by-step path to scaling up.
- Product-market fit: how to know when you've found it
How to recognise product-market fit: which signals count, how to measure retention and demand, what the Sean Ellis test tells you and when to scale up.
- Technical Debt in Startups: When to Pay It Down
Technical debt in startups: which shortcuts are fine, how to spot the dangerous kind, and when paying it down is worth more than shipping new features.