Your Side Project Graveyard: A Post-Mortem

Every developer has one.

A folder on your hard drive. A page in Notion collecting dust. A list of repos you haven't pushed to in months. Some of them have proper READMEs. A few even have deployed staging environments that nobody, including you, has visited since October.

This is the side project graveyard. And if you've been coding for more than a year or two, yours is probably bigger than you'd like to admit.

I spent a Saturday afternoon recently going through my own. Seventeen repos. Eleven of them with fewer than twenty commits. Three of them I genuinely couldn't remember starting. One had a README that said "TODO: figure out what this does" which, honestly, past me, fair enough.

The graveyard isn't a personal failing. It's a nearly universal developer experience. But most people treat it like weather, something that just happens, nothing you can do about it. I disagree. The graveyard has patterns. The bodies in it died from the same causes. And once you see those causes clearly, you can stop adding to the pile.

Anatomy of a side project graveyard

If you sort your abandoned projects by how they died, a few categories emerge immediately.

The over-scoped dream. This is the project that started as "a simple tool to track habits" and somehow grew into a full platform with social features, an analytics dashboard, API integrations, and a mobile app roadmap. You didn't abandon it because you lost interest. You abandoned it because it became impossible to finish. The scope grew every week, the end kept receding, and eventually the gap between where you were and where you needed to be felt too large to cross.

These projects usually have the most commits. Forty, fifty, sometimes a hundred. You put real work in. It just wasn't enough, because the target kept moving.

The unvalidated idea. This project sounded brilliant for about three days. You built the first few screens, got the basic data model working, and then... something felt off. You couldn't articulate who would use it. The more you built, the less convinced you became. Eventually you stopped opening the project, not with a conscious decision but with a quiet drift into other things.

These projects usually have fewer than fifteen commits. The excitement burned out fast because it was never grounded in anything real.

The tech exploration. You wanted to learn Rust. Or try Svelte. Or build something with that new database you read about. The project was a vehicle for the learning, not the other way around. Once you'd learned enough to satisfy your curiosity, the project lost its purpose.

These are actually fine. Learning projects don't need to ship. The problem is when you count them against yourself as "abandoned projects" and feel bad about a thing that was never meant to be a product.

The boring-middle casualty. This project was going well. You had a clear scope. The idea was solid. But around week three, the remaining work was all wiring. Error handling. Edge cases. Deployment config. The interesting problems were solved and what was left was tedious. So when a new, shiny idea showed up, the old project couldn't compete.

These are the saddest graves, because the project was probably 70% done. Another two weeks of boring work and it would have shipped.

Why projects end up here

Every dead project in your graveyard died from one or more of four things:

No scope constraints. The project grew until it was too big, and you didn't notice because there was no written scope to measure against. Scope creep is the number one killer, and it happens by default unless you actively prevent it.

No validation. You built something nobody needed, or something you couldn't have finished in a reasonable timeframe, or something that already existed in a form you hadn't bothered to check. According to the Stack Overflow Developer Survey, most developers admit they've built things "nobody asked for." Validation is what separates projects that ship from projects that join the graveyard.

No accountability. Nobody knew you were building it. Nobody knew you stopped. There was no cost to quitting, so you quit. The Indie Hackers community is full of developers who recognize this pattern — the start-abandon-repeat cycle — but haven't found a system to break it.

No system. You relied on motivation and excitement to carry you through, and those are depletable resources. They always run out during the boring middle, and without a system to push through, the project stalls.

How to escape the graveyard

The escape isn't about working harder or wanting it more. It's about building a system that addresses each failure mode.

Lock your scope before building. Write down your features. Cap them at 5-7. Then lock the list so that adding anything new requires deliberate effort and documentation. When scope changes are visible and costly, they happen less.

Validate ideas before they become projects. Spend thirty minutes asking hard questions. Does this problem exist? For whom? How are they solving it now? Would they pay for something better? If you can't answer these clearly, the idea isn't ready for a repo.

Create accountability that persists. Build in public. Keep a visible project log. Use a system with permanent history. The goal is to make your abandonment patterns visible to yourself. Most developers don't realize how often they quit until they track it.

Set short timelines. A project that takes three weeks to ship has a fighting chance. A project that takes six months will probably die. Reduce scope until the timeline is weeks, not months. You can always expand in v1.1 after shipping.

Push through the boring middle, once. The boring middle is where most projects die. If you can get through it once, with a locked scope, on a short timeline, and ship something real, it rewires your expectations. You learn that the boring middle is temporary and that shipping feels good enough to be worth the slog.

