In short
A prototype may take 2–6 weeks, a focused no-code MVP 4–10 weeks, and a custom web MVP about 8–16 weeks. Complex permissions, integrations, mobile platforms, uncertain business rules, or regulated data can extend the schedule to 16–28 weeks or more. Speed comes mainly from narrowing the test and making decisions quickly.
Planning ranges
| Approach | Typical range |
|---|---|
| Clickable prototype | 2–6 weeks |
| Concierge or no-code test | 3–10 weeks |
| Focused custom web MVP | 8–16 weeks |
| Complex web or mobile MVP | 16–28+ weeks |
Calendar time includes product decisions, content, access, review, launch preparation, and external dependencies—not only coding.
A typical 12-week shape
Weeks 1–2: define the test
Clarify audience, problem, riskiest assumption, current alternatives, minimum workflow, success evidence, and constraints. Map data and integrations early.
Weeks 2–4: structure and prototype
Design the core journey, important states, data model, and operational process. Test the prototype or service assumption before polishing the complete interface.
Weeks 4–10: build in vertical slices
Ship complete paths through interface, logic, data, and deployment rather than finishing every screen before connecting the system. Instrument analytics and support needs alongside the workflow.
Weeks 10–12: harden and release
Test permissions, failures, accessibility, security boundaries, performance, data integrity, backups, monitoring, and onboarding. Release to a controlled audience and watch behaviour.
What extends the schedule
- several audiences or products;
- unresolved business rules;
- complex roles and approvals;
- legacy-data migration;
- third-party API access;
- separate native platforms;
- transactions or sensitive data;
- legal, security, or procurement review;
- part-time stakeholders;
- a feature list with no learning priority.
How to launch faster safely
Reduce breadth, not completeness
One complete workflow is more useful than six half-connected features. Include the states required for a real user to begin, succeed, fail, recover, and receive support.
Use manual operations strategically
An internal team can manually review, match, schedule, or fulfil early work if users still experience the proposition being tested and the manual process can be measured.
Choose one platform
A responsive web release can test many products before separate native applications. Use native first only when device capabilities or use context are central to the hypothesis.
Reserve decision time
Weekly access to an accountable product decision-maker removes more delay than adding developers to an unresolved scope.
Common questions
Can an MVP be built in four weeks?
Yes, for a narrow prototype, no-code workflow, concierge service, or highly focused custom test with ready decisions. Four weeks is not a reliable default for a production product with accounts and integrations.
Does adding developers make the MVP faster?
Only when work can be separated without increasing coordination. Small products are often limited by product decisions, shared architecture, review, and dependencies rather than typing capacity.
When is an MVP ready to launch?
When the target user can complete the core value workflow safely, the team can observe the result, important failure states work, and operations can support the release.
Should the MVP include analytics?
Yes. Instrument the events and qualitative feedback needed to evaluate the core assumption, while avoiding invasive tracking that does not serve the decision.
What happens after MVP launch?
Review evidence, fix harmful defects, support users, and decide whether to continue, change the proposition, narrow the audience, or stop. Launch is the beginning of the test.
