Shipping an MVP in 6 Weeks: How the Process Actually Works

Six weeks is not a marketing number. It is the longest a founding team can hold its breath before the roadmap starts negotiating with reality. We have shipped enough MVPs on this clock to know exactly where the time goes, where it leaks, and which decisions in week zero decide whether week six ends with users or with excuses. Here is the actual process, week by week.

Week 0: the scope funeral

Before a single line of code, we hold what we internally call a scope funeral. Every feature the founders arrive with gets read aloud, and most of them get buried - with respect, and with a written epitaph in the backlog so nothing is lost, just deferred. The MVP that survives has to answer one question: what is the smallest product a real user would pay for, or at least come back to twice?

• A feature survives only if removing it makes the core promise untestable.
• Every survivor gets a named owner and a one-sentence success metric.
• "Nice for the demo" is an automatic burial. Demos lie; retention does not.
• Admin panels, settings pages and role systems are buried by default - a shared spreadsheet impersonates all three for six weeks just fine.

This meeting is uncomfortable, and it should be. A six-week MVP with twelve features is actually a twelve-week MVP with a surprise in the middle.

Weeks 1-2: the walking skeleton

We do not start with the hardest feature. We start with a walking skeleton: the thinnest possible end-to-end slice - sign up, do the one core thing, see the result - deployed to production infrastructure on day one. Not staging that "will become production later". The real domain, the real database, the real deploy pipeline.

The pipeline itself is boring on purpose. One workflow, main branch, straight to production behind a flag:

# .github/workflows/deploy.yml - the whole thing, on purpose
name: deploy
on:
  push:
    branches: [main]
jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pnpm install --frozen-lockfile
      - run: pnpm typecheck && pnpm test
      - run: pnpm deploy:prod   # every merge ships; flags gate exposure

Weeks 3-4: vertical slices, weekly demos

The middle two weeks are where MVPs usually die, because teams build horizontally: all the models, then all the APIs, then all the screens, then - in theory - integration. We build vertical slices instead. Each slice is one user-visible capability, working end to end, merged and deployed the day it is finished. The product is never broken; it is just incomplete, which is a very different thing.

Every Friday there is a demo on the production URL, driven by the founder, not by us. If the founder cannot demo it, it does not count as done. This single ritual removes about ninety percent of the "I thought it worked differently" conversations that otherwise show up in week six, when they are most expensive.

The demo you can only give from your own laptop is a rehearsal, not a product.

- D1versy engineering handbook

Week 5: hardening, not polishing

Week five is deliberately feature-frozen. No new slices - only the unglamorous work that separates a prototype from a product: empty states, error states, loading states, the password-reset flow everyone forgot, rate limits on anything public, and a real answer to "what happens when this API call fails". We also do a short internal red-team pass on auth and input handling, because retrofitting security after launch costs roughly five times more than doing it now.

Week 6: launch is a process, not an event

There is no big red button. Launch is a sequence: enable the flag for the design partners on Monday, watch the metrics and error tracker, widen the cohort midweek, open it up on Friday. Because everything shipped continuously for five weeks, "launch week" is mostly about watching dashboards and talking to users, which is exactly where founder attention belongs.

What we deliberately skip

• Microservices. One well-structured monolith; you can split it when the traffic - or the team - demands it.
• Kubernetes. A managed platform deploys in minutes and nobody has to carry a pager for the control plane.
• Pixel-perfect design systems. A tight component library and one accent color get you to real feedback faster.
• Ninety-percent test coverage. We test the money paths and the auth paths hard, and let the rest earn its tests.

None of these are forever decisions. They are six-week decisions, and that is the whole point: the MVP exists to buy you evidence. Six weeks of disciplined scope buys more learning than six months of building in the dark - and the codebase you end up with is not a throwaway, because everything in it earned its place. That is how the process actually works. The hard part was never the code; it was the funeral in week zero.