I have a graveyard of side projects. So does almost every engineer I know. We start with a burst of excitement, build the fun 60%, and then quietly abandon it when the interesting part is done and the boring part begins. For years I assumed this was a discipline problem. It's not — it's mostly a design problem, and once I understood why side projects die, I started finishing them.
The story
My pattern was painfully consistent. I'd get excited about an idea, spend a weekend building the core — the part that was novel and fun — and feel great. Then reality would arrive: the auth, the deployment, the edge cases, the unglamorous 40% that turns a demo into a thing people can actually use. The excitement faded exactly when the boring work started, and the project joined the graveyard. Repeat, for years.
The one that finally broke the pattern was almost embarrassingly small. Instead of a grand idea, I picked something I could genuinely finish in a weekend — tiny scope, one feature, nothing clever. And I told a few people I'd ship it by Sunday. That public commitment plus the tiny scope did something none of my ambitious projects ever had: it got finished. It wasn't impressive. But it was done and live, and that completed loop taught me more than all my abandoned half-projects combined.
The lesson wasn't "try harder." It was that my projects were designed to fail — too big, no deadline, no users, and a plan that put all the fun first and all the misery last.
Why side projects die
The scope is too big. Grand ideas have a long, unglamorous middle that excitement can't sustain. Most side projects are simply too large to finish on hobby energy.
There's no deadline. "Someday" is where projects go to die. Without a date, the boring 40% gets postponed forever.
There are no users. Building for nobody means nothing pulls you through the hard parts. A single real user waiting for it changes everything.
Perfectionism. Endlessly polishing the fun parts instead of finishing the whole thing. A half-perfect project is still an unfinished one.
Fun-first sequencing. We build the exciting core first, so motivation runs out exactly when the tedious-but-necessary work begins.
A finished ugly project beats a beautiful abandoned one every time. "Shipped" is a skill, and you build it on small things first.
Key lessons
Smaller is the cheat code. A project you can finish in a weekend builds the "I ship things" muscle. Ambition can come after you've proven you finish.
Deadlines create finishing. A real date — ideally one you've told people about — forces the unglamorous work to happen.
One real user changes everything. Building for someone who's waiting pulls you through the boring parts.
Done beats perfect. Ship it ugly and improve later. An unfinished masterpiece helps no one.
Action steps
- Pick something you can finish in a weekend. Cut the idea down until it's almost too small. Finish first, scale later.
- Set a public deadline. Tell people you'll ship by a date. The mild social pressure is remarkably effective.
- Find one user. Even a friend who genuinely wants it. Build for them, not for "everyone someday."
- Do the boring part early. Wire up deployment and the unglamorous basics while motivation is high, not last.
- Ship it ugly, then iterate. Get it live first. Polishing an unshipped thing is just hiding.
Final thoughts
My side-project graveyard wasn't evidence that I lacked discipline. It was evidence that I kept designing projects that couldn't be finished — too big, no deadline, no users, all fun-first. Once I fixed the design instead of blaming my willpower, I started shipping.
If you've got your own graveyard, you don't need more discipline. You need a smaller project, a real deadline, and one person waiting for it. Finish one tiny thing, feel what "done and live" is like, and you'll find the next one is far easier to carry across the line.