The 4 Phases of Building an MVP (And What Most Teams Get Wrong)

Every MVP goes through four phases. The teams that fail usually fail in phases 1 and 2 — then wonder why phase 3 is so chaotic.

Need to define your product scope? Use our interactive Feature Prioritizer to filter your absolute must-haves, or apply for a complimentary Free MVP Scope blueprint designed by our Senior Architect.

Phase 1: Discovery (Days 1–5)

The goal of discovery is to produce a single document: a scope specification that both the client and development team have signed off on.

What happens in discovery:

• Review existing research, wireframes, and competitive analysis
• Define the target user and their core job-to-be-done
• Write user stories for every feature ("As a [user], I want to [action] so that [outcome]")
• Prioritize features into Must Have / Should Have / Won't Have (now)
• Define the technical architecture (database schema, API design, third-party integrations)
• Create a project timeline with milestones

The most common mistake: Starting development without a complete scope document. The result is scope creep, budget overruns, and a product that doesn't match expectations.

What you produce: A scope document that both parties sign before any code is written.

---

Phase 2: Design (Days 3–8, overlaps with discovery)

MVP design is not a branding exercise. The goal is clarity, not beauty.

What happens in design:

• Map the core user flows (2–4 key flows that users will go through)
• Design the key screens for each flow
• Define the component system (colors, typography, spacing)
• Review with stakeholders and confirm before development begins

The most common mistake: Over-designing. Spending 3 weeks on pixel-perfect Figma mockups for screens that will be redesigned once real users use the product.

The right approach: Design the key flows well. Let development fill in the secondary screens using the established component patterns.

What you produce: Figma designs for 10–20 key screens. Not every screen in the app.

---

Phase 3: Development (Days 7–21, the 3-week sprint)

This is where the product is built. If discovery and design were done well, this phase runs smoothly.

Week 1: Foundation

• Project setup, CI/CD pipeline, deployment environment
• Authentication system (sign up, login, logout, password reset)
• Database schema implemented with ORM
• Core feature #1 fully functional

Week 2: Core Product

• Remaining core features
• Payment integration (Stripe)
• Admin or management interface
• Email notifications

Week 3: Polish + Launch

• Error handling and edge cases
• Performance optimization
• Onboarding flow
• Final QA and bug fixes
• Production deployment

The most common mistake: Adding features during development that weren't in the scope document. Every addition has a cascading cost — it affects other features, delays testing, and risks launch.

The rule: No new features during development. Everything goes in the backlog.

---

Phase 4: Launch (Day 21 + ongoing)

Shipping is not the end. It's the beginning of the learning process.

Week 1 post-launch:

• Monitor error logs (Sentry)
• Watch user sessions (PostHog, FullStory)
• Fix any critical bugs immediately
• Talk to every user who signs up

The most common mistake: Treating launch as a "done" moment. Building more features before understanding how users are using what you've already built.

The right approach:

Define 2–3 metrics that indicate success (activation rate, D7 retention, first payment)

Watch those metrics closely for 2 weeks

Interview users who didn't convert

Prioritize v2 based on what you learn — not what you assumed

What you produce: A product in the hands of real users, a list of v2 priorities based on real behavior, and a decision point: pivot, persist, or double down.

---

The Phase Gate That Saves Weeks

Do not move into development just because everyone is tired of planning. Run a short "break the scope" meeting first. Walk through the core user flow and ask: what happens if the user has no data, enters bad data, cancels payment, loses their password, or invites the wrong person? These are the edge cases that quietly eat week three.

The output does not need to be a 60-page spec. It needs to be enough that a developer can build without inventing product decisions mid-sprint. If the team is still debating what "active customer" means, you are not ready to code that dashboard.

The Critical Insight

Most development problems are actually scope and communication problems. The teams that ship fast and with high quality are the ones that invest in Phases 1 and 2 — even when it feels like "wasted time" before code is written.

Every hour spent in discovery prevents 10 hours of debugging the wrong features.

---

Written by Milad Kalhur *Founder & Chief Architect at Needmvp* Milad has designed, architected, and shipped over 40+ web applications for Y Combinator founders and VC-funded startups. Having pioneered the 3-week fixed-price MVP model, he actively consults on software development efficiency, database modeling, and high-performance serverless architecture.