How to Scope Your MVP: What to Build First, and What to Cut

Most first versions are late because scoping was treated as a question about which features to include, when it is really a question about what can be removed while one person still gets value once. Those two framings produce completely different products. This is the second one: how to find the thing that has to work, what to cut without guilt, and why doing part of it by hand is a legitimate answer rather than cheating.

Table of contents

• Start from the conversations, not a feature list
• The one-sentence test
• The five things that always creep in
• Doing it by hand is a feature
• How long it should take
• What done means for a first version
• Frequently asked questions

Start from the conversations, not a feature list

A feature list written in a quiet room is a list of things you find interesting to build. That is not the same as a list of things somebody needs, and the two overlap less than anyone expects.

If you have run the conversations from talking to users before you build, you already have the raw material. Go back through the notes and pull out only the moments where somebody described doing something awkward: the spreadsheet they maintain by hand, the message they send every Monday, the thing they check twice because they do not trust it. Those are the candidates. Anything on your list that no interview produced is a guess, and guesses belong after launch, not before it.

If you have survey answers rather than calls, the same filter works. Sort by the problems people described in their own words, not by the features they asked for. People are unreliable at naming solutions and very reliable at describing what annoyed them.

The one-sentence test

Write the sentence that has to be true for a single person to get value from your product one time. Not repeatedly, not at scale, not profitably. Once.

The shape is always the same: a person can do X and get Y without me being in the room. For example, "a founder can put up a page that collects emails and one survey answer, and see the answers". Everything you are considering building either has to exist for that sentence to be true, or it does not.

The value of writing it down is that it turns an argument with yourself into a test you can apply in ten seconds. Team accounts? Not required for one person to get value once. Billing? Not required, they can pay you by invoice for a month. A settings page? Almost never required, because a sensible default is a decision you have made rather than a feature you owe them.

Two honest caveats. The sentence has to describe value to the user, not activity: "a user can create an account" is not value. And if your sentence needs an "and" in the middle, you probably have two products and should pick one.

The five things that always creep in

These are the ones that feel mandatory and are not. In rough order of how much time they consume:

1. The settings page. Every option is a decision you refused to make, and each one multiplies the states you have to test. Ship your opinion. Add the toggle when a real user asks twice.
2. The admin dashboard. You are the admin, and at this size a database query does the job. Building internal tooling before you have customers is building for an imaginary version of your own company.
3. Integrations. Each one is a third-party API, an auth flow, an error surface, and a permanent maintenance obligation. Wait until someone names the specific tool as their reason for not paying you.
4. Onboarding flows. A guided tour is usually compensation for a confusing first screen. Fix the screen. With ten users you can onboard each one personally and learn more than any tour would have taught you.
5. The second use case. The most expensive item on the list, because it does not look like scope creep. It looks like ambition. Building for two audiences at once means doing neither well and learning nothing clean from either.

What does not get cut: the thing your one sentence describes, and anything that would embarrass you if it broke in front of a paying customer. Data loss, silent failures, and money handling are not polish, and they are the wrong place to be scrappy.

Doing it by hand is a feature

The most underused scoping move is to keep the promise and drop the automation. If the value is a weekly summary, you can write the first ten by hand and send them yourself. If the value is a migration, you can do it personally for the first few customers. The user gets exactly what they were promised; you skip weeks of building.

This is worth doing even when automating would be easy, because doing it manually is the fastest way to discover the shape of the job. You find out which parts are actually hard, which edge cases are common, and which step nobody cares about, all before you have committed any of it to code.

Two rules keep it honest. Never imply the manual thing is automated, because that is a promise you have to keep at scale. And set a threshold in advance for when it must be automated, in customers or in hours per week, so it does not quietly become your job forever.

How long it should take

Pick the timebox before you pick the features, because the reverse order always produces the same answer: slightly longer than you have. For one person working evenings and weekends, a first version that takes more than about six weeks is usually a signal that the scope is still too wide rather than that the idea is ambitious.

When you run over, resist the instinct to extend. Cut instead, and cut from the list of five above before you touch the one sentence. An estimate that doubles is normal; a scope that doubles is a decision you made without noticing.

The reason the timebox matters more than the features is that every week before launch is a week of learning nothing. You are working from interview notes that get staler, on assumptions no one has tested. Shipping something small restarts the flow of real information.

What done means for a first version

Done is not feature complete, and it is not bug free. Done is: a stranger can complete the one sentence without you, nothing loses their data, and you can tell when they succeeded. That last one gets forgotten and it matters most, because a launch you cannot measure teaches you nothing.

Practically, that means knowing how many people arrived, how many finished the main action, and where the rest stopped. Without it you are back to guessing, and the diagnostic in why nobody is joining your waitlist has nothing to work with.

Then keep the list of everything you cut. Not as a roadmap, as evidence. When users start asking for things, you will find that a surprising share of what felt essential is never mentioned by anyone, and that is the clearest proof the scoping worked.

Frequently asked questions

Is not a stripped-down product just a bad product?

Small and unfinished are different things. A product that does one job properly is small. A product that does five jobs badly is unfinished, and users can tell the difference immediately.

Should I charge for the first version?

Yes, and earlier than feels comfortable. Payment is the only feedback that cannot be given out of politeness, and a free first version teaches you what people will accept rather than what they value. There is more on setting the number in how to price your first indie SaaS.

What if a competitor already has all these features?

Then matching them is the one strategy guaranteed to fail, because you would be doing the same thing later and with fewer people. Being better at one specific job for one specific audience is the only opening a small product has.

How do I say no to an early user asking for a feature?

Ask what they would do with it and what they do today instead. Half the time the request dissolves into a smaller problem you can solve in an afternoon. When it does not, "not yet, and here is what I am doing first" is an answer people accept far better than founders expect.

When should I revisit the things I cut?

When two unrelated users ask for the same one, unprompted. One request is a preference. Two strangers converging is a signal, and it is worth more than anything on the list you wrote before launch.

Scoping well feels like losing something, because every cut removes a version of the product you had already imagined. The trade is that you find out whether any of it was wanted while changing your mind is still cheap. Write the sentence, cut everything that is not required for it, do the awkward parts by hand, and ship inside the timebox. The list of things you removed will still be there, and most of it will turn out not to matter.

Lighthouse is the waitlist, survey, newsletter, and feedback side of that first version, so you can validate and collect the evidence without building any of it yourself. From an indie dev, for indie devs and makers.