The Founder's Guide to Shipping an MVP in 6 Weeks.

Most MVP advice is theology. "Ship the minimum viable product." OK, sure. What does that actually mean when you're staring at a Notion doc with 47 features and a board meeting in 8 weeks?

This guide is the practical version. Not what an MVP is — what you actually do between now and launch.

We've shipped 50+ products. Most under 10 weeks. This is the playbook.

Week 0 — Define the wedge

Before you start, you have to answer one question with terrifying specificity:

What is the one thing this MVP needs to prove?

Not three things. One. If you can't write it on a napkin, you're not ready to start building.

The wedge isn't "we'll be the best CRM for designers." That's a positioning statement. The wedge is "we'll prove that designers will pay $X/month for a tool that does Y, measured by Z."

If you can name the X, Y, and Z, you have a wedge. If you can't, spend another week here. Building the wrong thing fast is the most expensive mistake in startup land.

Week 1 — Strategy sprint

We run a 5-day strategy sprint at the front of every MVP engagement. It looks like this:

• Monday: Wedge confirmation + user research review. Who's the customer? What do they currently do? What's the friction we're removing?
• Tuesday: Core user flow design. Three screens, max. The "happy path."
• Wednesday: Wireframes. Not Figma yet. Whiteboard or paper.
• Thursday: Scope cut. We list every feature anyone has mentioned, then we cut 60% of them. The wedge survives. The rest gets a parking lot.
• Friday: One-page product brief. Everyone signs off.

If you skip this week, you'll spend it later — just spread across weeks 3, 5, and 7, where it does much more damage.

The scope cut is the hard part

Founders are bad at this. We're bad at it too. It's painful to cut features you genuinely believe in.

Here's the rule we use:

If the feature isn't necessary to prove the wedge, it doesn't ship in the MVP.

Not "if it would be nice." Not "if competitors have it." Not "if your investor mentioned it." Necessary to prove the wedge.

This is hard because every cut feature has a real reason for existing. The brutal truth is that you cannot evaluate "is this a real reason" until you've shipped the thing and watched real users. Until then, every reason sounds plausible. Cut anyway.

We've never regretted cutting too much. We've regretted cutting too little every single time.

Weeks 2–3 — Design

By the end of week 1 you have a one-page brief. Now design takes over.

Two weeks. High-fidelity in Figma. Every screen in the happy path. Empty states. Loading states. Error states. The first-time experience.

Two principles that separate good MVP design from bad MVP design:

1. Design the empty state first. What does the product look like when the user has done nothing? If that screen doesn't make sense, the whole product doesn't make sense.
2. Design the second visit. Day 1 user and Day 100 user see different products. Most MVPs design only for Day 1. The product becomes useless once data accumulates. Design both.

Two rounds of feedback. No more. If you're on round three, you're avoiding ship.

Weeks 4–9 — Build

Six weeks of build. We work in 1-week sprints with a Friday demo.

The non-negotiable: a staging link exists from day one. The founder can open it on their phone any time. There is no "wait until it's ready" period. Real software, getting more complete every week.

Stack choice matters less than founders think. The right stack for an MVP is the one your dev team already knows. We default to Next.js + Postgres + Supabase + Stripe because that's our stack. If yours is different, your stack is probably better than ours — for you.

What you actually need in MVP infrastructure:

• Authentication (don't roll your own)
• Database with backups
• Payment processing if relevant
• Basic analytics (PostHog or Mixpanel)
• Error monitoring (Sentry)
• A way to email users when things break
• A deployment pipeline that doesn't require you

You do not need:

• A microservices architecture
• A custom design system
• A dashboard for your dashboard
• An admin panel beyond what you need for support

If you build the second list before you've validated the wedge, you're cosplaying as a company.

Week 10 — Launch

The launch week. QA, soft launch to 10 friendly users, watch what breaks, fix the breaks, then go public.

A few things real founders get wrong about launch week:

• It's not the finish line. Launch is week one of the real work. Plan for that. Your roadmap for weeks 11–16 should already exist.
• A noisy launch isn't a successful launch. Twitter likes don't pay rent. Signups that convert to paid do. Optimize for the second.
• The first 100 users are a learning vehicle, not a market. Don't let their feedback overfit your roadmap.

What we ship in 6 weeks vs. 10 weeks

Two MVPs from our recent work to calibrate:

6-week MVP — Helio Finance. Single-product fintech, 3 user flows, payments via Stripe, AI document upload, basic dashboard. Shipped in 6 weeks. Closed Series A four months later.

10-week MVP — A SaaS analytics platform (in stealth). Multi-tenant, billing, 4 user roles, integrations with 3 data sources, admin panel, AI insights layer. Shipped in 10 weeks.

The difference isn't ambition; it's complexity. A single-product app with a clean wedge ships in 6 weeks. A multi-tenant platform with paying customers ships in 10. Both are MVPs.

The decisions that kill MVPs

Three failure modes we see most often:

1. The "while we're at it"

"While we're at it, let's add a referral system."

No. Ship without it. Add it in week 12 if the wedge is validated.

2. The pivot before launch

The MVP isn't done, but you have a new idea. Resist. Ship the current wedge first. If it doesn't work, then pivot — with the data from real users instead of imagined ones.

3. The "feature complete" trap

You convinced yourself V1 needs everything V3 will have. It doesn't. V1 needs the wedge. That's it.

What "ready to ship" actually means

Not perfect. Not complete. Not even pretty in every edge case.

Ready to ship means:

• The happy path works end-to-end.
• The 5 most likely failure paths don't lose data.
• The first 10 users can complete the core action without help.
• You can take payments (if relevant) and refund them.
• You can email users when things break.

That's it. Everything else is week 11.

A six-week timeline you can actually plan around

Week 0:  Wedge definition       (the founder's homework)
Week 1:  Strategy sprint        (5 days, locked scope)
Week 2:  Design                 (3 screens, all states)
Week 3:  Design + early build   (design lands Wednesday)
Week 4:  Build                  (auth, core flow)
Week 5:  Build                  (payments, second flow)
Week 6:  Build + QA             (third flow, friendly users)
Week 7:  Soft launch            (10 users, watch what breaks)
Week 8:  Public launch          (the start, not the end)

Yes, that's 8 weeks if you count the wedge week and soft launch. Most "6-week MVPs" are really 6 weeks of build sandwiched between a strategy week and a launch week. Fine. Don't lie to yourself about the timeline.

Want help?

MVP Development is one of our most common engagements. We run the strategy sprint, design the MVP, and ship production-grade code in 6–10 weeks. Most MVPs cost $25K–$45K.

If you have a wedge and runway, book a call. We'll tell you honestly whether your timeline is realistic — and if it isn't, what would be.

Stop talking about your MVP. Ship it.