A focused software MVP often needs about 8–16 weeks of delivery after the core problem and release scope are understood. A prototype can be tested sooner; a product with unclear requirements, several integrations, regulated data or multiple user roles can take much longer. Treat the range as a planning starting point, not a delivery promise.

Reviewed: 9 September 2026

MVP development timeline at a glance

Stage	Indicative time	Evidence produced
Discovery and scope	1–3 weeks	Users, outcome, assumptions, dependencies and first-release boundary
Prototype and technical validation	1–3 weeks	Tested journeys and proof for uncertain technology
Focused build	6–12 weeks	Working product increments, integrations and operational controls
Release preparation	1–3 weeks, often overlapping	Acceptance, migration, support, monitoring and launch readiness

Some activities overlap, so adding every row does not create a universal project duration. Team availability, feedback speed and external approvals can matter as much as coding capacity.

What does “MVP” mean?

A minimum viable product is the smallest usable release that can test an important product assumption with the intended audience. “Minimum” controls scope; “viable” means the chosen journey works well enough to produce trustworthy learning. It is not a full roadmap squeezed into an arbitrary deadline.

GOV.UK’s alpha guidance describes doing the minimum necessary to test the riskiest assumptions. A team might test demand with a prototype, test feasibility with a technical spike, or deliver one complete transaction before adding adjacent features.

What happens during discovery?

Discovery identifies the user, problem, current alternative, success measure and constraints. It maps data, integrations, owners, risks and non-functional needs such as security, accessibility and support. It should produce decisions, not a large document that nobody uses.

Useful outputs include:

a clear problem statement and measurable outcome;
prioritised users and end-to-end journeys;
a first-release boundary and explicit later list;
integration and data assumptions with named owners;
a lightweight architecture and delivery approach;
acceptance evidence, release risks and budget bands.

If these remain unresolved, a fixed build deadline hides uncertainty rather than removing it. ACA’s development discovery workshop is a focused route to these decisions.

Why prototyping can shorten the real project

A clickable prototype lets representative users attempt important journeys before the team commits to production code. A technical proof tests the riskiest integration, device capability or performance question. Both can reveal mistaken assumptions while they are still inexpensive to change.

Prototype fidelity should match the question. Polished visuals are not required to test terminology and sequence; working code may be necessary to test offline behaviour or an unreliable external system.

What happens during the build?

A healthy build produces small, reviewable increments. The team develops the interface, business rules, backend, administration and integrations alongside automated checks, security controls, logging and deployment. Stakeholders review working behaviour against the agreed outcome rather than waiting for a final reveal.

GOV.UK’s agile principles emphasise frequent delivery, rapid feedback and improvement. That does not remove planning. It makes scope, decisions and progress visible enough to change direction while change is affordable.

What commonly extends an MVP timeline?

trying to serve several audiences in the first release;
slow decisions or unavailable subject-matter experts;
undocumented APIs and no representative test data;
migration from inconsistent spreadsheets or legacy systems;
late security, privacy, accessibility or legal review;
third-party procurement, credentials and approval queues;
changing the success measure after development starts;
treating every stakeholder preference as a launch requirement.

Mobile store review can also introduce an external lead time. Build current platform rules and review access into the plan; Apple’s App Review Guidelines explain submission expectations.

How can you reach launch sooner without cutting quality?

Choose one valuable end-to-end journey.
Secure decision-makers, credentials and test data early.
Use existing, supported services for commodity capabilities.
Test uncertain behaviour before building adjacent features.
Automate repeatable quality checks from the start.
Plan monitoring, support and rollback with the release.
Move optional features to a measured post-launch roadmap.

Cutting testing or operational readiness may create a calendar win and a product failure. Reduce breadth while preserving a complete, supportable journey.

What should be ready before the timeline is approved?

Confirm a product owner, user access, scope, data sources, dependencies, acceptance method and release route. Agree how changes will be prioritised and how often working software will be reviewed. The plan should show assumptions and decision dates, not only engineering tasks.

For budget context, read how mobile app development cost is shaped. ACA’s development team can then carry an evidenced first release through design, build and support.

Frequently asked questions

Can an MVP be built in four weeks?

A narrow prototype or very simple product may be possible. A dependable release with identity, data, integrations and operational support needs a scope and evidence-based plan before anyone should promise that date.

Does discovery delay development?

Discovery uses time early to reduce expensive rework. It can also show that a smaller experiment, existing product or process change should come before custom software.

When is the MVP finished?

When the agreed journey is usable, accepted, monitored and ready to test the chosen assumption. Learning after release should determine the next investment.

Should every MVP have a mobile app?

No. A responsive web product, assisted service or prototype may test the proposition faster. Choose the channel around the user and experiment.

How Long Does an MVP Take to Build?