How to Prioritize Features as a Solo Developer

The Framework Problem

You've read about RICE scoring. You've seen MoSCoW prioritization. Maybe you've tried ICE. All of these frameworks share one assumption: multiple people are making the decision. There's a team debating trade-offs, a product manager breaking ties, a designer arguing for user experience while engineering argues for feasibility.

You have none of that. You're one person trying to figure out how to prioritize features as a solo developer, and the frameworks built for product teams are actively working against you.

RICE asks you to score Reach, Impact, Confidence, and Effort on a scale. That's four variables you're assigning to yourself, debating with yourself, and scoring for yourself. You'll rationalize whatever score you need to justify building the thing you already wanted to build. The whole point of a scoring framework is to remove individual bias. When there's only one individual, there's nothing to remove.

MoSCoW is worse. "Must have, Should have, Could have, Won't have" sounds clean until you realize that every feature you thought of feels like a "must have" because you're the one who thought of it. Nobody is there to push back and say "that's actually a should have." You're judge, jury, and advocate all at once.

Research from Mind the Product shows that even lean prioritization methods need simplification for small teams. For a team of one, you need something that takes minutes, not hours — and that you'll actually use at 11 PM on a Tuesday.

The truth is, feature prioritization for a solo developer doesn't need a framework. It needs a filter. One binary question that cuts your feature list down to what actually matters.

Why This Is Harder When You're Working Alone

Let me be specific about what makes solo prioritization different from team prioritization, because the difficulty isn't just "there are fewer people." The difficulty is structural.

On a team, prioritization happens through conflict. The designer says the onboarding flow needs to be polished. The backend developer says the API needs pagination before anything else. The PM weighs both arguments and makes a call. That conflict is productive. It surfaces assumptions. It forces people to defend their priorities with reasons, not feelings.

When you're solo, there's no conflict. Every feature on your list came from your own brain, which means every feature feels equally justified. You thought of it, so obviously it's important. You can see exactly how it fits into the product, so obviously it's necessary. This is confirmation bias wearing a product management hat, and it'll keep you building forever if you let it.

There's another problem. When you're the PM, the developer, and the designer, your priorities shift depending on which hat you're wearing at any given moment. Right after you read a blog post about conversion optimization, the signup flow feels like the most important thing. An hour later, you're deep in code and suddenly the API architecture feels urgent. Before bed, you're sketching UI layouts and now the dashboard design is clearly the top priority.

This is why so many solo developer feature lists keep growing instead of shrinking. Your perspective changes hourly, and each perspective generates new "high priority" items. Without a fixed system, you're just chasing whatever feels most important right now.

Step 1: Brain Dump Everything

Start by getting every feature out of your head and onto a list. Every single one. Don't filter. Don't judge. Don't think about whether something is realistic or necessary. Just write.

Open a document. Set a timer for twenty minutes. Write down every feature, improvement, and idea you have for your product. Include the obvious stuff like authentication and the ambitious stuff like AI-powered recommendations. Write down the features you're embarrassed to want and the features you know are overkill. Put it all on paper.

The goal here is to empty your mental backlog. As long as features live in your head, they have a kind of phantom importance. They feel urgent because your brain keeps surfacing them. Once they're written down, they lose that urgency. They become items on a list, not thoughts competing for your attention.

Most developers end up with somewhere between 20 and 40 features on this list. That's normal. If you have fewer than 15, you're probably filtering already. Stop it. Add the stuff you think is "too small to count" and the stuff you think is "obviously for later." Everything goes on the list.

This is the raw material. Now you can start cutting.

Step 2: Apply the "Would Someone Pay Without This?" Test

Here's the filter that replaces RICE, MoSCoW, ICE, and every other framework you've been struggling with. For every feature on your brain dump list, ask one question:

Would someone pay for this product if this feature didn't exist?

Not "would they prefer it." Not "would it be better with it." Would they hand you money for a product that doesn't have this specific feature?

Go through your list, one item at a time. Authentication? Nobody's paying for software they can't log into. Yes, it stays. A dashboard showing their core data? That's the product. Yes. Dark mode? Be honest. Has anyone ever refused to buy software because it only had a light theme on day one? No. It goes to the v1.1 list. Export to CSV? Same thing. Notifications? Same thing.

This test is doing the work that a product team would normally do through debate. It's forcing you to distinguish between "this is the product" and "this would make the product nicer." The first category is your v1. The second category is everything after.

This is the core of mvp feature prioritization: figuring out what the minimum actually is. Not the minimum you're comfortable with. The minimum that someone would pay for. Those are very different numbers.

Be ruthless with this test. Proper mvp feature prioritization means being honest, not generous. If you're hedging on a feature, thinking "well, maybe some users would refuse to pay without it," that's a no. A real must-have doesn't require hedging. You know instantly that people need to log in. You know instantly that they need to see their data. The features where you have to argue with yourself are the features that can wait.

Step 3: Cap at 5-7 Features

After the "would someone pay" test, you should have a shorter list. But if you're like most developers, the list is still too long. Maybe you've got ten or twelve features that feel genuinely necessary.

