“Two weeks” sounds like a sales pitch until you see the schedule behind it. Here’s what actually happens inside those fourteen days, stage by stage — the same four stages every project here runs through: Define, Design, Build, Launch & Improve.
Days 1–2: Define
This is the stage most teams skip, and it’s the one that decides whether the other thirteen days are well spent. Before a single screen gets designed, we write down three things in plain language:
- The one user action that proves the idea works.
- Everything the product does not need to do yet, written down explicitly so it stops coming up in week two.
- What “done” looks like — not visually, but functionally: what a user can do end-to-end by day 14.
Most MVPs balloon in scope because nobody wrote this down. A scope doc that fits on one page is worth more than a 40-slide deck here.
Days 3–6: Design
Design moves fast because it isn’t starting from zero — it’s working from a system: type scale, spacing, components, and states already decided before the first screen is drawn. That means days 3–6 go toward the actual product flows, not toward relitigating what a button should look like.
By day 6, every core screen exists at least as a clickable prototype. Not polished — clickable. The goal is to catch flow problems while they’re still cheap to fix, which is “before engineering builds them,” not after.
If a reviewer can’t click through the whole flow by day 6, the schedule is already slipping — better to know on day 6 than day 12.
Days 7–12: Build
This is the longest stage and the most boring to describe, which is the point. Nothing here should be a surprise, because days 1–6 already removed the two things that blow up a build: unclear scope and undesigned edge cases. What’s left is writing the code.
We build in the order a user would hit things, not the order that’s technically convenient — the signup flow before the settings page, the core action before the nice-to-have one. That way, if day 10 runs long, what’s cut is the least important thing, not a random half-finished feature.
Days 13–14: Launch & Improve
Launch day is not a finish line — it’s the first time real data starts coming in. The last two days go toward making sure that data is actually usable: basic analytics wired up, a way to see where users drop off, and a short list of what we’re watching in week one.
An MVP that ships without a way to measure what happened isn’t an MVP — it’s a guess with a URL.
Why fourteen days, specifically
Not because it’s a round number. It’s roughly the longest a scope can stay frozen before someone’s priorities change, a competitor ships something, or the “quick idea” quietly turns into six other ideas. Fourteen days is long enough to build something real and short enough that the thing you agreed to build on day 1 is still the thing that ships on day 14.
If you’ve got an idea that keeps getting bigger every time you talk about it, that’s usually a sign it needs a Define stage before anything else.
