How to scope an MVP without overbuilding

Most first products are too big. Not because founders are careless, but because every feature feels essential when it's your idea. The result is months of building before a single real user says yes — or no.

Start with one painful problem

Write down the single problem your product solves, in one sentence, for one specific type of person. If you need the word and, you probably have two products.

List everything, then cut ruthlessly

Brain-dump every feature you've imagined. Then sort each one into three buckets:

• Must have — without it, the core problem isn't solved.
• Should have — makes it better, but users can live without it at first.
• Later — good ideas that can wait for real feedback.

Your MVP is the must have column. Be honest: most features belong in later.

Do it manually before you automate it

Many features can start as manual work behind the scenes. Instead of building a recommendation engine, hand-pick recommendations for your first 50 users. Instead of automated invoicing, send invoices yourself. You'll learn what users actually need before you pay to automate it.

Decide what “working” means

Pick one or two numbers that tell you the MVP is doing its job — for example, how many new users complete the core action in their first week. Decide this before launch, so you're measuring, not hoping.

Set a time box

Give your first version a fixed window, often six to twelve weeks. If the scope doesn't fit, cut scope, not quality. A smaller product that works beautifully teaches you more than a big one that barely works.

The takeaway

A great MVP isn't a cheap version of your dream. It's the fastest honest test of whether your dream solves a real problem. Scope it small, launch it well, and let real users tell you what to build next.

Want help shaping yours? Our First Light discovery sprint turns an idea into a focused, fixed-price build plan.