Most MVPs fail not because of bad code or wrong technology. They fail because the scope was wrong. Too many features, too little focus, and a budget that runs out before the product answers its most basic question: does anyone actually want this?
Good scoping is the single highest-leverage skill a founder can develop. It determines how fast you learn, how much you spend, and whether your first version actually validates the idea or just burns runway.
Start with one question, not a feature list
Every MVP exists to answer one question. Not five. Not "let's see what sticks." One question. Before you think about features, screens, or technology, write that question down.
Examples of good MVP questions:
- "Will restaurant owners pay 500 SEK/month to automate their booking confirmations?"
- "Can we reduce invoice processing time from 2 hours to 10 minutes using AI extraction?"
- "Will freelancers use a tool that auto-generates project proposals from a brief?"
Examples of bad MVP questions:
- "Can we build a platform for restaurants?" (too vague, no validation criteria)
- "Will people like our app?" (unmeasurable)
- "Can we compete with Salesforce?" (wrong scale for an MVP)
Your question should contain a specific user, a specific action, and a way to measure success. If it doesn't, keep refining it until it does. Everything else in your scope flows from this question.
The "would you pay for this?" test
Before writing a single line of code, test your assumption with real people. Not friends. Not your co-founder. People who match your target user profile and have the problem you think you're solving.
The test is simple: describe what you plan to build in two sentences. Then ask: "If this existed today, would you pay [specific price] for it?" Not "would you use it" (everyone says yes to free). Not "do you think it's a good idea" (everyone is polite). Would you pay.
If 7 out of 10 people say yes, you have something worth building. If 3 out of 10 say yes, refine the pitch or the idea. If nobody says yes, the scope question is irrelevant because you should not be building this yet.
This takes a week at most. Often just a few days. It costs nothing except your time, and it can save you tens of thousands in development costs on an idea that was never going to work.
What belongs in v1 vs v2
Once you have a validated question, scope the minimum product that answers it. Here is a practical framework with real examples.
v1 (must have): the core workflow that answers your question. One path through the product, end to end. If you are building a booking tool, v1 is: customer sees available slots, picks one, gets a confirmation. That is it. No calendar sync, no payment processing, no multi-location support.
v2 (after validation): everything that makes the product more convenient, more powerful, or more polished. Calendar sync, payment, email reminders, analytics dashboards, admin panels, multi-user support, mobile optimization.
A concrete example. Say you are building an AI tool that summarizes meeting notes:
- v1: Upload an audio file, get a text summary with action items. One page, one button, one output.
- v2: Live recording, team sharing, calendar integration, custom summary templates, search across past meetings.
The v1 takes 3 to 5 days to build. The v2 features are individually 1 to 3 days each but collectively add up to months. If you build v2 before proving v1 works, you have spent months on features that might never matter.
Common scoping mistakes
Building auth before validation. You do not need user accounts, login flows, or password reset on day one. Use a shared link, a simple access code, or just skip auth entirely for your initial test. Authentication is important for a product. It is irrelevant for a validation experiment. We see founders spend 2 to 3 weeks on auth before they have a single user to authenticate.
Over-designing the data model. Your v1 database schema should have 3 to 5 tables, not 25. If you are drawing an entity-relationship diagram that looks like a subway map, you are building a platform, not an MVP. Simplify until it feels uncomfortable. You can always add tables later. You cannot easily remove them.
Premature scaling.Do not set up Kubernetes, microservices, or a distributed cache for your first version. A single server handles thousands of concurrent users. You do not have thousands of concurrent users. You have zero. A SQLite database on a single machine will outperform most "scalable" architectures at your current scale, which is negligible.
Feature creep disguised as requirements."We need an admin panel" (you are the admin, use the database directly). "We need email notifications" (send them manually for the first 50 users). "We need analytics" (check your server logs). Every feature you add to v1 delays validation by days or weeks.
The 1-page scope doc
Before you talk to a developer (or an AI-native development team), write a 1-page scope document. Not a 30-page requirements document. One page. Here is the template:
Problem: 2 to 3 sentences describing the problem you are solving and who has it. Be specific about the user.
Validation question: The one question this MVP answers. Include how you will measure the answer.
Core workflow:3 to 5 steps describing what the user does, in order. "User uploads a document. System extracts data. User reviews and confirms. Data is saved." That level of detail.
Not in v1: A list of everything you are deliberately excluding. This is the most important section. It prevents scope creep by making the boundaries explicit.
Success criteria:What does "done" look like? "10 users have completed the core workflow and 7 said they would pay." Not "the app is finished."
This document takes 30 minutes to write. It saves weeks of misdirected development. When your developer or development partner reads it, they know exactly what to build and, more importantly, what not to build.
How scope affects cost
Scope and cost have a non-linear relationship. Doubling the scope does not double the cost. It triples or quadruples it, because complexity creates interactions between features that require additional design, testing, and debugging. Read more about this in our breakdown of the real cost of building an MVP.
A tightly scoped MVP with one core workflow costs 25,000 to 50,000 SEK and takes 3 to 7 days. The same idea with "just a few more features" costs 100,000 to 200,000 SEK and takes 4 to 8 weeks. The version with the admin panel, the analytics dashboard, and the email notification system? 300,000+ SEK and 3+ months.
The tightly scoped version gets you answers in a week. The bloated version gets you answers in three months, assuming you do not run out of money first.
The takeaway
Your MVP is not a small version of your final product. It is a focused experiment designed to answer one question as cheaply and quickly as possible. Scope it like an experiment: define the hypothesis, design the minimum test, run it, measure the result. Everything else is v2.
Write the 1-page scope doc. Cut everything that does not directly serve the validation question. Ship it in days, not months. Learn from real users, not assumptions. That is how you scope an MVP without wasting money.