The hardest part of building an MVP isn't the code. It's deciding what to leave out. Here's the framework we use to draw the line.

Every founder we talk to has the same problem, and it isn’t a technical one. They have a vision for a product that does fifteen things well. They need to launch something that does one thing well, and they have to choose which one.

That choice is the whole game. Get it right and you have a focused product in front of real users in weeks. Get it wrong and you spend six months building features nobody asked for, while the thing that mattered sits half-finished.

Here’s how we draw the line during the specification phase of every 90 Day MVP.

Start with the one job

Before we talk about features, we write a single sentence:

[Target user] uses this to [do one specific job] so they can [get one specific outcome].

If you can’t fill that in, you aren’t ready to scope features yet. If you can fill it in five different ways, you have five products. Pick one.

Everything in the MVP has to serve that sentence. Everything else waits.

The three questions every feature has to pass

Once the core job is clear, we put every proposed feature through three questions.

1. Does the core job break without it? If a user can’t complete the one job without this feature, it’s in. Sign-up and login usually pass. The thing your product actually does passes. A settings page with twelve preferences usually doesn’t.

2. Will it teach us something we need to know? An MVP is a learning tool. A feature that tests your riskiest assumption, like “will people actually pay for this?”, can earn a spot even if it isn’t strictly required.

3. Is there a manual workaround? Many features can be faked at first. Admin reports can be a database query you run on Fridays. Onboarding can be a personal email. Automated billing can start as an invoice. If a human can do it for the first hundred users, it can probably wait.

A feature has to pass the first question, or clearly pass the second, to make the cut.

What usually makes the list

Across the web and mobile MVPs we’ve scoped, the “in” list tends to look similar:

Accounts and authentication. Users need to get in, and you need to know who they are.
The core workflow, end to end, done well. This is where most of the budget should go.
Just enough admin to support real users without a developer on call.
Analytics so you can see what people actually do.
A way to get feedback, even if it’s just an email link.

What usually waits

And the “later” list looks similar too:

Multiple user roles and complex permissions
Deep customization and settings
Every integration a future enterprise customer might want
Native apps on every platform at once, when a responsive web app would prove the idea
Polish on screens that only a few users will ever see

None of these are bad ideas. They’re version 2 ideas. Writing them down on a prioritized roadmap, instead of pretending they don’t exist, makes them much easier to let go of.

Cut scope, not quality

There’s a myth that “minimum” means “sloppy.” It doesn’t. A good MVP does fewer things, but the things it does should be fast, reliable and pleasant to use. Users forgive missing features. They don’t forgive a confusing, buggy experience on the one thing you promised to do.

That’s why we’d rather ship four features that feel finished than ten that feel fragile.

The line is a tool, not a wall

During a 90 Day MVP, the in/out line we set during specification becomes the most useful document in the project. When a new idea comes up mid-build, and it always does, the question is simple: does it replace something above the line, or does it go on the roadmap?

That one habit is the difference between launching on day 90 and launching “soon.”

Have a product idea and not sure where the line should be? Tell us about it . Helping founders draw that line is our favorite part of the job.