Sixty days is not an arbitrary number. It's roughly the point at which a founding team's conviction outruns its evidence — long enough to build something real, short enough that you haven't spent a year being wrong in private.

We've run this playbook across dozens of products. It works, but only if you accept its central constraint: an MVP is one workflow done properly, not five done badly.

Days 1–10: Decide what you're not building

Most teams start by listing features. Start instead by writing the single sentence that describes the one job your product does. Everything that doesn't serve that sentence goes on a list titled "later" — and that list is the most valuable artefact of the whole phase.

  • Name the one workflow. If you need a comma to describe it, it's two workflows.
  • Write the success metric now. "Ten teams complete the workflow twice in a week" is a metric; "users love it" is not.
  • List the cuts explicitly. Scope creep is what happens when nobody ever wrote down what was out.

Days 11–20: Design the path, not the product

Design the screens that sit on the critical path and nothing else. Settings pages, admin panels, and onboarding tours can wait — every one of them is a week you're not spending on the thing people actually came for.

Get a clickable prototype in front of five people who resemble your buyer. If they hesitate, that's a design bug, and it costs an hour to fix now versus a sprint after it's built.

Days 21–45: Build the spine

This is the only phase that involves substantial engineering, which is precisely why the first twenty days matter so much. The rule here is simple: buy everything that isn't your differentiator.

  • Authentication: use a provider. Nobody has ever bought a product for its login page.
  • Billing: use Stripe and their hosted flows. Custom checkout is a month you don't have.
  • Infrastructure: managed Postgres, managed hosting. Kubernetes is a problem you earn later.
  • Permissions: model roles on day one. Retrofitting multi-tenancy is genuinely brutal.

Every hour spent on infrastructure you could have rented is an hour not spent on the reason anyone would pay you.

Days 46–55: Make it survivable

An MVP still has to stay up. Add error tracking, basic logging, and automated tests around the money path — signup, subscription, and the core workflow. Skip the exhaustive suite; cover the things whose failure would embarrass you.

Load-test the one endpoint you know will get hammered. Not all of them. Just the one.

Days 56–60: Ship to ten real users

Not a waitlist. Not a demo. Ten people using it for real work, with you watching the session recordings. What they do in the first ten minutes will tell you more than six months of internal debate.

Then resist the temptation to build everything they ask for. Look for the request that three of them make independently — that's signal. The rest is noise wearing a suit.

What usually goes wrong

In our experience the failure is almost never technical. It's a team that couldn't bring itself to cut the second workflow, and arrived at day 60 with two half-products instead of one whole one. The discipline is the deliverable.