An MVP timeline is determined less by the number of screens than by the number of unresolved decisions. The fastest useful path is to narrow the learning goal and deliver one coherent outcome.
An MVP is a decision instrument
A useful MVP tests a commercial, workflow, or adoption assumption. It is not a full roadmap squeezed into an arbitrary deadline, and it is not an excuse to ignore security or data integrity.
- Name the assumption that needs evidence
- Identify the first user and complete outcome
- Define what evidence changes the next decision
- Defer capabilities that do not affect that evidence
What extends the timeline
Complex role models, third-party integrations, data migration, offline mobile behavior, regulated information, and uncertain workflows add discovery and verification work. Slow stakeholder decisions can have the same effect as technical complexity.
- Multiple user roles and approval paths
- Unavailable or poorly documented APIs
- Historic data that needs cleaning
- Unclear ownership of product decisions
- High-consequence failure or security requirements
A practical sequence
A focused engagement normally moves through product definition, prototype and architecture decisions, vertical-slice delivery, release assurance, and measured learning. Some activities overlap, but skipping a decision rarely removes its cost; it usually moves it later.
Ask for a range with assumptions
A responsible timeline should be expressed with scope boundaries, dependencies, and decision dates. Beware of guarantees that are made before the team has seen the workflow, integrations, or existing codebase.