Key takeaways
- A well-scoped MVP usually takes six to twelve weeks. Ten weeks is a realistic plan for a product with accounts, one core workflow and payments.
- Roughly: weeks 1 to 2 for discovery, validation and design, weeks 3 to 8 for building in two-week sprints, and weeks 9 to 10 for QA, launch prep and launch.
- The founder's job is not managing tickets. It is answering questions quickly, reviewing each sprint demo, and making scope calls.
- Timelines slip because of scope creep, slow decisions, late design changes, unclear integrations and skipped QA, not because engineers type slowly.
Most well-scoped MVPs take six to twelve weeks from kickoff to launch. A simple validation MVP can ship in four to six. A first version with accounts, payments and one core workflow usually lands around ten. This article walks through what happens in each of those ten weeks, what you as the founder need to do, and the things that most often push a launch date out.
The plan below is the shape we use at Sprout, where we build in two-week sprints with a working demo at the end of each sprint and a written update every week. Your exact weeks will move, but the order rarely does.
How long does it take to build an MVP?
It depends almost entirely on scope. The number of screens, user types, integrations and edge cases drives the timeline far more than the size of the team. Adding people to a late project rarely makes it faster. Cutting features does.
| MVP type | Typical scope | Typical timeline |
|---|---|---|
| Validation MVP | One flow, minimal accounts, no payments | 4 to 6 weeks |
| Standard MVP | Accounts, one core workflow, payments, basic admin | 8 to 10 weeks |
| Complex MVP | Several user types, heavy integrations, AI or data-heavy features | 10 to 12+ weeks |
If you want the cost side of the same question, read how much it costs to build an MVP.
What happens in weeks 1 and 2: discovery and design
Week 1: Discovery and validation. The goal is to agree on what problem the MVP solves and for whom, and to cut everything else. That means reviewing what you already know about your users, mapping the one workflow the MVP has to nail, and listing what is explicitly out of scope. At Sprout we also run the idea through Truewick, our AI market research tool, so the plan starts from evidence about demand and competitors rather than assumptions.
What you do: join a kickoff session, share every customer conversation and note you have, and make the hard calls on what not to build.
Week 2: User flows and design. Designers turn the scope into user flows and then screens for the core workflow. You see clickable designs before any feature is built, which is the cheapest moment to change your mind. Engineering sets up the project, the repositories, environments and the data model in parallel.
What you do: click through the designs, show them to a few potential users if you can, and approve the flows. Changes here cost hours. The same changes in week 7 cost days.
What happens in weeks 3 to 8: building in sprints
The build runs as three two-week sprints. Each sprint ends with a demo of working software, not slides. Each week you get a short written update covering what shipped, what is next, what is blocked and which decisions need you.
Weeks 3 and 4: Sprint 1, the foundation. Accounts and sign-in, the core data model, and the skeleton of the main workflow. By the end you can log in and walk through the main path, even if it is rough.
Weeks 5 and 6: Sprint 2, the core workflow. The main feature becomes real: the thing users actually came for. This is the sprint where most product decisions surface, because using the real thing teaches you more than the designs did.
Weeks 7 and 8: Sprint 3, payments and the rest of the must-haves. Billing, notifications, the admin tools you need to run the product, and any integrations. This is also where the backlog of "small" requests gets triaged into launch versus later.
What you do during the sprints: attend each sprint demo, answer questions within a day, and protect the scope. Every new idea goes on a list for after launch unless it replaces something already planned.
What happens in weeks 9 and 10: QA and launch
Week 9: Testing and hardening. The team tests the full product end to end, fixes bugs, checks security basics like data access rules, and tests performance with realistic data. Analytics get wired in so you can see what users do from day one. If you have friendly early users, this is when they get access.
What you do: use the product the way a customer would, every day. Report anything confusing, not just anything broken.
Week 10: Launch. Production deployment, monitoring and error alerts, final fixes, and handover of accounts and documentation. Launch itself should be boring. The work was done in week 9.
What you do: invite your first users, watch the analytics, and start collecting feedback for the next iteration.
After launch, plan for a short period of fixes and quick improvements. At Sprout, MVP builds include a post-launch warranty period for exactly this.
What does the founder actually do each week?
Less than most founders fear, but it has to be on time. A summary:
| Week | Founder's main job |
|---|---|
| 1 | Share everything you know about users, cut scope |
| 2 | Review and approve designs, test them with a few users |
| 3 to 8 | Attend sprint demos, answer questions within a day, protect scope |
| 9 | Use the product daily, report confusion as well as bugs |
| 10 | Invite first users, watch the data |
What you should not be doing is writing tickets or managing developers day to day. That is the product manager's job. Your time is better spent on customers and fundraising.
What slows an MVP timeline down?
- Scope creep. "Just one more feature" is the single biggest cause of late launches. Keep a written list of out-of-scope ideas and revisit it after launch.
- Slow decisions. A question that waits three days for an answer can stall a sprint. Agree up front on how fast decisions get made.
- Late design changes. Changing the core flow after it is built costs far more than changing it in week 2.
- Unclear integrations. Third-party APIs with poor documentation, missing credentials or approval processes can block work for days. Start access requests in week 1.
- Skipping QA. Teams that cut testing to hit a date usually lose the time back after launch, in a more stressful way.
How can I shorten my MVP timeline without cutting corners?
Speed comes from doing less, not from rushing. These are the levers that actually move a launch date:
- Cut to one user type. Every extra role, such as admin, buyer and seller, multiplies screens and permissions. Launch with the one user who feels the problem most.
- Use proven building blocks. Sign-in, payments, email and file storage are solved problems. Use established services for them and spend engineering time on what makes your product different.
- Do manual work behind the scenes. If a step can be done by hand for your first fifty users, do it by hand. Automate it once you know it matters. Many successful MVPs had a person quietly doing the work a feature would later do.
- Fix the design before the build. Most of the time lost in weeks 5 to 8 comes from changing flows that were already built. A careful week 2 saves more time than any amount of overtime later.
- Agree on a decision owner. One person on your side who can say yes or no within a day keeps sprints moving.
- Set a launch date and protect it. A fixed date with a flexible feature list ships. A fixed feature list with a flexible date usually does not.
What not to cut: testing, basic security and analytics. Skipping those does not save time. It moves the cost to the week after launch, when real users are watching.
If you are deciding whether to build in-house, hire freelancers or work with a studio, the right setup also affects speed. We compare the options in fractional CTO vs technical co-founder vs dev agency.
How Sprout runs a 10-week MVP
Every MVP at Sprout gets engineers, a designer and a product manager. We start with validation, design before we build, work in two-week sprints with a demo at the end of each, and send a written update every week so you always know where things stand. MVPs start from $12,000 for a fixed scope, paid in milestones. You can see the details on our pricing page and the products we have shipped in our work.
If your idea is still forming, read our step-by-step guide to building an MVP first. If it is ready, book a free call and we will map your scope onto a week-by-week plan with you.