Time for a harder filter: Would someone refuse to pay without this?

There's a difference between "would pay without it" and "would refuse to pay without it." The first test catches obvious non-essentials. The second catches the subtle ones. The features that are nice, that add real value, but that aren't deal-breakers for a first-time user who's giving your product a shot.

Your target is 5-7 features. That's it. If your solo developer feature list is longer than seven items after both filters, you still have too much. Something has to go.

"But my app is genuinely complex." I hear this a lot. And sometimes it's true. Some products really do need eight or nine features to function. But most of the time, when developers say this, what they mean is "I can't imagine launching without these features." Your imagination is not the same as market reality. Plenty of successful products launched with less than you think. Basecamp launched without Gantt charts. Dropbox launched without shared folders. They added those later, after they had users telling them what actually mattered.

If your solo developer feature list truly cannot get below seven features, that's a signal. Either your product is too big for a solo build, or you haven't found the real core of what you're making. Both of those are worth sitting with for a day before you start building.

Step 4: Order by Dependency

You now have 5-7 features. The question of what features to build first has a straightforward answer: look at dependencies.

Some features can't exist without other features. You can't build a dashboard without a database. You can't build user settings without authentication. You can't build search without having data to search through. These dependency chains determine your build order.

Map it out. Draw arrows if it helps. When deciding what features to build first, the dependency chain is the answer. Feature A requires Feature B, Feature B requires Feature C, so you build C first, then B, then A. This isn't complicated, but it's worth doing explicitly because your instinct will be to start with whatever is most exciting. Excitement is not a build order.

Once you've established hard dependencies, you'll probably have a few features that could be built in any order. For those, prioritize by user value. What's the first thing a new user needs to experience to understand why your product exists? Build that path first. Everything else comes after.

This step is also a good sanity check on your feature list. If you have a feature with no dependencies and nothing depends on it, that's suspicious. It might be a standalone nice-to-have that snuck through your earlier filters. Look at it again.

Step 5: Timebox Each Feature

Here's where prioritization meets reality. Take each of your 5-7 features and estimate how long it will take to build. Not "build perfectly." Build to the point where it works and a user can use it.

The rule: if any single feature will take more than three days, it's too big. Break it down.

"User authentication" might break into: email/password signup (1 day), login flow (half a day), password reset (half a day), session management (1 day). That's three days total, which is fine. But if you'd estimated "user authentication" as one item taking five days, you'd know the scope was wrong and something needed to be cut or simplified.

Three days is the ceiling for a reason. When a feature takes longer than three days, two things happen. First, you lose momentum. The satisfaction of finishing something is gone, replaced by the slog of a feature that just won't end. Second, the feature starts growing. Day four of building "the dashboard" is when you start thinking "while I'm in here, I might as well add sorting" and "the charts would look better with animations." A three-day cap prevents both problems.

If a feature genuinely can't be broken down below three days, that's another signal. Either the feature is too complex for your v1, or your definition of the feature includes too much polish. Ship the ugly version. You can make it pretty in v1.1.

After timeboxing, add up your estimates. If the total is more than three to four weeks of work, you have too much scope. Go back to step 3 and cut again. Most solo MVPs should take two to four weeks to build if the scope is truly minimal.

Step 6: Lock and Build

This is the step that separates developers who ship from developers who tinker forever. Once you've prioritized your features, ordered them by dependency, and timeboxed each one, you lock the list. It's done. No additions until v1 ships.

"But what if I realize mid-build that I need something I forgot?" Then you add it to a v1.1 list and keep building what's in front of you. The v1.1 list is your pressure valve. It lets you capture ideas without acting on them. Most of those ideas will look less urgent after you've shipped and have real users giving you real feedback.

If you want the full breakdown on scope locking, I wrote about it in detail in how to avoid scope creep as a solo developer and how to scope your MVP. The short version: create friction between wanting to add something and actually adding it. Make yourself justify every scope change in writing. If you can't write a convincing argument for why a feature must be in v1, it doesn't belong in v1.

FoundStep builds scope locking directly into the workflow, making it harder to deviate from your committed feature list than to stick with it. But you can do this manually too. The important thing is that re-prioritization stops once you start building. Every hour you spend debating priorities is an hour you didn't spend shipping.

The Three Mistakes That Kill Feature Prioritization

Treating All Features as Equal

When everything is a priority, nothing is a priority. This is the most common failure mode for solo developers. Your list has fifteen features and they all feel important, so you build whichever one you're in the mood for on any given day. You make progress on everything and finish nothing.

The whole point of prioritization is ranking. Some features are more important than others. If you can't say "this feature matters more than that feature," you haven't prioritized. You've just made a list.

Using Team Frameworks Solo

I've already covered this, but it's worth repeating because it's such a common trap. RICE, MoSCoW, and weighted scoring matrices are designed for groups of people who need a structured way to resolve disagreements. If you're one person, there are no disagreements to resolve. Using these frameworks alone just adds overhead without adding clarity. Feature prioritization as a solo developer needs to be fast and binary, not scored and debated.

