How to Scope an MVP: A Solo Developer's Guide to Building Less and Shipping More

Your MVP Is Too Big

I will bet money on this without knowing anything about your project: your MVP is too big. Y Combinator's guide on what an MVP really is frames it well: an MVP is a process, not a product. Your first version exists to learn, not to impress. Not because you are doing anything wrong, but because every developer's first instinct is to scope too large. We are builders. We see possibilities. And we have an almost pathological inability to distinguish between "the product needs this" and "I want to build this."

Learning how to scope an MVP is the single most practical skill a solo developer can develop. More practical than learning a new framework. More practical than optimizing your dev environment. More practical than reading about productivity systems. Because the number one reason side projects fail is not bad code or bad ideas. It is scope that grows until the project collapses under its own weight.

If you have ever started a project with a "quick weekend build" timeline and found yourself still working on it three months later, the problem was not your estimate. The problem was your scope. You were not building an MVP. You were building a full product and calling it an MVP because that made the timeline seem reasonable.

What an MVP Actually Is (And Is Not)

An MVP is the smallest version of your product that delivers its core value proposition to users. That is it. Not the smallest version that you would be proud of. Not the smallest version that competes with established products. Not the smallest version that "does it right." The smallest version that works.

An MVP is not a prototype. A prototype proves a concept. An MVP proves a business. It is something people can actually use, pay for, or at least give you meaningful feedback on.

An MVP is not a bad version of a good product. It is a complete version of a small product. This distinction matters because "bad version" implies you should keep adding until it is good, which leads to scope creep. "Complete version of a small product" implies you should ship what you have because it is, by definition, complete.

An MVP is not your vision. Your vision is the product you want to build in two years. Your MVP is the product you need to ship in two months. They are related but they are not the same thing, and confusing them is how you end up with a fourteen-feature "minimum" that is anything but minimal.

The 5-7 Feature Rule

Here is the most useful constraint I have found for scoping MVPs: your v1 should have between 5 and 7 core features. Not 10. Not 12. Five to seven.

This number is not arbitrary. It comes from observing which projects actually ship versus which ones stall. Projects with 5-7 features have a manageable scope that one person can build, test, and ship in a reasonable timeframe. Projects with 8 or more features hit a complexity threshold where things start interacting in unexpected ways, edge cases multiply, and the timeline extends past the point where motivation holds.

Before you object with "but my project is different," it probably is not. Let me show you what 5-7 features looks like for a few common side project types:

A task management app: create tasks, organize tasks into lists, mark tasks complete, edit/delete tasks, user authentication, basic settings page. That is six features.

A habit tracker: create habits, log daily completion, view streak history, user authentication, basic settings. Five features.

A link bookmarking tool: save links with tags, search/filter saved links, organize into collections, user authentication, import bookmarks. Five features.

Notice what is missing from these lists. No collaboration features. No integrations. No analytics dashboards. No export options. No mobile app. Those are all legitimate features for v2 or v3. They are not MVP features, and including them would roughly triple the build time for each project.

If your feature list is longer than seven items, you have two options. Cut features until you are at seven, or combine features until you are at seven. "User authentication" and "password reset" can be one feature. "Create items" and "edit items" can be one feature. Group related functionality until you have a list that fits.

The Payment Refusal Test

The most reliable filter for separating must-haves from nice-to-haves when you scope an MVP is what I call the payment refusal test. For every feature on your list, ask: "Would a real person refuse to pay for this product if this specific feature was missing?"

Not "would they prefer it." Not "would they ask for it eventually." Would they literally look at your product, see that it lacks this feature, and decide not to buy it?

Let me run through some examples:

A project management tool without the ability to create projects. Yes, someone would refuse to pay. That is the core functionality. Must-have.

A project management tool without Gantt charts. No. Plenty of people buy project management tools without Gantt charts. Many people actively dislike Gantt charts. Nice-to-have.

A SaaS without user login. Yes. People need to access their data. Must-have.

A SaaS without social login (Google, GitHub, etc). No. Email/password login works fine for v1. People might prefer social login, but they will not refuse to use the product without it. Nice-to-have.

An analytics tool without the ability to view your data. Obviously must-have.

An analytics tool without the ability to export your data to CSV. Probably no, for v1. Some users will want this, but it is not the reason they would buy or not buy the product.

When I apply this test honestly to my own projects, the feature list typically gets cut by 40-50%. Half of what I thought was necessary turns out to be things I wanted to build, not things users needed. That gap between want and need is where scope creep lives.

If you want more on validating your idea before scoping, that step should come first. There is no point in scoping a product nobody wants.

What Overscoped vs. Properly Scoped Looks Like

Here's the same idea scoped two ways:

