How to Scope a Startup MVP Without Killing Your Runway

Founders rarely come to me with too little ambition. They come with too much of it crammed into "version one."

I've scoped and shipped enough MVPs now to know the pattern that kills runway: the founder tries to prove the whole business model in the first release, instead of proving the one assumption that's actually in doubt.

Start with the assumption, not the feature list

Before you write a single user story, write down the riskiest assumption your business depends on. Not "will people sign up" — that's rarely the real risk. It's usually one of:

• Will people pay for this, or just say they would?
• Can we actually deliver the core service at the unit economics we've modeled?
• Does the workflow we're replacing actually have the pain we think it does?

Everything in your MVP should exist to test that one assumption. If a feature doesn't move the needle on it, it doesn't belong in v1 — it belongs in a backlog labeled "after we know this works."

The 80/20 that actually holds

A rule that has served every MVP I've scoped well: 80% of your engineering time should go into the one workflow that proves the assumption, done properly — not eight workflows done at 50%.

That means:

1. Pick one user role. Not admin + customer + partner portal. One.
2. Pick one path through the product. The happy path, end to end, with real data.
3. Fake everything else. Manual onboarding, a Slack notification instead of an automated email, a spreadsheet instead of a reporting dashboard. If it's not the thing you're testing, it can be manual for the first 50 customers.

What this actually costs

Most MVPs I take on land between $12k and $35k depending on scope, integrations and whether AI is involved. That range isn't arbitrary — it's what a fixed-scope, fixed-timeline build costs when the assumption is scoped correctly. When founders come in over that range, it's almost always because the "MVP" is actually three products stitched together.

The architecture debt you're allowed to take on

An MVP is the one place where I'll deliberately recommend technical shortcuts — as long as they're written down. Skip the queue system and process things synchronously. Skip multi-tenancy if you only have one paying customer. Use a monolith even if you eventually want services.

The debt that's not allowed: a data model you can't migrate away from, and no observability into whether the core assumption is actually being validated. Get those two things right, and everything else is negotiable.

How to know it worked

The MVP is done when you can answer the risky assumption with data, not opinion. If the answer is yes, you scope v2 around scaling the thing that worked. If the answer is no, you've spent six weeks and $20k finding that out instead of six months and $200k.

That's the whole game.