What nobody tells you about side projects

I have a folder on my machine called archive. It is where side projects go to die. Half-finished CLI tools, abandoned API wrappers, a recipe app I was sure the world needed. Every developer I know has a folder like this. Most of us do not talk about it.

The side project graveyard is normal. But after years of starting things and watching them stall out, I have noticed patterns in what kills projects and what keeps them alive. Landbound and Routemade both survived. A dozen other projects did not. Here is what I think made the difference.

The first weekend is a trap

Starting a project is the most fun part. Everything is new. You are picking a stack, scaffolding the repo, building the first feature. Progress feels fast because there is no existing code to work around, no bugs to fix, no edge cases to handle.

Then week three hits. The exciting parts are done. What remains is the boring stuff: error handling, edge cases, the settings page nobody wants to build, deployment configuration. This is where most projects die. Not because the idea was bad, but because the work stopped being fun.

I have learned to judge a project idea not by how excited I am on day one, but by how I feel about the boring parts. If I care enough about the outcome to slog through building password reset flows and writing database migrations, the project has a chance. If I am only in it for the initial rush of building something new, it will be dead by month two.

Scope creep is a slow killer

The feature list always grows faster than the motivation shrinks. You start with "a simple app that does X" and before you have shipped anything, you are planning user accounts, team features, an API, and a mobile app. None of these things are wrong to build eventually. But planning them before you have shipped version one is how projects become permanently unfinished.

The best side project scope is embarrassingly small. When I started Routemade, the first version did exactly one thing: take a GPX file and render it on a product. No accounts, no sharing, no customization options. That version shipped. Everything else came after.

The rewrite trap

This one got me more times than I want to admit. You build something in one framework, it works but the code is messy, and you decide to rewrite it in a different framework "the right way." Three weeks into the rewrite, you have recreated maybe 60% of the original functionality, your motivation is fading, and you have a new idea you would rather work on.

The rewrite is almost never the right move for a side project. Messy working code is infinitely more valuable than clean unfinished code. If the original stack works, keep building on it. Refactor incrementally if the code bothers you, but do not start over.

I rewrote an early version of Landbound twice before I learned this. Both rewrites died. The version that survived was the one where I forced myself to keep going with the existing code, even when I hated parts of it.

What actually works

A few things have consistently helped me finish projects instead of abandoning them:

Ship something ugly early. The first public version should make you slightly uncomfortable. If you are not a little embarrassed by it, you waited too long. Ugly and live beats polished and private every time.

Tell someone about it. The moment another person knows about your project, the cost of abandoning it goes up. It does not have to be a public launch. Just telling a friend "I am building this thing" creates enough accountability to push through the boring parts.

Use boring technology. Side projects are not the place to learn a new framework, a new language, and a new deployment platform all at once. Use what you already know. The goal is to ship the product, not to pad your resume. Every technology decision you have to research is time you are not spending on the actual idea.

Work on it regularly, even if just a little. Thirty minutes three times a week beats an eight-hour Saturday session followed by two weeks of nothing. Momentum matters more than intensity. The projects I finished were the ones I touched consistently, not the ones I sprinted on.

The Minecraft lesson

My first "side project" was a Minecraft server when I was a teenager. Modding it, configuring plugins, writing scripts to automate things. I did not think of it as programming at the time, but it taught me something important: you finish things you actually use yourself.

I played on that server every day, so I was motivated to keep improving it. The same principle applies now. Landbound exists because I plan outdoor trips and wanted a better tool for it. Routemade exists because I wanted to turn my own routes into something tangible. The projects that survived were the ones solving my own problems. The ones in the archive were solutions looking for a problem.

If you find yourself struggling to finish a side project, it might not be a discipline problem. It might be that you are building something you do not actually need. The best projects are the ones where you are your own first user, and quitting would mean losing something you personally rely on.