Overscoped "MVP" for a developer portfolio builder: Custom domain support, theme editor, GitHub project import, blog section, analytics dashboard, SEO tools, social media integration, contact form builder, resume generator, custom CSS injection, newsletter widget. Ship time: never. This is Squarespace.

Properly scoped MVP for a developer portfolio builder:

1. Add projects with title, description, and link
2. Choose from 3 clean templates
3. Public portfolio URL
4. GitHub import for project list
5. Basic contact info section

Ship time: 3 weeks. The first version gets the developer a live portfolio with their projects. That's core value. Everything else is v2 — informed by what real users ask for.

Common MVP Scoping Mistakes

Mistake 1: "Everything Is a Must-Have"

This is the most common mistake by far. You write your feature list, you run each item through the payment refusal test, and somehow everything passes. Authentication: must-have. Dashboard: must-have. Notifications: must-have. Dark mode: must-have. Search: must-have. Settings with seventeen options: must-have.

If everything on your list is a must-have, you are not being honest with yourself. Go back and be more ruthless. A feature is a must-have only if the product literally does not deliver its core value without it. Notifications might be nice, but can someone use your product without them? Yes? Then it is not a must-have.

Another way to catch this mistake: ask yourself "could I charge for this product if I only had three of these features?" If the answer is yes, then at least some of your "must-haves" are actually nice-to-haves.

Mistake 2: Scoping for Imaginary Scale

You are building a todo app. You have zero users. And you are designing a database schema that can handle millions of records with sub-millisecond query times.

This is scoping for scale you do not have and might never have. Every hour you spend on scalability before you have your first user is an hour you could have spent shipping. Your database can be SQLite. Your hosting can be a single server. Your architecture can be a monolith. These choices are fine for an MVP, and they will get you to launch weeks or months faster than the "proper" architecture you were planning.

If you get to 10,000 users and SQLite is choking, that is a fantastic problem. You can refactor then, with real data about your actual performance requirements instead of guesses about hypothetical ones.

Mistake 3: Building the Platform Instead of the Product

Some developers scope their MVP as a platform. Instead of "a tool that does X," they scope "an extensible system that can be configured to do X, Y, Z, and anything else through a plugin architecture."

This is not an MVP. This is a framework. Frameworks take years to build properly, and building one when you should be building a product is a reliable way to never ship anything.

Your MVP is a product. It does one thing. It does it in one way. It does not have plugins, extensions, custom themes, or an API for third-party integrations. Those are all legitimate future features, but they do not belong in your first version.

Mistake 4: Confusing Polish With Scope

Loading skeletons. Animated transitions. Custom error pages. Empty states with friendly illustrations. Keyboard shortcuts. Responsive design for every screen size. These are all forms of polish, and they are all scope.

I am not saying your MVP should look terrible. But there is a wide spectrum between "looks terrible" and "has custom loading animations on every page." Your MVP needs to look functional and trustworthy. It does not need to look like a design portfolio piece.

Every hour spent polishing is an hour not spent shipping. And a shipped product with basic styling beats an unshipped product with perfect animations every single time.

Mistake 5: No Clear Definition of "Done"

If you do not know what "done" looks like for each feature, you will keep building each feature indefinitely. A feature without a clear endpoint is a feature that will consume unbounded time.

For every feature on your list, write down the specific, concrete thing that must be true for that feature to be complete. Not "user dashboard" but "a page that shows the user's projects with name, status, and last-updated date. No charts. No filters. No sorting. Just a list."

The more specific your definition of done, the harder it is for scope to creep within a feature. And feature-level scope creep, where you keep adding to a feature that is "almost done," is just as dangerous as project-level scope creep.

Step-by-Step: From Idea to Scoped MVP

Here is the process I use every time I start a new project. It takes about an hour, and it saves weeks of wandering.

Step 1: Write one sentence that describes what your product does. Not what it could do. What it does. "A tool that helps solo developers track their projects and ship faster." If you cannot fit it in one sentence, your idea is too broad and needs narrowing before you can scope it.

Step 2: List every feature you can think of. Do not filter. Do not prioritize. Just dump everything. This is your brain dump, and trying to be selective during this phase just means you will remember the filtered-out items later and add them mid-build. Get them all out now.

Step 3: Run every feature through the payment refusal test. Be brutal. For each item ask: would someone refuse to pay for the product without this? Mark everything that fails as "v1.1." Your list should shrink by at least 30%. If it does not, you are not being honest with yourself. Try again.

Step 4: Check your count. If you have more than 7 must-haves, you need to cut or combine until you are at 7 or below. This is the hardest step because everything on the list feels necessary. Push through it. You will be wrong about some cuts and that is fine. You can add them back in v1.1 when real users tell you they need them.

Step 5: Write a specific definition of "done" for each feature. One or two sentences describing exactly what this feature does, what it looks like, and what it does not do. The "does not do" part is as important as the "does" part.

