Every developer has a graveyard. Mine has a CHIP-8 emulator from a couple of years ago, half a college RPG written in C, a Gatsby portfolio (and a Next.js one, and a... you got it), some automation scripts that solved problems I no longer have, and a notebook full of side project ideas I will never start.
For a long time I treated this as a personal flaw. Lack of discipline, lack of focus, lack of something. Then I noticed that the developers I respect have graveyards too, sometimes bigger than mine. And the ones with the smallest graveyards were not the most productive ones, they were the most boring ones.
So the real question is not how to stop abandoning projects. It is knowing when abandoning is the correct move, and when it is just the easy one.
After enough years doing this, I noticed my abandonments fall into four buckets.
1. The project that taught you and stopped
This is the classic one. You start a CHIP-8 emulator because reading about how old systems worked feels exciting. The first week is amazing, opcodes mapped, display rendering, the test ROM finally showing something. Then you hit the part that is just... typing. The drawing logic, the input handling, the edge cases of the BCD instruction.
The dopamine drops. The IDE stays closed.
I have a folder for this kind of project. F0ReST, the text RPG from college that ended its life with a single bear fight and an ASCII title screen. The CHIP-8 I keep promising myself I will go back to. A Lex/YACC compiler I wrote for the same class and never extended.
The honest truth: most of these should be abandoned. Their purpose was learning, and the learning happened in week one. Finishing them would teach me nothing new, just punish me for getting excited in the first place.
The trap is feeling guilty about it. Guilt makes you start the same kind of project next month, because deep down you think this time you will be different. You will not. Accept the pattern, archive the repo, move on.
2. The project that life outgrew
This one hurts more, because the project was good and you were enjoying it.
A while ago I wrote about jumping into Omarchy. That "first impressions" post where I was wrestling with Hyprland and ABNT keyboards. I had a good time. The system was fast, the workflow was interesting, my desktop looked like a screenshot from r/unixporn.
I am not on Omarchy anymore. I am on Fedora.
Nothing about Omarchy got worse. I got busier. Personal life, hobbies that do not involve a screen, friends, family. At some point I noticed I was spending Saturday afternoons tweaking waybar instead of doing the things I had actually been wanting to do. The operating system became the project, and the project was competing with my life.
Fedora boots, runs my stack, and asks for nothing back. That is exactly what I needed.
This kind of abandonment is different because the project was not the problem. The problem was the position it occupied in my week. Sometimes the move is not to finish or quit, it is to demote.
3. The project built to die
Filmle was supposed to die, and it did.
When I built it, I knew up front that it would be online for one year. Twelve months of daily challenges, then dark. That decision changed everything about how I built it: no auth, no backend, no scale considerations, no roadmap. A static frontend, some clever string distance for typos, and a year of prompts generated with an LLM.
It ran for the full year and then I pulled the plug. The numbers were exactly what I expected on one side and slightly unsettling on the other: a small but steady stream of players from week one to week 52, and a roughly equal stream of bots and would-be hackers prodding the infrastructure the entire time. Two flat lines on the same chart, one of users, one of attackers, oddly similar in shape. A small reminder that anything you put on the public internet is interesting to someone, even if the someone is a script.
This is the most underrated way to "abandon" something. You decide at the start that the project has an expiration date, and that frees you to make it exactly as small as it needs to be. No premature scaling. No "what if it goes viral". No five year vision document.
It also makes the eventual shutdown emotionally trivial. You are not abandoning anything, you are collecting on a debt the project owed you from day one.
4. The project that knows when it is done
The other side of the coin.
Right now I am building a small endless runner. Nothing ambitious, a single mechanic, minimal art, maybe a leaderboard if I feel generous. What makes it different from most of my graveyard projects is not a deadline, it is the definition. Before I wrote a line of code I knew exactly what "done" looked like for v1. Whether it eventually ships to a store, sits on itch.io, or just lives on my hard drive is a separate decision and frankly a smaller one.
That distinction matters more than I used to think. A deadline is about when you stop. A closed scope is about what counts as stopping. Most of my graveyard had neither.
Writing down what "done" means before the first commit sounds boring, and it is. It is also the cheapest insurance I have found against scope creep, against losing interest halfway through, against the project quietly mutating into something I no longer want to finish. The plan can still change, but at least there is one to change.
How I decide now
When I feel the urge to walk away from something, I run a short list before I close the tab:
- Did I get what I came for? If the project was learning, did I learn the thing? If yes, abandoning is fine. The repo is just a receipt.
- Is the next 20% going to teach me anything? If the rest of the work is mechanical execution of stuff I already know, the project is done in my head. The code just has not caught up.
- Am I quitting because it is hard, or because it is not mine anymore? Hard is a reason to push through. Not mine anymore, when my life has shifted and the project belongs to a previous version of me, is a reason to let it go.
- Did I promise anyone, including myself, that this would ship? If yes, finish it. Even a small public commitment matters more than most people admit.
Most of the time the answer is "yes, abandon it", and the guilt is what makes me hesitate, not the project itself.
Closing thought
The graveyard is not the problem. The problem is treating every project like it has to live forever, and then feeling like a failure when something does not.
Some projects are lessons. Some are built to die. Some are demoted because life got bigger. And every once in a while, one is built knowing exactly what done looks like.
All four are fine. The trick is knowing which one you are holding.