How to Decide What to Build as a Developer (When You Have Too Many Ideas)

The Paralysis of Possibility

I keep a text file called ideas.txt. Last time I checked, it had 47 entries. Some are a single sentence. Some have bullet points and rough feature lists. A few have domain names already purchased, which I now regret.

If you are a developer, you probably have a similar list. Maybe it is in Notion, or Apple Notes, or a folder of half-initialized repos. The ideas pile up because developers are natural problem-solvers. We see inefficiencies everywhere, and our instinct is to build something to fix them.

The problem is not having too few ideas. The problem is having too many. Paul Graham wrote about startup ideas being everywhere — he's right, but for solo developers, abundance is the enemy. And when everything looks like it could work, deciding what to build as a developer becomes its own form of paralysis. You spend weeks bouncing between ideas, starting one, getting distracted by another, and ultimately building nothing.

I have been stuck in this loop more times than I want to admit. And I have noticed something: the developers who actually ship things are not the ones with the best ideas. They are the ones who pick an idea and refuse to let go until it is out the door.

Why "Build What You Know" Is Incomplete Advice

You have probably heard this advice. Build what you know. Scratch your own itch. It sounds wise, and it is partially right. Personal experience with a problem gives you insight that outsiders lack. You understand the nuances, the edge cases, the specific frustrations.

But "build what you know" has a blind spot. It assumes your experience is representative. Just because you have a problem does not mean enough other people share it to make a product viable.

I once spent two months building a tool to organize browser bookmarks by project. I had that problem. I thought it was universal. Turns out most developers either do not use bookmarks heavily or are fine with the built-in browser folders. My personal pain was real, but it was not widespread enough to matter.

The better version of this advice: build what you know, then verify that other people know it too. Your experience is a starting point for empathy, not a substitute for validation.

Decision Frameworks That Actually Work

When you have multiple ideas competing for your attention, you need a consistent way to compare them. Here are frameworks I have found useful, along with their limitations.

Impact vs Effort Matrix

The classic. Draw a 2x2 grid. One axis is impact (how much value does this create if it works). The other is effort (how long will it take to build a usable version).

High impact, low effort ideas go first. Low impact, high effort ideas get killed. The other two quadrants require judgment.

This framework is simple, which is both its strength and its weakness. It works well for comparing ideas that serve similar audiences. It breaks down when you are comparing a B2B SaaS tool against a developer CLI utility, because "impact" means different things in different contexts.

The main trap here: developers consistently underestimate effort. That "weekend project" will take three weekends. That "simple API" will need auth, rate limiting, error handling, and docs. Be honest with yourself when plotting the effort axis.

The Five-Filter System

I developed this for myself after abandoning too many projects. Run each idea through five filters in order. If an idea fails any filter, it is out.

Filter 1: Do I care about this problem enough to work on it for six months? Not the tech. The problem. If the answer is no, skip it. Motivation fades, and caring about the problem is what gets you through the ugly middle.

Filter 2: Can I build a usable v1 in four weeks? If the idea requires three months just to reach something testable, the scope is too big for a solo developer starting out. Cut it down or pick something smaller.

Filter 3: Can I name five people who have this problem? Not "types" of people. Actual humans. If you cannot, you do not understand the market well enough yet.

Filter 4: Is there a clear way to reach these people? Building a product nobody can find is a waste. You need at least one distribution channel, whether it is SEO, a community you are part of, a social media following, or a partnership.

Filter 5: Would I use this myself? This is not strictly necessary, but it helps enormously. Being your own user shortens feedback loops and keeps you grounded about what matters.

The Regret Minimization Test

Ask yourself: if I do not build this, will I regret it in a year? This is a gut-check filter that surfaces ideas you are genuinely drawn to versus ideas that just seem smart on paper.

Some ideas look great on a spreadsheet but generate zero emotional pull. Those are the ones you will abandon in week three when the initial excitement wears off. The ideas that stick are the ones tied to something personal, a frustration you keep bumping into, a vision you keep coming back to.

The Role of Constraints in Better Decisions

Here is something counterintuitive: more constraints make decisions easier, not harder.

When everything is possible, you freeze. When you have limitations, whether they are time, money, skills, or audience, the field of viable ideas shrinks dramatically. And a smaller field is easier to choose from.

Useful constraints to apply deliberately:

Time constraint. "I have 10 hours per week to work on this." This eliminates ideas that require full-time effort to reach viability. It forces you toward simpler products with smaller scopes.

Skill constraint. "I am a frontend developer and not great at backend infrastructure." This points you toward products where your existing skills cover most of the work. Fighting your skill gaps is fine for learning projects, but a bad strategy for shipping.

Audience constraint. "I only have access to other developers through my existing network and online presence." This eliminates B2C consumer products and points you toward developer tools or B2B products.

Revenue constraint. "I need this to make $500/month within 6 months." This kills ideas with long payback periods and pushes you toward niches where people already pay for solutions.

Y Combinator's startup idea evaluation framework emphasizes that the best ideas solve problems people are actively solving with bad workarounds. Look for those workarounds. Spreadsheets doing the job of software. Three tools stitched together. Manual processes that cry out for automation. That's signal.

FoundStep's 7-Step Validation builds constraints into the decision process. It asks the hard questions about timeline, audience, and scope before you start building, which narrows your options to the ones that actually fit your situation.

The Graveyard Problem

If you have been a developer for a few years, you probably have a collection of abandoned projects. Half-built apps, expired domains, repos you have not touched in months. Each one represents a moment where you chose to start something new instead of finishing what you had.

I wrote about this pattern in escape the side project graveyard, and it is directly connected to the decision problem. When you do not choose carefully at the start, abandonment is almost inevitable. You pick something on impulse, the excitement fades, a shinier idea appears, and the cycle repeats.

