Scoping an MVP is the most important decision you make before you build. Here's a step-by-step guide to defining exactly what goes in your first version, and what doesn't.
The most expensive mistake in software development happens before a line of code is written. It's not choosing the wrong technology. It's not hiring the wrong team. It's building too much in version one. An over-scoped MVP takes longer to build, costs more money, and often arrives too late to matter. An under-scoped one leaves out something critical and fails to test the idea. Getting scope right is the difference between an MVP that becomes your product and one you either rebuild or abandon. This guide walks you through how to scope an MVP properly, step by step, without needing a technical background.
What MVP actually means
Minimum Viable Product is one of the most misused terms in startup culture. Founders hear "minimum" and think "cheap." They hear "viable" and think "everything a user could possibly need." The result is a product that's neither minimum nor viable. The correct definition is simpler: an MVP is the smallest version of your product that lets you test whether your core idea works with real users. That's it. Not the smallest version that could theoretically exist. Not a stripped-down version of your full vision. The smallest version that answers the question your business depends on. Everything in your MVP should serve that one purpose. Everything else is scope creep dressed up as ambition.
Step 1: Write down the one thing your MVP needs to prove
Before you list a single feature, write down the core assumption your business rests on. Every product is built on an assumption about the world: users will pay for this, this process can be automated, people will change their behavior if you make it easy enough. Your MVP exists to test that assumption with real evidence. Write it as a sentence: we believe that [user type] will [do this thing] because [reason], and we'll know we're right when [measurable outcome]. For example: "We believe that independent restaurant owners will pay for a mobile inventory tool because managing stock manually wastes time and causes service failures, and we'll know we're right when 20 owners use it at least three times per week after a two-week trial." This sentence is your scope filter. Every feature that goes into your MVP should help you test this assumption. Every feature that doesn't is out of scope.
Step 2: List every feature you think you need
Don't edit yourself at this stage. Write down everything you think your product should do. Include the things you know are ambitious. Include the things you're not sure about. Get it all out of your head and onto a list. This list will be too long. That's fine. The next steps are about cutting it down to what actually matters.
Step 3: Sort every feature into three buckets
Go through your list and put every feature into one of three categories. Must have: features the product cannot work without, ones where, if missing, the product cannot do the one thing it exists to do. Be ruthless here, most features that feel like must-haves are actually nice-to-haves in disguise. Nice to have: features that improve the product but don't determine whether the core idea works, and belong in version two, not version one. Not now: features you want eventually but have no place in an early version, like future roadmap items, complex integrations, advanced analytics, or admin tools beyond the basics. A useful test for each feature: if a real user could get value from the product without this feature, it's not a must-have.
Step 4: Cut your must-haves in half
Once you have your must-have list, cut it. This sounds extreme. It's almost always the right call. Founders consistently overestimate what belongs in version one. Features that feel essential in planning often turn out to be unnecessary once real users start using the product, and sometimes they want something different entirely. For each must-have feature, ask: can users get the core value of the product without this? Could this be done manually, even clumsily, while we test the idea? Are we building this because users need it or because we assume they do? The features that survive this round of questioning are your real must-haves. The ones that don't survive belong in version two.
Step 5: Define your user types and what each one does
List every type of person who will use your MVP and exactly what they can do. Be specific. "Users" is not a user type. "Customers who browse listings" and "vendors who manage their listings" are user types, each with different screens, different permissions, and different flows that need to be built. For each user type write who they are in one sentence, what they can do as a list of specific actions, and what they cannot do, anything that might seem obvious but is out of scope for this version. Every user type you add multiplies the scope of the build: two user types is roughly twice the work of one, three is roughly three times. If you can launch with one user type and add others later, do it.
Step 6: Write the core user flows
A user flow is the step-by-step path a user takes to accomplish something in your product. Write a flow for each of the main things a user will do. Keep them simple, plain prose is fine. For example, a vendor listing a product for sale logs in, goes to their dashboard, clicks "Add listing," enters product name, description, price, uploads one photo, then clicks "Publish," and the listing appears in the marketplace. Writing these flows reveals decisions and edge cases that aren't visible in a feature list. What happens if the photo upload fails? What happens if the vendor tries to publish without filling in the price? What does the vendor see after they publish? These questions need answers before the build starts, not during it.
Step 7: List your integrations
Write down every third-party service your MVP needs to connect to. Common ones include payments (Stripe, PayPal, or a local payment gateway), email for notifications, receipts, or onboarding, SMS for alerts or verification codes, authentication for signing in with Google or Apple, maps for showing locations or calculating distances, and file storage for images or documents users upload. For each integration, note whether it's required for the MVP to work or whether it can be simplified or deferred. Integrations have an outsized impact on cost and timeline. A payment integration alone can add one to two weeks to a build. Know what you need upfront.
Step 8: Write your explicit out-of-scope list
This is the most underrated step in the process and the one most founders skip. Write down everything your MVP will not do: features you've decided to defer, integrations you're not building yet, user types you're not supporting in version one. This list does two things. It forces you to make deliberate decisions about what's out of scope rather than leaving it ambiguous, and it gives you something to point to when scope creep starts, which it will. When someone asks "can we just add this one thing," your out-of-scope list is the answer: not yet, it's on the list, we'll get to it in version two.
Step 9: Sanity check your scope against your timeline and budget
Once you have a clear scope, check it against your constraints. If you have three months and $30,000, your scope needs to fit inside that. If your development team tells you what you've scoped will take six months and $60,000, something has to change: either the scope shrinks, the timeline extends, the budget increases, or some combination of all three. This is not a negotiation, it's arithmetic. Software takes as long as it takes to build. The only variable you control is scope. If your scope doesn't fit your constraints, go back to step three and cut more aggressively. Ask your development team which features are taking the most time and whether simpler versions of them would work for an MVP. Often a feature that takes three weeks to build properly can be done in three days with a simpler approach that still tests the idea.
Step 10: Get it in writing before you build
Once your scope is defined, it needs to be documented and agreed before any code is written. This document, whether it's called a scope document, a product blueprint, or a statement of work, should specify exactly what is being built, what is explicitly not included, the timeline, the cost, and who owns what at the end. Read every line of it. Ask about anything you don't understand. Don't sign it until you're confident it reflects what you actually want to build. This document is what protects you if something goes wrong. It's also what keeps the project on track when new ideas come up during the build, which they always do.
The mindset that makes scoping work
Good scoping requires accepting one uncomfortable truth: you don't know exactly what your users want until they use the product. That's not a weakness, it's the entire point of an MVP. You're not trying to build the perfect product. You're trying to build the smallest thing that lets real users tell you what the perfect product should be. Every feature you add to version one before you have that feedback is a bet. Some bets pay off. Most don't. The founders who ship fastest and learn fastest are the ones who make the fewest bets in version one and use real user feedback to guide everything after. Scope tightly. Ship fast. Learn from real users. Build version two based on what you learn. That's how MVPs work when they work.