From Idea to MVP in 4 Weeks: A Founder's Playbook

Every founder eventually arrives at the same realization. The idea has been sitting in a Notion doc for six months. The “research” phase has become a polite synonym for procrastination. The longer the project lives only in conversation, the less it resembles something a real customer would pay for.

The fastest fix is to ship something. Not the final product. Not a polished beta. An MVP — a minimum viable product whose only job is to put a real artifact in front of real users so you can learn what you actually need to build.

Four weeks is the right amount of time. Less and you cut the wrong corners. More and you’ve lost the discipline that forced you to focus. What follows is the week-by-week playbook we use with founders — what we ship, what we cut, and how we spend your validation budget wisely.

What an MVP is actually for

Before the schedule, a definition. An MVP is not a small version of your final product. It’s a test of your most uncertain assumption.

That distinction matters. A small version of the product still assumes the product is right — it just builds less of it. An MVP starts from the assumption that you don’t yet know what the product should be, and is designed to surface that knowledge as cheaply as possible.

If your MVP launches and you can’t say what you learned, it wasn’t an MVP. It was just a small launch.

The MVPs that work follow a pattern. They identify the riskiest assumption — usually “will the target user actually pay for this?” or “will the target user actually use this every week?” — and build the smallest possible artifact that can answer the question. Everything else is cut.

Week 1 — Strategy and design

The first week is the one founders most want to skip and the one we most often refuse to skip. Building the wrong thing fast is worse than building the right thing slowly.

The week is structured around three deliverables:

A one-page strategy doc. Who the user is, what action you want them to take, what assumption you’re testing, and what success looks like. Same structure as a design brief — see How to Brief a Designer Without 5 Rounds of Revisions — but for the product as a whole.
A scope cut. A list of every feature the founder originally wanted, sorted into “Week 4 ship” and “version 2.” We aim for roughly five core features in the ship column. Anything more and the timeline slips.
Wireframes for every screen in the ship list. Low-fidelity, fast, and reviewed daily. By Friday, the wireframes are signed off and the engineering team has a clear blueprint.

The strategy doc lives in version control. We typically keep it next to the codebase, as a strategy.json file that anyone — designer, engineer, founder — can read on day twelve and remember what we agreed.

{
  "audience": "Solo creators selling digital products",
  "primary_action": "Connect a Stripe account and upload a first product",
  "core_hypothesis": "Creators will pay $19/mo for a hosted storefront with built-in email capture",
  "ship_features": [
    "Account creation and Stripe connect",
    "Single product upload with cover art",
    "Hosted storefront with one editable theme",
    "Email capture on the storefront",
    "Owner dashboard with sales count and email list export"
  ],
  "explicitly_cut": [
    "Multiple themes",
    "Custom domains",
    "Discount codes",
    "Mobile app",
    "Integrations with anything other than Stripe"
  ],
  "success_metric": "20 paying customers within 30 days of launch"
}

That file is the contract. Everything that gets built has to trace back to it. Everything that doesn’t gets cut.

Week 2 — Build the spine

Weeks two and three are full-stack development sprints. The goal in week two is the spine — the end-to-end happy path with no styling, no edge cases, and the absolute minimum of real database wiring.

By Friday of week two, a real user should be able to:

Sign up.
Complete the primary action defined in your strategy doc.
See some kind of confirmation that the action worked.

If those three steps work end-to-end — even if they’re ugly, even if they break under load — you’ve de-risked the project. Everything from here is polish and edge cases.

Two patterns we apply every time:

Use boring infrastructure. Auth is a vendor (Clerk, Supabase, Auth0). Payments are Stripe. Email is Resend or Postmark. Hosting is whatever your team already knows. None of these decisions deserve a week of evaluation in an MVP. Pick the default, ship the product.
Cut your own framework. No internal design system, no in-house ORM, no abstractions that won’t be reused. The most expensive thing in an MVP is code written to support code that doesn’t exist yet.

Week 3 — Polish and instrumentation

Week three is where the MVP starts to feel like a product. The visual design lands on top of the spine — type, color, spacing, micro-interactions — and the edge cases that would embarrass you in front of a paying customer get patched.

But week three is also when most teams forget to instrument. If you launch without analytics, you’ve built a beautiful MVP that can’t answer the question you set out to answer.

The minimum instrumentation:

Event tracking for the primary action. Whatever your strategy doc names as the goal, you need a counter for it. If you can’t see the number going up in real time, you can’t course-correct.
Funnel metrics for every step in the happy path. Signup, first action, second action, retention day seven. A simple table is enough for week one.
A way to talk to users. A live chat widget on the dashboard, or an intro@ email link, or a “book time” button. Real conversations beat dashboards in the first month.

The single highest-leverage move in week three is making it easy for users to tell you what’s broken. The closer they can get to a real human, the more you’ll learn.

Week 4 — Ship and stop

Week four is the smallest week. By Monday, the product is feature-complete. The team spends the week on QA, deployment, and writing the launch artifacts — the landing page, the welcome email, the help docs that explain the five things a confused user might need.

Then the founder stops.

This is the part most teams get wrong. They ship on Friday and immediately start building the next feature on Monday. The point of an MVP is to learn, and learning takes time. Reserve the next two weeks for talking to users, watching the funnel, and resisting the urge to build.

A good ritual: at the end of week six, the founder writes a one-page memo answering three questions.

What did we learn that we didn’t know on day one?
Was the core hypothesis confirmed, partially confirmed, or refuted?
Given what we now know, what’s the single most important thing to build next?

That memo becomes the brief for version two. If the answers are clear, you’ve earned the right to keep building. If they’re not, the MVP did its job by saving you six months of building the wrong thing.

What gets cut, and how to feel okay about it

The hardest part of a four-week MVP is not the schedule. It’s the cuts. Every founder has a list of features they’re sure are essential — and most of those features will not be in the launch.

A few patterns that make the cuts easier:

Cut anything that doesn’t change the answer to your core hypothesis. A second theme doesn’t change whether creators will pay $19/mo. Custom domains don’t either. Both can ship in version two if the core hypothesis is confirmed.
Cut anything that requires a third integration. Each new vendor adds a week of debugging. In an MVP you can afford one or two; you cannot afford five.
Cut anything that exists to please an investor or an advisor. You’re not pitching to them in week four. You’re learning from users. Build for the users.

A useful heuristic: write down every feature you want to cut, with the version (v2, v3, v4) where you’ll add it. The list itself is reassuring. The features aren’t gone — they’re scheduled.

When four weeks isn’t enough

Four weeks is a default, not a law. Some products genuinely need more — a connected-hardware product, a regulated fintech, a multi-sided marketplace where one side has to be live before the other has anything to do. In those cases, the MVP is usually the one side that has to exist first, and the four-week clock starts there.

But most products are not those products. Most products are SaaS, marketplaces, content tools, or consumer apps where the core loop is small and the validation question is “will real users do this real thing.” For those, four weeks is enough.

The hidden benefit

There’s a benefit to the four-week MVP that doesn’t show up in any case study. By forcing the cuts and the schedule, you find out very quickly whether your team can actually ship together. The friction points that would have killed you twelve months from now surface in week two. The decision-makers who can’t make decisions are revealed in week one.

Those are uncomfortable discoveries to make. They’re also the cheapest possible time to make them.

Where to go next

If you’re at the stage where the Notion doc has been open for six months, the next step is not more research. It’s a one-page strategy doc and a kickoff date. Both can happen this week.

For a complementary read on a topic that often comes up around an MVP launch — how to systematize your visual identity before you scale — see Why Every Brand Needs a Design System (Even Small Ones).