The solution is not to find the "perfect" idea. Perfect ideas do not exist. The solution is to choose a good-enough idea, commit to it fully, and ship it before you allow yourself to start anything else.

This requires discipline, and honestly, discipline alone is not always enough. External structure helps. Some developers use accountability partners. Others use public commitments. Tools that enforce focus, like scope locking or feature freezing, can make it harder to wander off into scope creep territory.

What to Do With Ideas You Don't Build

Choosing one idea means rejecting the rest. Most developers fail here — they pick one but leave the other 14 ideas floating, creating background noise and future temptation. You need a clear system for rejected ideas.

Kill. The idea failed the filters. It's not worth building. Delete it, archive it, write "KILLED" next to it. Every killed idea clears mental space for the one you're building.

Park. The idea is decent but timing is wrong — you don't have the skills yet, or you need to ship something else first. Park it with a note about why and when you'll revisit.

Wait. The idea passed filters but lost to a stronger candidate. It's next in line. Ship the current project first, then evaluate this one again.

Here's a practical one-page decision matrix:

Idea	Problem I Know?	4-Week MVP?	Still Care in 3 Months?	Reach 10 Users?	Verdict
Snippet Manager	Yes	Yes	Yes	Yes (dev forums)	BUILD
AI Design Tool	No	No	Maybe	No	KILL
Budget Tracker	Yes	Yes	No	Maybe	PARK
Dev Blog CMS	Yes	Yes	Yes	No	WAIT

One page. Clear verdicts. No more scattered notes across five apps.

A Practical Process for Choosing Your Next Project

Here is the process I use now. It takes about two days, and it has saved me from starting at least a dozen projects I would have abandoned.

Day 1: Dump and Filter

Write down every idea you are considering. Do not edit, do not evaluate. Just get them out of your head.

Then cut the list. Remove anything you wrote down more than three months ago and never thought about again, because that means you do not actually care about it. Remove anything that would take more than two months to build a v1. Remove anything where you cannot immediately name the target user.

You should be down to 3-5 ideas.

Day 1 Evening: Score

For each remaining idea, score it 1-5 on these dimensions:

• Problem intensity (how painful is this for the target user?)
• Personal motivation (how much do I care about this specific problem?)
• Buildability (can I ship a v1 in 4 weeks with my current skills?)
• Reachability (can I get this in front of the right people?)
• Revenue potential (would someone pay for this, and how much?)

Add up the scores. The highest-scoring idea is your leading candidate. But do not commit yet.

Day 2: Stress Test

Take your top idea and try to kill it. Spend a few hours looking for reasons it will not work. Search for competitors. Look for Reddit threads where people discuss the problem and see if they seem satisfied with existing solutions. Try to find evidence that the market is too small or the problem is not painful enough.

If the idea survives the stress test, you have your project. If it dies, move to the second-highest scorer and repeat.

This process works because it combines intuition (personal motivation) with analysis (market signals). Neither alone is sufficient. Pure intuition leads to building things nobody wants. Pure analysis leads to building things you do not care about. You need both.

When The "Wrong" Choice Is Still The Right Move

I want to push back on the anxiety around choosing. Developers sometimes treat this decision like it is irreversible, as if picking the wrong project will ruin their career or waste years of their life.

In reality, most projects take weeks to months, not years. If you pick wrong, you learn something. You learn about a market, or about your own preferences, or about what kind of work drains you versus energizes you. That learning compounds.

The developers I admire most have all built things that "failed." They shipped a product nobody used, or built something the market did not want, or discovered halfway through that they did not care about the problem. And then they took what they learned and built something better.

The real failure is not choosing wrong. The real failure is not choosing at all, staying in the comfortable space of "I have a lot of ideas" without ever testing any of them.

Making the Decision Stick

Choosing is only half the battle. Sticking with the choice is the other half. Here are some tactics that help.

Tell someone what you are building and give them a deadline. Social accountability creates just enough pressure to keep you moving when motivation dips.

Write a one-page project brief. Define the problem, the target user, the core feature, and the ship date. Put it somewhere you will see it. When a new idea tempts you, re-read the brief and ask if the new idea is truly better or just newer.

Use a structured workflow. Prioritizing features as a solo developer gets easier when you have a system that forces you to evaluate each addition against your original scope. And watch out for shiny object syndrome — the urge to abandon a project the moment a new idea shows up is one of the top reasons solo developers never ship.

Set a review date. "I will work on this for 4 weeks and then evaluate whether to continue." This gives you permission to quit if the idea genuinely is not working, while preventing premature abandonment driven by boredom.

The best time to decide what to build was before you read this article. The second best time is right now. Open your ideas list. Run the process. Pick one. And start.

FAQs

How do I stop going back and forth between project ideas?

Set a deadline for your decision. Give yourself 48 hours to evaluate your top 3 ideas using a consistent framework, then commit. The cost of choosing a slightly wrong project is much lower than the cost of never starting.

Should I build something I am passionate about or something the market wants?

Build something at the intersection. Pure passion projects often lack an audience. Pure market plays drain your motivation. The best projects solve a problem you personally care about that other people also have.

What if I pick the wrong project?

You will learn from it regardless. Most successful founders built several failed projects before finding the one that worked. The wrong project is still better than no project, as long as you ship it and learn from the outcome.

Is it better to build something small or something ambitious?

Start small. You can always expand a small project that gets traction. You cannot easily shrink an ambitious project that is draining your energy. Ship something in weeks, then decide if it deserves months.

How many ideas should I evaluate before choosing one?

Three to five is the sweet spot. Fewer than that and you might miss a better option. More than that and you will get stuck comparing. Write them down, run them through the same criteria, and pick one.