From graveyard to Harbor

Here's what I think is missing from most "how to finish projects" advice: there's no positive endpoint. The advice is all about discipline and constraints and not quitting. Which, sure. But where's the payoff?

The payoff should be visible. A record of things you actually finished. Not your GitHub contribution graph, which shows activity, not outcomes. Not your resume, which lists skills, not shipped products. Something that specifically tracks what you started and what you completed.

In FoundStep, this is the Harbor. Your personal wall of shipped projects. Every project you mark as shipped lives there permanently. It shows what you built, when you shipped it, and how long it took. It doesn't show your drafts. It doesn't show your abandoned projects. It only shows what you finished.

The Harbor matters because it reframes the goal. You're not just avoiding the graveyard. You're building toward something visible. After two or three shipped projects, the Harbor starts to feel like an accomplishment in itself. You want to add to it. And wanting to add to it turns out to be a better motivator than wanting to avoid failure.

This is the shift: from graveyard to Harbor. From a growing list of things you didn't finish to a growing list of things you did. Both are permanent records. One makes you feel bad. The other makes you want to keep going.

Cleaning Your Current Graveyard

Before you can stop adding new entries, deal with the ones already there. Open every unfinished project and make one decision: ship it in the next four weeks, or kill it right now.

The rules:

• If you haven't touched it in 90 days, kill it
• If you can't explain the MVP in one sentence, kill it
• If the market moved on, kill it
• If you can strip it to three features and ship in four weeks, ship it

Most of your graveyard will get killed. That's the right outcome. Killing twelve abandoned projects and shipping one is better than maintaining the fiction that all thirteen are "in progress."

Killing a project isn't failure. It's a decision. You evaluated the situation and chose to redirect your energy. That's discipline. Abandonment is what happens when you avoid that decision. And if you want to actually ship a side project, clean the graveyard first.

Your Graveyard Is Data

Before you feel too guilty about all those dead repos, consider this: your graveyard is data. It tells you things about yourself if you're willing to look.

Which projects got the furthest? Those are the types of projects you're most likely to finish. What they have in common is worth paying attention to.

Where did they die? If most of your projects die around week three, you have a boring-middle problem. If they die in the first week, you have a validation problem. If they die after accumulating dozens of features, you have a scope problem.

What were you avoiding? Sometimes a project dies because you hit a technical problem you didn't know how to solve and you quietly moved on instead of asking for help or learning the skill. That's a different problem than scope creep or motivation, and it has a different solution.

Go through your graveyard. Be honest about what you find. Then build a system that addresses the actual patterns, not the patterns you assume you have.

And if you want a system that tracks all of this for you, FoundStep is built around the idea that the path from graveyard to Harbor is systematic, not motivational. Validate, plan, lock, build, ship. Each step has structure. Each failure is tracked. Each success is visible.

FAQ

Why do developers have so many unfinished projects?

Because starting is fun and finishing is boring. New projects give you a dopamine hit: the clean repo, the green-field decisions, the interesting architecture problems. Finishing requires grinding through error handling, edge cases, and deployment config. There's no external pressure to complete a side project, so most die during the boring middle.

How do I revive an abandoned side project?

Don't try to pick up where you left off. The context is stale, the code feels unfamiliar, and the original scope was probably too large. Instead, re-scope it to a much smaller v1. Look at what you already built and ask: what's the smallest useful version of this? Lock that scope and treat it like a new project with a 2-week deadline.

Is it okay to abandon side projects?

Sometimes, yes. If you validated the idea and it turned out to be wrong, abandoning is the smart move. You didn't quit. You made a decision based on evidence. If you abandoned because you got bored, distracted, or overwhelmed by scope, that's a pattern worth fixing because it'll keep happening with every new project.

How many unfinished side projects does the average developer have?

No hard data exists, but informal surveys across developer communities consistently show most developers reporting 5-15 abandoned projects. Some have significantly more. The number itself matters less than the pattern. One or two abandoned projects is normal exploration. Ten or fifteen suggests a systemic issue with scope, validation, or accountability.

What is the main reason side projects fail?

Scope creep. The project grows silently until it's too large for one person to finish in a reasonable timeframe, then gets abandoned. The scope grows because there's nothing preventing it: no locked feature list, no documented changes, no friction between having an idea and adding it to the backlog. The second most common reason is starting without validating whether the idea was worth building in the first place.