How to plan an MVP in 8 weeks

A minimum viable product (MVP) is the smallest version of a product that real users can use to solve a real problem, and that teaches you whether you are on the right track. It is not a prototype, not a demo and not "version 1 with everything". Done well, an MVP takes six to ten weeks. Done badly, it takes nine months and still teaches you nothing.

This article describes the eight-week plan we use for fixed-price MVPs, week by week.

Before week 1: are you ready?

You are ready for an MVP when you can answer three questions in one sentence each:

1. Who is it for? A specific group, such as "field technicians of mid-sized HVAC companies", not "everyone".
2. What problem does it solve? For example, "technicians lose 30 minutes a day on paper reports".
3. How will you know it works? One measurable signal, such as "50% of technicians submit reports in the app within four weeks".

If you cannot answer these yet, start with a short discovery workshop or a clickable prototype instead.

Week 1: discovery and scope

The first week decides the success of the project.

• Kickoff workshop with the people who own the problem and the people who will use the product.
• User journey for the one core flow: what does a user do from start to finish?
• Feature list, ruthlessly cut. For every feature, ask: can the user solve the core problem without it? If yes, it waits.
• Technical check: integrations, data, hosting, data-protection requirements.

Deliverable: a written scope of one to three pages with the core flow, the feature list (must / later), acceptance criteria and a fixed price.

Trap: "while we are at it" features. Every extra feature delays learning.

Week 2: design and architecture

• Wireframes for every screen of the core flow, then visual design based on an existing UI kit to save time.
• Clickable prototype in Figma, tested with three to five real users. Fix what confuses them.
• Architecture: data model, API contract, authentication, hosting. For most MVPs we use proven building blocks, such as Flutter or Next.js for the front end and NestJS or FastAPI with PostgreSQL for the back end.

Deliverable: approved design and a short architecture document.

Trap: perfect design. The MVP needs clarity, not pixel perfection.

Weeks 3–6: build in sprints

Two two-week sprints, each ending with a demo on a staging environment you can use yourself.

• Sprint 1: authentication, the core data model and the first half of the core flow, end to end. By the end of week 4 you can click through a real, thin version.
• Sprint 2: the rest of the core flow, the admin panel essentials, notifications and the first integration.

Every change is code-reviewed, critical paths get automated tests and the build runs automatically. You receive a short written update every week: what is done, what is next, what is at risk.

Trap: changing direction mid-sprint. Collect feedback and decide at the sprint review, not on a Tuesday afternoon.

Week 7: hardening and pilot preparation

• Bug fixing, performance checks and accessibility basics.
• Security review: permissions, input validation, secrets, backups.
• Analytics: the events you need to measure your success signal.
• Legal basics: privacy policy, imprint, data processing agreements and, for apps, store privacy labels.
• Onboarding material for the first users.

Week 8: launch

• Release: to the App Store and Google Play (plan a few days for review) or to production on the web.
• Pilot users: start with a small group you can talk to directly.
• Monitoring: crash reports, error tracking and the first usage numbers.
• Retrospective: what did we learn, what comes next?

After week 8: measure, learn, decide

The MVP has done its job when you can make a decision based on real usage: double down, change direction or stop. Most successful products go through several rounds of improvement after the MVP. That is where a dedicated team with a monthly budget usually makes more sense than another fixed price.

Ten rules that keep MVPs on time

1. One core flow, not five.
2. One decision-maker on the client side who is available every week.
3. Written scope with acceptance criteria.
4. Use proven components; build custom only where it creates value.
5. A staging environment from week 3.
6. Demos, not status reports.
7. A change budget: new ideas go into a list for after launch.
8. Integrations checked in week 1, not week 6.
9. Accessibility and privacy built in, not bolted on.
10. Code in your repository from day one.

What does an MVP cost?

MVP budgets depend on platforms, features and integrations. Our article What does app development cost in Germany? explains the drivers, and the app estimator shows effort and timeline.

What an MVP is not

• Not a prototype. A prototype tests understanding; an MVP is used by real people for real work.
• Not a cheap first version you will throw away. The code should be clean enough to grow, because successful MVPs rarely get rebuilt.
• Not "everything, but buggy". Fewer features, done properly, teach you more than many features done badly.
• Not a marketing launch. An MVP goes to a small group you can learn from; the big launch comes later.

Example: a field-service MVP

For a service company that wants to replace paper reports, the core flow could be: technician logs in, sees today's jobs, opens a job, records work and materials, takes photos, gets the customer's signature and submits. The office sees the report in a web dashboard and exports it for invoicing. Everything else (scheduling, route planning, spare-parts inventory, customer portal) waits until the core flow works and technicians use it.

Roles on both sides

On your side: one product owner who can make decisions within a day, access to a handful of real users for testing, and someone who can provide data or access to systems that need integration.

On our side: a project lead in Germany who owns scope, timeline and communication; a designer for weeks one and two; two to three engineers for the build; and QA throughout. Everyone joins the kickoff, so nothing gets lost in hand-overs.

Conclusion

Eight weeks are enough for a real MVP if you focus on one user group, one problem and one core flow, and if both sides make decisions quickly. The result is not a finished product. It is something better: evidence about what to build next.

Plan your MVP with us