Step 6: Lock the scope. Write "LOCKED" at the top of the document. You are done scoping. Everything below this line gets built. Everything on the v1.1 list waits.

Step 7: Estimate your timeline. For a solo developer working part-time (10-15 hours per week), a well-scoped 5-7 feature MVP should take 4-8 weeks. If your honest estimate is longer, go back to step 4 and cut more aggressively.

If you want a tool that handles this process for you, FoundStep's Scope Locking feature lets you lock your feature list and tracks any changes you make afterward. But the process works just as well with a text file and some discipline.

The Uncomfortable Truth About "Minimum"

Most developers treat "minimum" as a dirty word. Building the minimum feels like cutting corners. It feels like shipping something inferior. It feels like admitting you cannot build the full version.

None of that is true.

Minimum is a strategy, not a compromise. You are not building less because you are lazy or incapable. You are building less because you have learned, probably through painful experience, that shipping a small thing teaches you more than planning a big thing.

Paul Graham wrote that startups should do things that don't scale. The same applies to MVPs: your first version can have manual processes, rough edges, and missing features. It just needs to work for the users in front of you right now.

Every successful product you use daily started as an MVP that would embarrass its creators today. The first version of just about any product you admire was missing features that you now consider basic. They shipped anyway, they learned from real users, and they built the right features in the right order based on real feedback.

Your side project does not need to be complete to be useful. It needs to be focused. A product that does one thing well is more useful than a product that does five things halfway. And the only way to get to "one thing done well" is to scope ruthlessly and ship before you feel ready.

Scope expansion happens in three predictable moments: during building (you realize it would be "so easy" to add something — it's not), after feedback (someone says you need a feature — write it down for v2, not now), and when you're bored (new features are exciting; the hard stuff you're supposed to be building isn't). Recognizing which moment you're in helps you resist it.

For more on shipping faster as a solo developer, that piece covers the execution side. And how to build an MVP fast walks through the 4-week sprint structure. This guide is about the planning side. Together, they form a complete path from idea to launched product.

Scoping Is a Skill, Not a Talent

I want to end with this: nobody is naturally good at scoping MVPs. It is a skill you develop through practice, and the practice involves getting it wrong repeatedly.

Your first MVP will probably still be too big. You will scope 7 features and realize during development that three of them are more complex than you estimated. You will ship late. That is normal. The point is not to scope perfectly on the first try. The point is to scope better than you would have without a system.

Each project you scope teaches you something. You learn which features are actually must-haves and which ones felt like must-haves in the planning phase but turned out to be irrelevant. You learn how long things really take versus how long you think they take. You learn that the features users ask for are almost never the features you predicted.

The developers who ship consistently, the ones with actual launched products instead of a graveyard of unfinished repos, are not smarter or more talented. They are better at scoping. They have learned, through repetition, how to find the real minimum in minimum viable product. That skill is available to anyone willing to practice it.

Use the best workflow for solo developers to pair your scoping process with a development workflow that keeps you on track after you have scoped.

FAQ

How many features should an MVP have?

5 to 7 core features. This is not an arbitrary number. Projects with more than 7 core features have dramatically lower completion rates because complexity compounds, edge cases multiply, and the timeline extends beyond the point where motivation holds. If your list is longer than 7, you have not found your actual MVP yet. Cut or combine until you are within range.

How do I decide what is a must-have versus a nice-to-have?

Use the payment refusal test: would a potential user refuse to pay for your product if this specific feature was missing? If they would still buy or use the product without the feature, it is a nice-to-have and belongs in v1.1. Be honest with yourself during this exercise. Most developers dramatically overcount their must-haves because they are thinking about the product they want to build rather than the product they need to ship.

Should I validate my MVP idea before scoping?

Yes, absolutely. Scoping an unvalidated idea is a waste of time because you might end up building the wrong thing perfectly. Validate your idea first to confirm the problem exists and people want a solution. Then scope the minimum product that solves that validated problem. The validation step often changes what you think the MVP should include, saving you from building features nobody wants.

What is the biggest MVP scoping mistake?

Treating everything as a must-have. Most developers cannot distinguish between features the product needs to function and features they want to build. The result is an "MVP" that is actually a v2 with 12 or more features, which takes three to four times longer than expected and often never ships. The fix is to apply the payment refusal test ruthlessly and accept that a real MVP will feel incomplete to you as the builder.

How long should it take to build an MVP?

For a solo developer working part-time on evenings and weekends, a well-scoped MVP should take 4-8 weeks. If your honest estimate is longer than that, your scope is probably too large. Either cut features or simplify their definitions of done until the timeline fits. A project that takes longer than 8 weeks to ship its first version has a high risk of being abandoned because motivation decays over time.