In this article 11 sections
Plan a focused production MVP in weeks to a few months, then validate the schedule against its actual dependencies. A six-to-twelve-week plan can be a useful starting scenario for a small, decided scope; it is not a measured industry average or a delivery promise.
Define what “finished” means#
A clickable prototype, an invitation-only pilot and a public product are different deliverables. A prototype can answer questions about a flow without having production data, permissions or support. A live product needs those decisions made. Agree the launch audience and acceptance criteria before comparing delivery dates.
| Planning scenario | Illustrative allowance | What must be true |
|---|---|---|
| Prototype | 1–3 weeks | A clear research question and access to test participants |
| Focused production MVP | 6–12 weeks | One main journey, available decision-makers and limited integration uncertainty |
| Complex first release | Scope separately | Multiple roles, migrations or external dependencies need separate estimates |
These are editorial planning scenarios, not a survey of completed projects. They assume a team is available to start. Procurement, recruitment, supplier onboarding and approvals can extend the calendar before or after implementation.
What an eight-week plan could contain#
For an illustrative small web product, weeks one and two could cover discovery, the prototype, architecture and the hardest integration check. Weeks three to six could deliver the main journey in working slices. Weeks seven and eight could focus on user acceptance, release preparation and a supported pilot.
Testing should happen throughout. The final weeks are for completing acceptance and launch work, not discovering whether the product works for the first time. If the early integration check fails, revise the plan then instead of carrying an unsupported launch date forward.
Find the dependency that controls the date#
List anything the delivery team cannot resolve alone: access to an API, migration exports, content approval, payment-provider onboarding or app-store review. Give each dependency an owner and a required date. Build against a realistic test environment early. A finished interface cannot make an unavailable integration ready.
Protect the decision-making cadence#
Name one product decision-maker and agree when they will review working software. Keep decisions small and written down. A team waiting three days for each clarification can lose more calendar time than it gains from fast coding. New requirements should trigger a visible trade-off in scope, budget or schedule.
What to ask before accepting a deadline#
- Does this include discovery, design, testing and deployment?
- Which people are allocated, and when can they start?
- What must we supply before work begins?
- Which external approvals sit outside the estimate?
- What happens when acceptance testing finds a serious issue?
- Who supports the first users after release?
Work backwards from an immovable event, then reduce the release to something the team can credibly support. The scope guide helps decide what can wait.
Calculate capacity before promising a date#
Forty team-days is not automatically four calendar weeks with two people. Design decisions, engineering dependencies, review and availability affect which tasks can happen together. As a simple illustration, a developer allocated three days per week needs more than thirteen weeks to supply forty developer-days, before allowing for interruptions or work that belongs to other roles.
Estimate effort by workstream, then place it against real availability and dependencies. Record waiting separately from active work. A payment-provider decision or missing data export can hold the critical path even while another part of the interface is progressing.
| Dependency | Evidence needed | Action if late |
|---|---|---|
| CRM access | Test credentials and representative records | Prove a smaller integration or move the connected feature |
| Content approval | Named owner accepts the final copy | Use agreed temporary copy only where the release permits it |
| Payment setup | Chosen model and test account are available | Adjust the pilot’s transaction design before development assumes it |
| Customer acceptance | Representative users can attend a test session | Book another session; do not treat absence as approval |
Interpret advertised schedules carefully#
On 16 October 2026, Wall & Fifth’s MVP offer advertises eight weeks, while Code23’s pricing page lists six to ten weeks for its custom SaaS MVP/web-app band. These are supplier descriptions tied to their offers, not a measured industry distribution or a promise for your brief. Wall & Fifth is affiliated with this publication.
Ask when the clock begins: signature, discovery, receipt of content or allocation of a team? Ask whether review, store submission, changes and post-launch fixes are inside that period. Separate “ready to submit” from approval by an external platform, and “code complete” from a usable supported release.
Use a replan rule instead of absorbing every delay#
At each review, compare accepted outcomes with the remaining work and dependencies. If a critical assumption changes, choose explicitly between scope, date and additional resources. More people may not accelerate a task that depends on one unresolved decision.
For an illustrative fixed-date pilot, you might defer optional reporting while retaining cancellation handling and recovery checks. Explain the consequence of the cut and who accepts it. Do not silently remove testing to preserve a date on a slide. A credible plan shows the trade-off while there is still time to act.
Put this guide to work#
Frequently asked questions#
Can an MVP launch in two weeks?
A tightly bounded prototype, manual service or small application may. Whether it is a dependable production release depends on what already exists and what must be built and checked. Ask for the actual deliverable and exclusions before comparing a two-week offer with a larger engagement.
Does discovery happen before the quoted build timeline?
It depends on the offer. Clarify the start event and whether problem definition, prototype testing and technical investigation are included. A schedule that starts after discovery cannot be compared directly with an idea-to-release timeline.
Can I shorten delivery by hiring more developers?
Sometimes, where the work can proceed independently and coordination is manageable. Extra people will not remove missing requirements, unavailable integrations or a single approval bottleneck. Ask which specific work becomes parallel and include onboarding effort.
What is the most useful weekly progress measure?
A working, accepted outcome with evidence is more useful than a percentage-complete estimate. Track remaining uncertainty and blocked dependencies alongside it. A nearly finished interface can still hide an untested payment or permission problem.
When should I announce a public launch date?
Distinguish an internal target from an external commitment. Announce when the remaining dependencies, release evidence and support arrangements make the commitment credible for your situation. If the date is externally fixed, scope a release you can support at that date.
Sources and methodology#
This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.
- GOV.UK: how the discovery phase works ↗
Public-service guidance on understanding a problem before delivery, not a benchmark for startup duration.
Accessed 16 October 2026 - Wall & Fifth: advertised MVP offer ↗
Publisher-affiliated supplier. Headline price and scope checked 16 October 2026; confirm the final scope and any conflicting wording in a written proposal.
Accessed 16 October 2026 - Code23: published pricing bands ↗
Supplier-advertised ranges checked 16 October 2026. These are not observed transaction prices or an industry average.
Accessed 16 October 2026
Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.
Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.
MVP Build Editorial. “How long does it take to build an MVP?.” MVP Build, 9 September 2026.
https://mvpbuild.xyz/mvp/how-long-does-an-mvp-take/