How to Scope an MVP: A Founder’s Pre-Build Checklist

Most MVPs that fail don’t fail at coding. They fail at scoping. Founders end up paying for features no one uses, deadlines slide because nobody could agree on what “done” meant, and the launch ships with the wrong core flow polished and the right one missing entirely.

This is the checklist we run founders through before quoting custom software development for startups. Answer these ten questions honestly before you write a brief or get a quote, and you’ll save yourself months of rework and somewhere between $5K and $30K.

1. What is the single most important thing a user does?

Not three things. Not “our platform does X, Y, and Z.” One thing. The thing that, if it doesn’t work, the product is worthless. Write it down as one sentence in the format “a user can _______”. That sentence is your MVP. Everything else is v2.

2. Who is the user, specifically?

“Small business owners” is not a user. “The office manager at a 12-person law firm who currently uses Excel to track client intake” is a user. The more specific you can get, the easier every other decision becomes — what features matter, what the UI should look like, what they’ll pay, what channels reach them.

3. What do they do right now without you?

If they’re already solving this problem somehow — with a spreadsheet, with a competing tool, with a part-time employee — you’re replacing that. Your MVP needs to be visibly better than the status quo, not visibly better than nothing. If the answer is “nothing, this problem is brand new,” that’s a yellow flag — you may be inventing demand rather than capturing it.

4. What is your “first useful moment”?

From the second a user lands on your product, how long until they get something useful? 30 seconds is great. 5 minutes is acceptable. 20 minutes of setup before any value is delivered is a death sentence for an MVP. If your “first useful moment” takes long, your MVP scope should focus entirely on shortening that.

5. What are the three features you’d cut if you had to ship in half the time?

Imagine the budget got cut in half and the deadline moved up four weeks. Which three features go? Those are probably the things you should cut from v1 anyway. Founders consistently overestimate how much they need to ship to learn something. Real users will tell you what to add next; you can’t guess in advance.

6. How are people going to find this thing?

If the answer is “we’ll figure that out after launch,” stop. Distribution is a real part of the product. If your MVP requires SEO content to drive traffic, you need to start writing now — not after launch. If it requires paid acquisition, you need to know your CAC math. If it’s a B2B product sold via demos, you need to think about who’s booking those demos.

7. What does “successful MVP” look like as a measurable number?

Vague success criteria are how MVPs slip. Define the win up front: “100 signups in the first month,” “20% of trial users convert to paid,” “5 paying customers willing to upgrade.” If you don’t pick a number, you can’t tell whether v1 worked, which means you can’t make smart decisions about v2.

8. What integrations are non-negotiable in v1?

Each integration is its own sub-project. Stripe is two weeks. Google Calendar is two weeks. Your existing CRM is unknown until someone reads its docs. Be honest about which integrations are required for the MVP to be useful vs. which are nice-to-have. “Nice-to-have” goes in v2.

9. Do you actually own the data you need?

If your MVP requires data you don’t have — user-uploaded content, scraped data, a partner’s API access — figure out how you’re going to get it before you start building the UI on top of it. The data pipeline is half the work, and most founders forget to budget for it.

10. What happens in week 5 if you’re behind schedule?

Builds slip. Founders get sick, scope grows, integrations surprise you. Have a pre-committed answer: do you push the launch, cut more features, or pay for more engineering capacity? If you don’t have an answer in advance, you’ll panic-decide in the moment and it’ll be the wrong call.

Putting it together

If you can answer all ten questions in writing — not in your head — you’re ahead of 80% of founders kicking off an MVP build. A good development partner will work through these with you in a discovery call before quoting anything; if they skip straight to the quote, that’s a sign they’ll skip straight to building too, and you’ll end up paying for the gap.

The questions you can’t yet answer are exactly where to focus over the next week. Talk to users, look at competitors, do napkin math. By the time you’re ready to write the brief, the brief should almost write itself.

Want help working through the list? Our free consultation is a 30-minute call where we walk through these questions for your specific idea — no commitment, and you’ll walk away with a clearer scope whether or not we end up building it together.