Bury Your Darlings: A Field Guide to Killing Side Projects on Purpose

Here's an uncomfortable exercise: open your GitHub and count the repos with a single commit and a README that says "TODO: write actual README." Mine had eleven. This year I made myself shut down six projects formally — not let them rot, but kill them, document them, and move on. It was the most productive thing I did all year.

We treat shipping as a skill and quitting as a character flaw. That's backwards. Deciding what not to build is the harder, rarer skill, and almost nobody practices it on purpose.

The Graveyard, Annotated

1. A habit tracker with streaks and graphs. Died after five weeks. Post-mortem: I built the tracking infrastructure I found interesting, not the habit change the user needed. Lesson: if the fun part is the database schema, you're building for yourself.

2. A Chrome extension for tab management. Killed at v0.3. Post-mortem: the market was a graveyard already — I counted forty competitors, three of them excellent and free. Lesson: check the cemetery before you dig.

3. A newsletter for Midwest developers. This one hurt. Eleven issues, 84 subscribers, then silence. Post-mortem: I loved writing it and hated promoting it, and a newsletter with no distribution is a diary with extra steps. Lesson: the unglamorous half of a project is still half.

4. A recipe app for my family. Killed when I realized my mom would email me recipes anyway. Lesson: some problems are cultural, not technical, and no amount of React fixes them.

5. An AI-powered meeting summarizer. Started in the middle of the hype wave, killed when I admitted I had no access to users and no real differentiator. Lesson: momentum from a trend is not the same as conviction.

6. A portfolio redesign. Meta, I know. Killed at 60% because the redesign had become a way to avoid writing. Lesson: the project you retreat into is telling you something.

Why a Graveyard Page Beats a Wall of Repos

Most portfolios are museums of finished things and abandoned things, with nothing distinguishing the two. A visitor can't tell your triumphs from your ghosts.

So I added a graveyard section to my site: each dead project, one line on what it was, one line on why it died, one line on what I took from it. The reaction surprised me. Recruiters mentioned it. Other devs emailed me their own post-mortems. It reads as judgment — proof that I can tell the difference between a rough patch worth pushing through and a dead end worth leaving.

Nobody hires you for the projects you abandoned by accident. Some people will absolutely hire you for the ones you killed on purpose.

How to Run a Funeral

Keep it simple. Three questions per project:

• What did I hope would happen?
• What actually happened?
• What's the reusable part — code, lesson, or scar tissue?

Then archive the repo, write the two-paragraph post-mortem, and — this is the part that matters — delete the tab. Don't leave it "for later." Later is where side projects go to guilt you.

Six funerals this year. Two of the replacements are already further along than anything they replaced. Turns out the graveyard isn't where projects go to die. It's where your attention goes to get refunded.