Too Many Side Projects, Can't Finish Any: How to Focus

You Have 15 Tabs Open and Zero Shipped Projects

You have eight repos on GitHub. Three have commits from this year. One has a README that says "Coming soon" from 2024. Two are private because you're embarrassed by the code. And one — the one that might actually be worth something — hasn't been touched in six weeks because you started something new.

Having too many side projects isn't a time problem. It's a decision problem. You don't need more hours. You need fewer projects. And the solution isn't "better project management" — it's killing projects you shouldn't be working on and committing to the one that deserves your focus.

You are busy. You are productive. You are writing code every day. And you have shipped absolutely nothing.

If this is you, congratulations on being a developer with lots of ideas and energy. Now for the uncomfortable part: having too many side projects is worse than having none.

Why More Projects Means Less Shipping

This seems counterintuitive. If you are working on five projects, surely at least one of them will get finished, right? That is like saying if you dig five holes, at least one of them will become a well. No. You will have five shallow holes.

The math is straightforward. Assume you have 10 hours per week for side projects. If you split that across five projects, each project gets 2 hours per week. At that rate, a project that would take 3 weeks of focused effort takes 15 weeks. In 15 weeks, you will have abandoned it at least twice, started two new projects, and the technology you chose will have a major version update that breaks your dependencies.

Context switching compounds the problem. Studies consistently show that context switching costs 20-40% of productive time. According to research from the American Psychological Association, switching between tasks can cost 20-40% of productive time. Every time you switch between projects, you lose time remembering where you left off.

But the worst cost is emotional. When you are spread across five projects, none of them make meaningful progress. You feel busy but unproductive. Imposter syndrome kicks in, not because you lack skill, but because you lack focus.

This is the side project graveyard in formation. Every abandoned project makes the next one harder to commit to, because your history tells you that you do not finish things.

There are also three hidden costs beyond lost time:

Emotional debt. Every unfinished project carries guilt. You know you should finish the invoicing tool. You feel bad about the abandoned habit tracker. This emotional debt compounds silently, creating background anxiety that saps energy from whatever you're currently working on.

Skill plateau. Starting projects teaches you setup, config, and scaffolding. Finishing projects teaches edge cases, production debugging, and iteration on real user feedback. If you only start, you repeat the easy parts and never learn the hard (and valuable) parts.

Reputation gap. Your portfolio is a collection of "Coming soon" pages and half-built prototypes. Hiring managers, potential co-founders, and customers look for shipped products. One shipped project with real users is worth more than eight unfinished repos.

Why Developers Collect Side Projects

You're not hoarding projects because you're lazy. You're hoarding them because starting is intoxicating and finishing is boring.

Starting a new project is pure dopamine. Fresh repo. Clean codebase. No legacy decisions to live with. No bugs from code you wrote three weeks ago. You're solving new problems, exploring new tech, and everything feels possible.

Finishing a project is the opposite. You're fixing edge cases. Writing docs. Handling error states. Testing on browsers you hate. Doing the unglamorous work that turns a prototype into something shippable.

Shiny Object Syndrome is what happens when the excitement of a new idea consistently overrides the commitment to a current project. New ideas arrive with all their potential and none of their problems. Your current project has messy code, hard bugs, and boring work ahead. The new idea has none of that because you have not started building it yet. Of course the new idea feels better. It is a fantasy competing against a reality.

And there are no consequences for abandoning a side project. When you abandon a team project, people notice. Standups get awkward. When you abandon a side project, nobody notices. The repo sits silently. No notifications. No accountability. No consequences.

Step 1: Audit Your Active Projects

Grab a piece of paper or open a blank document. Write down every project you are currently "working on." Be honest. Include the ones you have not touched in two weeks but still consider active. Include the one you started yesterday.

For each project, answer these questions:

1. When did I last work on this?
2. What percentage complete is it?
3. Could I ship a v1 in the next two weeks?
4. Is there a real person who wants this?
5. Am I excited about this, or just guilty about abandoning it?

Be honest with your answers. Most developers who do this exercise discover that they have 3-5 "active" projects, 1-2 of which they have not touched in over a month. Those are not active projects. Those are abandoned projects you have not admitted to yet.

Step 2: Kill Most of Them — The Build/Wait/Kill Framework

For every project on your list, answer three questions:

1. Does the problem still matter to you? Not "is it a good idea" — do you still care about solving this problem? If the excitement is gone and only guilt remains, that's a kill signal.
2. Can you ship an MVP in four weeks or less? If the current scope requires months of work, either the scope is too big or the project is too ambitious for a side project right now.
3. Has anyone asked for this? Not "would someone use this" — has an actual human expressed interest?

Projects that get three yeses: build. Projects with any nos: kill or park.

Be ruthless. You probably need to kill 80% of your active projects. Not "put on hold." Not "come back to later." Formally, consciously, explicitly decide that these projects are done. Archive the repos. Move the ideas to a "maybe someday" list. Tell yourself, out loud if you need to, "I am not building this right now."