Re-Prioritizing Mid-Build

This one is sneaky. You start building Feature A, hit a tough technical problem, and suddenly Feature B looks more appealing. So you "re-prioritize" and switch to Feature B. A week later, Feature B gets boring and Feature C seems more impactful. You "re-prioritize" again.

This isn't prioritization. This is procrastination with a professional-sounding name.

Builders on Indie Hackers who shipped fast consistently report that their cut features were almost always ego-driven or comfort-seeking, not user-driven. The pattern is consistent enough to be worth taking seriously.

Real prioritization happens once, before you start building. After that, you execute. If you find yourself wanting to re-prioritize, ask yourself honestly: is the priority actually wrong, or am I just avoiding something difficult? Nine times out of ten, it's the second one.

What 5-Feature MVPs Look Like in Practice

Theory is fine. Here's what proper feature prioritization produces in practice:

Bookmark Manager MVP (3 weeks):

1. Save bookmarks with one click
2. Organize into folders
3. Search saved bookmarks
4. Import from browser
5. Quick-access browser extension

Cut: social sharing, AI categorization, reading list mode, custom themes, mobile app.

Habit Tracker MVP (2 weeks):

1. Create habits with daily/weekly frequency
2. Log completions
3. View streaks
4. Simple dashboard
5. Basic reminders

Cut: social accountability, gamification, detailed analytics, push notifications, habit templates.

Both shipped. Both got real user feedback within a month. Both added cut features back in v2 — but only the ones users asked for.

What Happens After v1

Once you ship, everything changes. You have real users doing real things with your product. Some features you agonized over will turn out to be irrelevant. Some features you cut will get requested constantly. Some features you never considered will become obviously necessary.

This is the whole reason to ship a minimal v1. Not because minimalism is a virtue, but because building in a vacuum produces waste. Every feature you build before launch is a guess. Every feature you build after launch is informed by actual behavior.

Your v1.1 list, the one you've been adding ideas to throughout development, becomes your starting point. But now you filter it through real data instead of assumptions. Which features are users actually asking for? Which missing features are causing people to leave? That's your v1.1 scope.

If you haven't validated your idea yet, the validation process should actually come before prioritization. Know that people want what you're building before you decide what to build first.

How to Prioritize Features as a Solo Developer: The Complete Process

The complete process for how to prioritize features as a solo developer:

1. Brain dump every feature onto a list (20 minutes, no filtering)
2. Apply the "would someone pay without this?" test (cut everything that isn't essential)
3. Cap at 5-7 features (use "would someone refuse to pay without this?" if you need to cut more)
4. Order by dependency (build what other features depend on first)
5. Timebox each feature (3-day maximum per feature, break down anything bigger)
6. Lock the list and build (no re-prioritization until v1 ships)

That's it. No scoring matrices. No weighted criteria. No two-hour prioritization sessions where you end up right where you started. One binary filter, a hard cap, and the discipline to stop re-evaluating once you've decided.

That's how to prioritize features as a solo developer. The developers who ship are not the ones with the best prioritization framework. They're the ones who pick a small number of features, commit, and build straight through to launch. Everything else is noise.

FAQ

How many features should an MVP have?

5-7 features maximum. If more than seven pass your "would someone pay without this?" test, you're being too generous with what counts as essential. Tighten the filter to "would someone refuse to pay without this?" and the list will shrink. The goal is the absolute minimum that delivers your core value proposition. Everything beyond that is v1.1.

Should solo developers use RICE or MoSCoW for prioritization?

No. Those frameworks are designed for committee decisions where multiple stakeholders need a structured process to reach agreement. When you're one person, there's no disagreement to resolve. You need a simpler filter: does this feature need to exist for someone to use v1? Yes or no. Anything more complex than that just adds overhead and lets you rationalize building whatever you wanted to build anyway.

What features should I build first?

Start with dependencies. What has to exist for other things to work? Authentication before dashboard. Database schema before search. Data input before data display. Once hard dependencies are resolved, order by user value. What's the first thing someone needs to experience to understand your product? Build that path first. Then fill in the remaining features from your capped list.

How do I stop adding features to my MVP?

Lock your feature list after prioritization and make it painful to unlock. Keep a v1.1 list for new ideas that come up during development. Write them down immediately, then go back to building. If you want to add something to v1, force yourself to write a justification and identify what you're cutting to make room. If you're not willing to cut anything, you don't get to add anything. FoundStep enforces this with built-in scope locking, but even a manual process works if you commit to it.

Start Cutting

You have too many features. I know this without seeing your list, because every solo developer has too many features. The instinct is always to add more, not less. More feels like progress. Less feels like giving up.

It's the opposite. Less is what gets you to launch. More is what keeps you building forever.

Open your feature list right now. Apply the "would someone pay without this?" test. Get to 5-7 features. Lock it. Build.

The pricing page is there when you want tooling to enforce this process. But the process itself is free, and it works whether you use a tool or a text file. The point is to stop debating priorities and start shipping.