MVP development runs in five phases over 8 to 16 weeks plus the first 90 days of use. Discovery, one to two weeks, produces the written scope. Design, two to four weeks, produces user flows and a clickable prototype. Build, six to ten weeks, produces working software demoed every one or two weeks. Test and launch, one to three weeks, puts it in front of real users with analytics wired in. Measure and decide, the first 90 days, produces the version-two decision. The founder's job in every phase is to decide quickly, because slow decisions are the biggest cause of delay.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Founders who have not built software before want to know what will happen, in what order, and what will be asked of them. This is that walkthrough. Each phase below lists its duration, what comes out of it, and the decisions you will be asked to make. The durations are for a typical MVP. How long an MVP takes explains what stretches them.
Phase 1: Discovery and scope
One to two weeks. The team learns the problem, the user and the business, challenges the feature list and produces a written scope: the core journey, the features in and out with reasons, the platform, the by-hand plan and the 90-day success measure. For a product with unknowns, discovery may include a short technical investigation, such as confirming a partner's API does what it claims. How to scope an MVP describes the method.
You decide: what is in and what is out, who on your side approves things and how quickly, and whether the scope and the quote that follows are acceptable. Discovery is often sold as a separate, smaller engagement so that both sides can decide whether to continue.
Phase 2: Design
Two to four weeks. User flows first, showing each step of the core journey as boxes and arrows. Then wireframes, which are the screens without visual styling. Then the visual design, applied to the screens that matter most. Usually a clickable prototype, which is the designed screens linked together so you can tap through the journey. The prototype is tested with a handful of target users before development starts, which catches most usability problems at the cheapest point. Wireframe, mockup and prototype explains the artefacts.
You decide: approval of the flows, then the wireframes, then the visual direction. Each approval should take days, not weeks. A design waiting a week for a decision is a week added to the launch date.
Phase 3: Build
Six to ten weeks. The backend, the front end, the integrations, built in short cycles of one or two weeks. Each cycle ends with a demo of working software, not slides. The order is usually: accounts and the data model first, then the core journey end to end in rough form, then each feature completed, then polish. By the midpoint you can use the product, badly. By week eight it does the core journey properly. Analytics, error tracking and backups go in during the build, not after. Choosing a tech stack for an MVP covers the technical choices made at the start of this phase.
You decide: feedback on every demo, fast and specific. Any change requests go on the out list unless they are blocking the core journey. Content: the real text, images, prices and categories the product needs, which are on the critical path and usually come from you.
Phase 4: Test and launch
One to three weeks. Testing against the written scope, bug fixing, performance checks, security review, production environment setup, app store submission and review if mobile. A closed group of recruited target users tries the product for a week or two before the public does. Launch itself is usually quiet: the product goes live to the first users you can reach, not to a press release. How to launch an app has the checklist.
You decide: the launch criteria, meaning what must work before going live and what can be fixed after. The go-live date. Who the first users are and how you reach them.
Phase 5: Measure and decide
The first 90 days. Activation and retention measured. Session recordings watched. Users who stayed and users who left interviewed. A decision memo at around week seven: build on, pivot, or stop. A small version two shipped by week twelve, aimed at the biggest drop-off. What to do after your MVP launches is the full plan, and how to test an MVP with real users covers the interviews.
You decide: everything. This phase is the reason the MVP exists, and the decision at week seven is the most important one in the product's life.
The process at a glance
| Phase | Weeks | Deliverable | Your decision |
|---|---|---|---|
| 1. Discovery | 1 to 2 | Written scope and quote | In, out, who approves |
| 2. Design | 2 to 4 | Flows, wireframes, clickable prototype | Approvals within days |
| 3. Build | 6 to 10 | Working software, demoed every one to two weeks | Demo feedback, content |
| 4. Test and launch | 1 to 3 | Live product, analytics on, first users in | Launch criteria, go-live date |
| 5. Measure and decide | First 90 days | Numbers, interviews, version two | Build on, pivot, or stop |
What happens between the phases?
Two things. A contract, usually after discovery, when the scope is known and the quote is real. Fixed price vs time and materials covers which type suits an MVP. And a weekly rhythm throughout: a short call, a written update, a demo when there is one, and a shared list of decisions waiting on you. If that rhythm is missing, something is wrong. Signs your development project is going wrong lists what to watch for.
What makes the process fast
- One person on your side who can approve in a day.
- Content ready before the build needs it.
- Scope changes go on the out list, not into the build.
- Demos every one or two weeks, feedback the same day.
- Analytics and the first users planned during the build, not after.
How 7L runs it
This is the process inside the first three phases of the Startupper Program, and it is the same for a $20,000 (€17,000, £15,000) MVP and a $150,000 (€130,000, £110,000) one. The difference is the length of the build phase. Discovery is usually a separate short engagement so the founder can see how we work and we can see whether the product is ready to build. If you want to know what the five phases would look like for your idea, describe it to us.
Frequently asked questions
Can discovery and design be skipped to save time?
Skipping them does not save time. It moves the decisions into the build phase, where each one costs a developer's day instead of a designer's hour. Two to four weeks of discovery and design is the cheapest part of the project and the part that most reduces the cost of the rest.
How involved do I need to be during the build?
A few hours a week: the weekly call, feedback on demos, answering questions, providing content. The faster you respond, the faster the build. Founders who disappear for two weeks mid-build add two weeks to the date.
What is an agile or sprint-based process and is it what I need?
Sprints are the one or two week cycles in the build phase, each ending in a demo. Most MVP builds use them, whatever the contract type. The label matters less than the practice: short cycles, working software at the end of each, your feedback between them.
What do I receive at the end of each phase?
Discovery: the written scope and a quote. Design: the flows, wireframes and clickable prototype files. Build: the source code in a repository you own, deployed and running. Launch: the live product, documentation and credentials. Our post on who owns the code covers what to insist on.
Is the process different for a mobile MVP?
Mostly the same, with app store submission added to the launch phase, which can add a week or two for review and any rejection. Design also takes slightly longer, since mobile screens are less forgiving. Our post on iOS or Android first covers the platform decision.