The six-week MVP framework has seven phases: discovery (week 1), design and architecture (week 2), build (weeks 3 and 4), integrate and QA (week 5), launch and handoff (week 6), post-launch iteration (first 30 days), and the decision point (day 30 — continue, pivot, or kill).

The framework assumes a senior-led team of roughly four people: one engineering lead, one full-stack or platform engineer, one designer, and a fractional product manager or founder acting as PM. This is the smallest team that can ship quality in six weeks. Smaller teams can do it but introduce single-point-of-failure risk; larger teams introduce coordination overhead that typically costs more than they contribute in the first MVP.

Meetings are kept deliberately light: a 15-minute daily standup, a 45-minute weekly design review, a 45-minute weekly demo to the founder, and a one-hour retrospective at the end of each week. No long planning meetings. The written scope doc is the source of truth, and it gets updated live as decisions get made.

Three gates enforce discipline. Gate 1 at the end of week 1: a scope doc signed by the founder that fits on four pages or fewer. Gate 2 at the end of week 2: a technical architecture doc that fits on two pages, and a clickable Figma prototype covering all critical paths. Gate 3 at the end of week 5: a QA-complete build in a staging environment with zero P0 bugs and no more than 5 P1 bugs. If you miss a gate, you either de-scope or slip — never both at the same time without a founder-level conversation.

Everything else — specific tools, ceremonies, testing strategies — is a team choice. We have shipped six-week MVPs on React + Node, Next.js + tRPC, SwiftUI + Vapor, React Native + NestJS, and more exotic stacks. The framework is stack-agnostic. The discipline is not.

Week 1 is the most important and the most frequently mismanaged week. The output is a four-page scope doc signed by the founder, plus a validated understanding of the three most important user jobs. Nothing else matters in week 1.

Days 1–2 are discovery. Talk to three to five target users in 30-minute structured interviews. Read any existing research. Review competitor products. The goal is to write, in one page, who the user is, what job they are hiring the product to do, and what the current alternative is. If you cannot write this in one page with specific examples, you are not ready to build.

Days 3–4 are scoping. The founder, engineering lead, and designer map the minimum user flow that completes the core job. This is where most projects fail — not because the team cannot design a feature, but because they cannot stop adding features. Every feature that enters the MVP should pass a brutal test: 'If we shipped without this, could the user still complete the job?' If the answer is yes, cut it.

Day 5 is the scope doc review. The doc must fit in four pages (1: user and job; 2: user flow; 3: out of scope; 4: success metrics). The 'out of scope' section is at least as long as the in-scope section. The scope doc must be signed by the founder. Yes, literally signed — even digitally. The act of signing forces the founder to commit, and the artifact protects the team from week 3 feature creep.

Common week 1 failure: trying to build the product in week 1 because the team is excited. Every day spent coding in week 1 is a day not spent scoping, and it is almost always a day wasted when the scope changes at the end of the week. Engineering spikes in week 1 are fine (verify a tricky integration, prove a technical assumption) but building features is premature.

The deliverable at end of week 1: scope doc, signed. User flow map. Success metrics with concrete thresholds. Out-of-scope list. Tech stack decision. Team is ready to enter week 2.

Week 2 is parallel execution. Design owns the clickable prototype; engineering owns the architecture document and the project skeleton. By the end of the week, both streams converge for the Gate 2 review.

Design produces a clickable Figma prototype covering every screen in the scoped user flow. This includes empty states, loading states, error states, and the two most likely edge cases. Aesthetics are secondary in week 2; what matters is flow clarity and interaction fidelity. Use a design system (Shadcn for web, Material/Cupertino for mobile, your existing system if you have one) to avoid drawing components from scratch.

Engineering produces a two-page architecture doc covering: service topology, data model, external integrations, auth, hosting, and observability. Then they scaffold the repository, set up CI/CD, configure the staging environment, and make sure that 'hello world' deploys cleanly on both web and whatever clients are needed. Getting the deploy pipeline working in week 2 is non-negotiable; waiting until week 5 guarantees chaos.

A product manager or founder runs the interface between the two streams, resolving design-engineering trade-offs as they emerge. Typical trade-offs in week 2: whether to build a custom interaction or lean on the design system; whether to support one or two auth methods at launch; whether to invest in a real admin UI or ship a scripts-and-console approach. The PM's job is to make these calls fast and document them in the scope doc.

At the end of the week, Gate 2 review: the team walks the founder through the clickable prototype end to end while the engineering lead walks through the architecture. If the prototype and architecture do not match the scope doc, one of them has drifted. Adjust before Monday of week 3. Starting week 3 with a mismatched prototype and architecture is the most common cause of a missed week 5 gate.

