I Shipped 4 Side Projects Last Year and Finished None of Them

The Pattern

Here’s my 2024 in side projects:

January: A CLI tool for managing dotfiles. Got the core working in a weekend. Never added the sync feature that was the whole point.

April: A habit tracker with a twist (location-based reminders). Built the UI, wired up geolocation, never figured out the notification system. Moved on.

July: A Markdown-based CMS. Actually got pretty far on this one. Then I saw someone launch something similar on Product Hunt and lost all motivation.

October: A browser extension for bookmarking with AI tags. Built the popup, the storage layer, half the tagging logic. Thanksgiving happened. Never touched it again.

Four projects. Hundreds of hours. Nothing shipped.

Why This Keeps Happening

I used to think it was a discipline problem. I’d tell myself to focus, to push through the boring parts, to stop chasing new ideas. That framing never worked because it treated the symptom, not the cause.

The real problem was simpler: I never defined what “done” meant before I started.

Each project began with an exciting idea and an immediate jump to code. The first few days were great. Everything was new, progress was visible, momentum was high. Then I’d hit the messy middle, the part where you’re wiring up boring stuff, handling edge cases, writing the features that aren’t fun but are necessary.

Without a clear picture of what v1 looked like, every hard task felt optional. “Do I really need the sync feature for launch? Maybe I’ll skip it for now.” Skip enough “optional” things and there’s no product left.

The Fix Isn’t Discipline

After four abandoned projects, I tried something different for project number five. Before writing any code, I spent thirty minutes writing down exactly what v1 was.

Not a grand vision. Not a roadmap. Just a list:

• What does it do?
• Who is it for?
• What are the 5-7 features in v1?
• What is explicitly NOT in v1?
• How will I know it’s done?

That last question mattered most. “Done” became concrete: when a user can do X, Y, and Z, it’s done. Not perfect. Not polished. Done.

When I hit the boring middle on project five, something was different. The boring tasks weren’t optional anymore. They were on the list. I could see exactly how many were left. The finish line was visible.

I shipped it.

What Changes When You Define Done

Three things shift when you write down what v1 looks like:

You can say no to yourself. New feature ideas still pop up. But now you have a list, and the new idea isn’t on it. “Cool idea. That’s v2.” Back to the list.

The boring parts feel purposeful. Setting up auth is tedious. But when it’s item 4 of 7 on your v1 list, finishing it feels like progress instead of a chore.

You know when to stop. This is the big one. Without a definition of done, you’re never done. There’s always one more thing to add, one more thing to fix. With a list, you check off the last item and ship.

Thirty Minutes That Save Thirty Hours

I’m not suggesting you write a formal spec for every side project. That would kill the fun. But thirty minutes of “what is this thing, specifically?” before you open your editor will save you from the cycle.

Write it in a note, a README, the back of a napkin. Doesn’t matter. Just answer: what does done look like?

Your future self, the one who’s tired on a Tuesday night and debating whether to keep going, needs something to point at. Give them a list to finish instead of a vision to chase.