← Back to the blog

MVP scoping that survives contact with reality

Most MVPs ship late because they were scoped on a whiteboard, not against a calendar. Here's the scoping pass we run before we quote a number.

An MVP is the smallest thing you can put in front of a real user that validates a real assumption. It is not the v1 of the product with two features removed. That distinction is the entire game.

Why MVPs slip

Most MVPs are scoped on a whiteboard against an abstract calendar ("6 weeks"). Then the team starts building, and reality arrives: auth needs password reset, payments need refunds, the admin console is a separate app, the legal review takes three weeks, and QA on iOS turns up four blockers nobody planned for.

None of those are surprises in retrospect. They were always going to happen. They just weren't in scope.

The cut

Before we quote an MVP, we run one pass with the client that we've started calling the cut. It has three steps.

  1. Write the assumption.One sentence. "Small business owners will pay $39/month to automate their VAT filings." If you can't write the sentence, you're not building an MVP, you're building a product on faith.
  2. List every feature on a card. Auth. Onboarding. Billing. The thing the assumption is about. Each card gets a rough estimate.
  3. Cut everything that doesn't test the assumption.Onboarding can be a calendar invite. Billing can be a Stripe payment link. Admin can be the Postgres console. If users won't notice, it doesn't go in v1.
The principleEvery feature in your MVP is a feature you have to maintain, fix bugs in, and migrate later. The cheapest feature is the one you didn't build.

The calendar test

Once we've cut, we run the result against a real calendar — not "six weeks" in the abstract, but six specific weeks with holidays, leave, code reviews, and the day the client's legal team takes for the privacy policy.

In our experience, an honest calendar pass adds 30–40% to the whiteboard estimate. Better to find that out before quoting than at week five.

What stays in v1

Things we almost never cut, even from MVPs:

  • Auth that won't embarrass you. Magic links or OAuth — never a homemade password flow.
  • Error reporting. Sentry or equivalent on day one. You will need it.
  • A real database with backups.SQLite is fine, but you need to know it's being backed up.
  • One way to talk to users. A live chat widget, a public email, anything. The cost of not hearing from the first 50 users is enormous.

Everything else is negotiable. Our services page walks through the engagement shape we use for MVP builds, or just send us a brief.

★ ★ ★

End of article · Thanks for reading

Subscribe

More of this, once a month.