Do not underinvest in week 2. Every hour spent on design and architecture in week 2 saves five hours of rework in weeks 3 and 4. A team that shortcuts week 2 to start building earlier almost always ships late.

Weeks 3 and 4 are the build phase. Scope is locked. Architecture is set. Design is signed off. The team ships features every day, merges to main at least once per engineer per day, and runs a 15-minute daily standup at 9:30am sharp.

The core rule of weeks 3–4: no new scope. Not 'small additions,' not 'quick changes,' not 'this should only take a day.' Every deviation from the week-1 scope goes through a written change-request that the founder signs, exactly as strictly as the original scope doc. This single rule prevents more failed MVPs than any other practice.

Engineering typically builds in order of risk, not order of user flow. The tricky integration, the novel algorithm, the new infrastructure — these go first, in week 3. The familiar CRUD, the well-understood UI flows, the known integrations — these go in week 4. Reversing this ordering is a classic failure mode: teams build the easy stuff first and discover the hard stuff blocks launch in week 5.

Design is not done in week 2. During weeks 3 and 4, the designer pairs with engineering on the details that only surface during implementation: precise spacing, micro-interactions, error copy, accessibility audit, mobile layout on actual devices. The design review at the end of week 4 is the last opportunity to catch visual quality issues before QA week.

Observability goes in early. Logs, metrics, error tracking, and analytics are configured in week 3, not week 5. Sentry, PostHog, and a structured logger running on day one of week 3 will pay for themselves three times in debugging efficiency by week 5. Teams that defer observability to week 5 spend week 5 writing log statements instead of fixing bugs.

Weekly demo on Friday of week 4. The whole team, plus the founder, plus anyone who will own the product after handoff. Walk the user flow end to end on staging. Write down everything that does not feel right. Monday of week 5 starts with a triaged list of must-fix-before-launch items.

Week 5 is where most six-week MVPs either come together or break. The team stops writing new code by Wednesday. Monday through Wednesday is focused on integration, end-to-end testing, and the 'deep QA pass.' Thursday and Friday are bug fixes and the Gate 3 review.

The deep QA pass is a structured walkthrough: every screen in every state, on every target device (desktop + two phones + one tablet for web products; two iPhones + two Androids for mobile). A designated QA lead (often the PM or a contracted QA engineer for this week only) maintains a ranked bug list. P0: blocks launch. P1: must be fixed this sprint. P2: first-30-days backlog. P3: later.

Security hardening lands in week 5. Review of auth, authorization checks on every API endpoint, rate limiting, CSRF/CSP, secret rotation, SQL injection review, dependency audit, and a penetration-style review of the most sensitive flows. For compliance-adjacent products (HIPAA, GDPR), this is also when the compliance checklist is walked through. Skipping security hardening is the single most expensive deferred-cost item in a rushed MVP.

Load and resilience testing, even lightweight: can the service handle 100 concurrent users, 1,000 requests per minute, a database with 10x the current record count? If the answer is 'we will find out in production,' you have a week 5 bug. A day of k6 or Locust runs catches an enormous amount of latent fragility.

Friday of week 5 is Gate 3: zero P0 bugs, no more than 5 P1s, all security checks passed, a rehearsed deploy and rollback procedure. The founder sits with the engineering lead and reviews. If Gate 3 is missed, the launch slips to week 7 — a conversation that is painful but much less painful than launching a broken product.

One frequent week 5 failure: starting week 5 with a longer P0 list than the team can clear. This is almost always a symptom of week 3–4 scope creep. The fix is not to work weekends; the fix is to cut scope ruthlessly on Monday of week 5. Shipping a smaller, stable MVP beats shipping a bigger, unstable one every time.

Week 6 is launch week. Code freeze by Tuesday. Production deploy Wednesday or Thursday. Soft launch Friday. The last day of the engagement is a handoff session with the team that will own the product next.

Monday and Tuesday are final polish: copy review, screenshot generation for App Stores or marketing, final round of design QA, preparation of support playbooks. The engineering team runs a final dependency audit, checks that all feature flags are in a known state, and rehearses the deploy procedure once more on staging.

The production deploy is a deliberately boring event. If the deploy feels exciting, something is wrong with your staging fidelity. Deploy behind a feature flag that limits traffic to internal users and a small alpha cohort. Watch the dashboards for an hour. Expand access in measured steps: internal team → alpha cohort → beta list → public. The phased rollout over two days catches issues that staging never would.

Launch communications run in parallel. A public blog post, a founder email to the waitlist, a product-hunt or linkedin announcement if that fits the audience, and a press note for existing customers or investors. The launch post is written in week 5, not week 6; writing marketing copy under deploy pressure produces bad copy and broken deploys simultaneously.