Letting go of projects feels like waste. All that code you already wrote. All that time you already invested. But that code is a sunk cost. If you cannot bring yourself to kill a project, ask yourself: "If I did not have this code already written, would I start this project today?" If the answer is no, archive it.

Step 3: Pick the Right One

Do not pick the most exciting one. Excitement fades. In two weeks, the project you pick today will feel exactly as boring as the project you are abandoning today. Excitement is a terrible selection criterion.

Instead, consider these factors:

Which project is closest to shippable? A project that is 70% done is a better bet than one that is 10% done, because you need a win right now. You need to prove to yourself that you can finish something.

Which project solves a problem you personally have? Products built for your own use have a natural advantage: you are the first user, you understand the problem intimately, and you will know immediately whether your solution works.

Which project has the smallest scope? The smaller the project, the higher the likelihood of finishing it.

For ideas that are brand new and you have not built yet, validation matters. Running an idea through a validation process before building it is one of the best ways to prevent project sprawl. FoundStep's 7-Step Validation framework forces you to answer hard questions about your idea before you write any code, which kills bad ideas early and saves you from starting projects that were never going to work.

Step 4: Commit Publicly

Once you have picked your project, tell someone. Post about it. Tweet about it. Tell a friend.

"I'm going to ship [project name] by [date]."

Public commitment creates external accountability, which is something solo developers desperately lack. When you tell nobody, quitting is invisible. When you tell people, quitting requires explaining why you stopped.

This is not about pressure or shame. It is about making your commitment real. A decision you make privately is easy to reverse. A decision you make publicly has weight.

Step 5: Handle New Ideas Without Acting on Them

You will have new ideas. That is guaranteed. The question is what you do with them.

Here is the system that works: when a new idea appears, write it down in a dedicated ideas document. That is it. Do not scaffold a repo. Do not buy a domain. Do not design the logo. Write it down and go back to your current project.

Then, after you ship your current project, review the ideas list. The ideas that seemed brilliant three weeks ago often look mediocre now. The ones that still feel compelling get considered for the next project. But do not start anything new until the current project is shipped.

This system works because it respects your creative brain without letting it hijack your productive brain. The ideas are captured. They are not lost. You can come back to them. But they do not get to interrupt the project that is already in progress.

If you have trouble with features specifically — where you keep adding new features to your current project instead of shipping it — that is a different flavor of the same problem. How to prioritize features as a solo developer covers that in detail.

Why Idea Validation Prevents Project Sprawl

Most side project sprawl happens because developers skip validation. An idea pops into your head, you get excited, and you start building. Two weeks later, you realize the idea has problems. But by then, you have already invested time and emotional energy into it, so instead of killing it, you keep it "active" and start a new project.

If you validated ideas before building them, most of them would die at the idea stage instead of the half-built stage. That means fewer active projects, less guilt about abandoned code, and more focus for the project that actually deserves your time.

Validation does not need to be a big production. Five conversations with potential users and honest answers to hard questions about market and motivation will eliminate 80% of bad ideas. The 20% that survive validation are worth building, and you will build them with more confidence because you know they solve a real problem.

The One-Project Rule

I want to propose something that might feel radical: adopt a one-project rule. One active side project at a time, no exceptions.

When you finish and ship that project, you can start another. When a new idea appears, write it down and wait. When your current project gets boring, push through instead of switching.

This rule is hard to follow. Your brain will fight you on it because new ideas genuinely feel more rewarding than finishing old ones. But the developers I know who ship consistently all follow some version of this rule, whether they call it that or not.

One project. One focus. One ship date. Everything else is a distraction.

What Happens When You Focus

Let me tell you what happens when you actually commit to one project.

The first few days feel constraining. You will want to open that other repo. You will want to start that new idea. Resist.

After about a week, something shifts. Because you are not splitting your attention, you make more progress in one week than you made in the previous month across all your projects combined. The project starts feeling real. Features connect to each other. The finish line starts looking reachable.

After two weeks, you are in a rhythm. You know the codebase inside and out. You are not spending time context-switching or re-reading your own code. Every hour of work produces real, tangible progress.

After three or four weeks, you ship. And the feeling of shipping one finished project is worth more than all the excitement of starting ten unfinished ones.

That shipped project goes in your Harbor — a permanent record of what you've actually built and launched. It is proof that you can finish things. And that proof changes the way you approach every future project.

The Future Is Not About Having More Ideas

You already have enough ideas. You probably have too many. The bottleneck in your development career is not idea generation. It is idea execution.

Every hour you spend starting a new project is an hour you are not spending finishing an existing one. Every new repo is a commitment you are making, whether you realize it or not.

The developers who build real things, who launch real products, who create real value, are not the ones with the most ideas. They are the ones who pick one idea and see it through to the end.

Pick one. Kill the rest. Ship it.

Sign up for FoundStep and start shipping instead of starting.