Every founder I've worked with starts with a feature list, not a product. MVP scoping is the discipline of taking that list, usually 30 to 50 items long, and cutting it down to the one workflow that actually proves the business idea works. Get this step wrong and you'll spend six months and a real budget building things nobody asked for before you find out whether anyone would pay for the core idea at all.
The instinct to build everything at once comes from a reasonable place: you can see the whole product in your head, and every feature feels necessary because it's part of that vision. But an MVP isn't a smaller version of the final product. It's a test. Its only job is to prove or disprove the riskiest assumption in your business as cheaply and quickly as possible.
Here's the method I actually use when a client hands me a feature wish list, and a worked example of applying it.
Step 1: Find the Single Money-Moving Workflow
Every product has exactly one workflow where value actually gets created and exchanged. Everything else is support, convenience, or polish around that core loop. Your first job in MVP scoping is identifying that one workflow, not listing features.
Ask this question about every feature on your list: "if this feature did not exist, would the core transaction still happen?" If the answer is yes, it's not part of the MVP. It might be part of version 2, or version 5, but it is not part of what proves your business works.
For a marketplace app, the money-moving workflow is: a buyer finds a product, pays for it, a seller fulfills it. Notifications, reviews, wishlists, seller analytics dashboards, none of those are the money-moving workflow. They make the money-moving workflow nicer, but they don't make it exist.
For a B2B SaaS tool, the money-moving workflow is usually the one action a paying user does repeatedly that they were previously doing manually or with a worse tool. Everything else, onboarding flourishes, admin settings, white-labeling, is secondary until that core loop is proven to retain users.
Step 2: Build Only That Path, End to End
Once you've identified the workflow, build it completely, start to finish, with no gaps. A half-built core workflow is worse than a narrow but complete one, because a gap in the middle of the money-moving path means nobody can actually complete a real transaction, which means you learn nothing.
This is the part founders get backwards most often. They build the core workflow at 60% and then start adding secondary features, because the secondary features feel more finishable and give a sense of progress. Resist this. An MVP with one complete path beats an MVP with five incomplete ones, every time, because only the complete path can be tested with real users doing a real thing.
Step 3: Fake or Manual Everything Else
This is the step that saves the most time and money, and the one most founders are uncomfortable with. Anything outside the core workflow that still needs to exist for the business to function, but isn't the thing you're testing, should be manual or faked rather than built.
Examples I've used on real projects:
- Customer support: a WhatsApp number the founder answers personally, not a ticketing system.
- Inventory sync: a shared spreadsheet updated by hand, not a real-time integration.
- Payment reconciliation: manual checking against a bank statement, not automated matching.
- Onboarding: a founder walking a new user through setup on a call, not a polished in-app tutorial.
- Admin tooling: direct database queries run by the founder, not an admin dashboard.
None of this is embarrassing. It's correct sequencing. You build the automation once you've proven there's enough volume to justify automating it. Building the admin dashboard before you have ten users to administer is money spent on a problem you don't have yet.
Worked Example: Cutting 40 Features to 6
A founder came to me with a logistics coordination app for online sellers, wanting to launch with a feature list that included: multi-carrier rate comparison, automated label printing, real-time GPS tracking, a seller-facing analytics dashboard, a customer-facing tracking page, SMS notifications, a loyalty points system, bulk order import, warehouse inventory management, and a partner referral program, among others. Forty items total.
We walked through the money-moving workflow question: what is the one thing that, if it worked, would prove sellers will pay for this? The answer was: a seller creates a shipment, the system picks the cheapest reliable carrier automatically, and the seller gets a trackable label without manually comparing rates across four different carrier apps.
That cut the list to six for the MVP:
- Seller creates a shipment (manual form entry, no bulk import)
- System compares rates across 2 carriers (not multi-carrier, just the two most-used ones)
- System auto-selects the cheapest option above a reliability threshold
- Label generation
- Basic status tracking (manual carrier API polling, no real-time GPS)
- A simple dashboard showing shipment status per seller
Everything else, the loyalty program, SMS notifications, warehouse management, the referral system, got parked. Three months later, with the six-feature version live, we had actual data on whether sellers cared about automated rate comparison enough to pay for it. They did, which justified building the rest. If they hadn't, we'd have found that out for a fraction of the cost of the 40-feature build.
This pattern, proving the core loop before automating the surrounding operations, shows up constantly in logistics-adjacent products; see Logistics Tech: The Unsexy Edge for Online Sellers for more on why this specific layer matters so much for online sellers.
A Quick Scoping Table
| Question | If yes | If no |
|---|---|---|
| Does the core transaction fail without this feature? | Keep it in MVP | Cut or fake it |
| Can this be done manually for the first 20-50 users? | Fake it manually | Consider building |
| Does this feature test the business's riskiest assumption? | Keep it in MVP | Defer to v2 |
| Will this feature's absence stop us from learning anything? | Keep it in MVP | Cut it |
The Takeaway
MVP scoping is not about building small, it's about building narrow and complete. Find the one workflow that moves money, build only that end to end, and fake everything else with manual effort until real usage tells you what's worth automating. If you're mid-scoping and stuck on where to draw the line, why software estimates are always wrong is worth reading too, since a tighter scope is the single biggest lever you have over estimate accuracy.