Handoff is the part most teams skip. In the last two days of week 6, the engineering lead runs a live knowledge-transfer session with whoever owns the product next — in-house team, fractional CTO, or ongoing maintenance engagement. Handoff artifacts: architecture doc, runbook for common incidents, on-call rotation, observability walkthrough, key decisions log, and a 30-day backlog sorted by priority. A skipped handoff costs 6–10 weeks of re-learning.

The last ceremony of week 6 is a retro. What worked. What did not. What the team would do differently. Retros after MVP launches are the single best source of compounding improvement across projects. Write it down.

The first 30 days after launch is the phase where MVPs either graduate into products or quietly become shelfware. The founder's job in the first 30 days is not to build more features. It is to find out whether what was built is being used, and by whom.

Week 1 post-launch: stabilize. Expect a surge of bugs and edge cases from real users that never surfaced in QA. The team's only job is to triage, fix P0/P1 issues, and talk to users. Do not add features. Do not start the next big thing. Stabilize, observe, learn.

Weeks 2–3 post-launch: measure. Instrument the funnel. Acquisition → activation → first value → retention. Identify where users drop off. Schedule at least 10 user interviews, ideally 5 with users who stuck and 5 with users who bounced. The difference between the two groups is where your product lives.

Week 4 post-launch: decide. With four weeks of real usage data plus qualitative signal from interviews, the founder makes a decision: double down (evidence says the core bet is working), pivot (evidence says a different use case or user type is right), or kill (evidence says the job isn't valuable enough). All three outcomes are legitimate. A fast kill beats a slow death.

The metrics that matter in the first 30 days: not MAU, not total signups, not press mentions. The metrics are: activation rate (% of signups who complete the core job within 7 days), retention (% who return in week 2, week 4), and qualitative excitement (would users be very disappointed if this went away — the Sean Ellis question). If the product hits 40%+ on the Sean Ellis question, you are probably onto something. Below 20%, you likely are not.

Scope creep during weeks 3–4: the most common and most expensive anti-pattern. Fixes: signed scope doc in week 1, written change-request process for any deviation, founder commitment that scope changes cost time or features (never 'just add it').

Deferring observability to week 5: leads to a week of log-writing under deploy pressure. Fix: Sentry and a structured logger go in during week 3, with dashboards live by end of week 3.

Building easy features first: leaves hard integrations for week 5 when there is no time to address them. Fix: order weeks 3 and 4 by risk, not by UI flow.

Skipping the clickable prototype: leads to design-engineering mismatches that surface in week 4 or 5. Fix: clickable Figma is a non-negotiable Gate 2 deliverable.

Weekend heroics in week 5: caused by scope creep in weeks 3–4. Masks the real problem and burns out the team. Fix: cut scope on Monday of week 5. Deploy a smaller MVP.

No handoff plan: leaves the post-launch team re-learning the codebase for 6–10 weeks. Fix: written handoff with runbook, architecture doc, decisions log.

Measuring MAU instead of activation: leaves you unsure whether the product is working. Fix: instrument activation and retention before launch.

Building the admin panel in the MVP: an entire separate product hidden inside the MVP. Fix: ship the admin as scripts-and-console for the first 30 days. Build the panel only if usage justifies it.

An MVP is successful if it teaches you something true about your market. Shipping on time and on budget is table stakes. The real measure is whether you know more on day 30 than you did on day 0 — and whether what you know is enough to inform the next decision.

Operational metrics: shipped on the originally scoped date, within 10% of the originally scoped budget, with a P0 bug count in the first week post-launch in single digits, and no security incidents. If all four of these hit, the delivery was credible.

Product metrics: activation rate ≥ 40% for freemium products, ≥ 60% for paid products, week-2 retention ≥ 30% for consumer products / ≥ 70% for B2B tools, and a Sean Ellis 'very disappointed' score ≥ 40% on the second-week cohort. Products that hit these thresholds in the MVP phase have a credible path to the next stage.

Learning metrics: the team has a written answer to three specific questions that were unanswered on day 0 (about the user, the job, or the value prop), at least one hypothesis from the scope doc has been falsified, and the 30-day backlog is prioritized based on real usage rather than guesses.

Not every MVP will hit every threshold. That is fine. The purpose of an MVP is to produce evidence, not to declare victory. An MVP that misses activation targets but produces a clear, falsifiable hypothesis for the next iteration is a successful MVP. An MVP that hits its vanity metrics but leaves the team unable to name what to try next is a failure dressed as a win.

Finally: treat the MVP framework as a starting point, not a religion. If your product or team has a specific reason to vary the cadence — a specific compliance requirement, a specific domain complexity, a specific team constraint — adapt the framework, write down the adaptation, and commit to it. The pattern-matching of experienced teams is what makes the six-week framework flexible enough to keep working across domains.