The Year I Stopped Starting Side Projects

I counted at some point in early 2024: I had fourteen repositories on my GitHub with some amount of real work in them that hadn’t been touched in over six months. A CLI tool for a use case I no longer had. A half-built FastAPI service for an app idea I’d abandoned when someone shipped a better version three weeks after I started. A static site generator I’d been building for myself instead of just using one of the existing ones, because apparently I needed to understand the problem from first principles.

Fourteen. I was proud of most of them when I started. They felt like capability, like proof that I was building things. By the time I counted, they mostly felt like clutter.

The Pattern

I’d start something on a Friday night or a Saturday morning. Usually there was a genuine itch — a tool I actually wanted, a problem I’d run into at work, something that seemed like it had a useful thing at the end of it. I’d get a weekend into it, hit the first real design decision, feel the project get heavy, and then an easier thing would present itself and I’d start that instead.

The easier thing was almost always the fun part of a different project.

I got very good at starting. I got very bad at finishing. And the half-built repositories piled up, each one a small monument to the enthusiasm I’d had about something before the hard part.

What Actually Changed

Nothing dramatic. I just stopped starting new things until the current thing was at a point where I could honestly describe what it did. Not shipped, not done — just functional enough to explain.

That’s a lower bar than “finished.” It still stops you from jumping to the next thing every time the current one gets hard. You can’t abandon the FastAPI service until it can actually do the one thing you built it to do. Once it can, you have options: keep going, or park it with a README that explains what it is.

The parking option matters. A repository with a clear README explaining what it is and why you stopped is more useful to future-you than a graveyard of half-typed files.

What I Gave Up

There are things I didn’t start last year because I held myself to this rule. Some of them I’m glad I didn’t start. A few of them I think about occasionally and wonder if they’d have been worth pursuing.

The FOMO on ideas is real. I keep a notes file of things I’d build if I had time — not to manage a backlog, but because writing it down usually makes the idea feel less urgent. Most of them look worse after two weeks in a text file.

What’s Actually Running Now

One personal project that does something I use every week: a small FastAPI service that pulls cycling data from Garmin and posts a summary somewhere I’ll see it. It’s not impressive. It does what I needed it to do and I actually finished it.

This site. Which I’m treating as an ongoing project — writing is the work, the site is the publishing mechanism. Low complexity, low overhead, and the habit of writing is the goal rather than the software.

That’s it. Two things.

On the Guilt

The fourteen abandoned repositories didn’t disappear when I decided to start fewer things. I archived the ones that were clearly never going to be touched. I deleted a few that were embarrassing. Left the ones that still had some plausible future.

But the guilt about them mostly went away, which surprised me. Starting fewer things made the existing things feel less like a mess I was responsible for cleaning up and more like a collection of experiments, some of which worked and some of which didn’t. That reframe happened on its own once I wasn’t adding to the pile.

I don’t think everyone should do this. Some people thrive on parallel exploration and have the follow-through to make it work. I am not that person. I work better on one thing at a time with actual focus on it, and I spent several years ignoring that about myself.