Discovery (one to two weeks), scope (under a week), design and prototype (one to two weeks), build in sprints (four to six weeks), test (alongside, plus a week), launch to first users, then measure and decide. Our working plan puts a tightly scoped software MVP at about eight to twelve weeks.
Phase 1: Discovery (one to two weeks)
Interviews and research to write down:
- Who the first users are and what problem they have.
- How they solve it today, and what that costs them.
- The riskiest assumption behind the idea.
- What evidence would show the idea works.
Phase 2: Scope (under a week)
Turn discovery into a written scope: the main user task, the few features needed to test the riskiest assumption, what is out, and how success will be measured. Eric Ries's MVP guide frames the aim as the most validated learning for the least effort, so every feature must earn its place.
Phase 3: Design and prototype (one to two weeks)
Map the main flow, sketch wireframes, then build a clickable prototype and put it in front of five or so target users. Fix what confuses them before a line of production code is written; changing a prototype costs hours, changing built software costs weeks.
Phase 4: Build in sprints (four to six weeks)
Build in sprints of one or two weeks, each ending in working software you can click through. Use bought services for login, payments and email. Set up continuous integration from the first week so every change is built and tested automatically.
Phase 5: Test (alongside, plus about a week)
Testers check each sprint's work as it lands, then a final week covers the main flows end to end on real devices, security basics and the launch checklist. Finish with acceptance testing: does it meet the users' needs well enough to launch?
Phase 6: Launch to first users
Launch to a small group you can talk to, with monitoring and a way to report problems. Watch closely in the first days and fix what blocks the main task.
Phase 7: Measure and decide (ongoing)
The Lean Startup's Build-Measure-Learn loop turns ideas into products, measures how customers respond, and decides whether to pivot or persevere. Track behavior: return visits, the main task completed, payments, referrals. Review weekly and decide the next build cycle from the evidence.
What makes the weeks stretch
Our working plan assumes a tight scope and quick decisions. Five things stretch it:
- Scope that grows during the build.
- Slow decisions: a week waiting for feedback is a week added.
- Integrations with older systems or partners.
- Regulated data, such as health or payments, needing extra security work.
- Two native apps instead of one web app or cross-platform app.
How this compares with a full build
Clutch's software developers pricing guide (updated 21 September 2026) puts the typical custom software project at about 13 months. An MVP is meant to answer the main question in a fraction of that time, so the full build that follows is spent on what users showed they need.
Conclusion
The MVP development process runs discovery, scope, design and a tested prototype, building in short sprints, testing, launch to first users, and measuring to decide the next step. On our own working plan, a tightly scoped software MVP takes about eight to twelve weeks; scope growth, slow decisions, integrations and regulated data stretch it.
PromotEdge International is an international strategy, technology, marketing and design company, and our delivery team is in India. Our MVP team runs these phases with you, building in weekly steps with code and accounts in your name.
Facts we rely on: see our company facts for what we state about ourselves and where each fact comes from.