Why Your Side Project Never Gets Finished

Count the number of projects you’ve started. Count the number you’ve finished. The ratio is probably embarrassing. Mine was.

I used to think finishing was just about willpower. Push through. Try harder. That’s wrong. Finishing is about understanding why projects die and designing around those failure modes.

The scope expansion problem

Projects start small and grow. You add features while building. “It would be cool if it also did this.” “People will expect this other thing.” “I should add this before launching.”

Every addition pushes the finish line further away. A project that should take a weekend becomes a month becomes “someday.” Eventually, the distance to completion exceeds your motivation reserves.

The solution isn’t more discipline. It’s recognizing that scope expansion is the enemy and designing constraints to prevent it. What’s the absolute minimum version? Build only that. Add features after launch, if at all.

The shiny object problem

New ideas are exciting. Existing projects are not. The initial burst of energy fades. The work becomes repetitive. A new idea appears, offering that initial energy again.

Chasing the new idea feels productive. You’re making progress! On something different. The old project sits neglected, eventually forgotten.

Some people are natural finishers and don’t relate to this. Most of us need strategies. Write new ideas down but don’t start them. Create artificial deadlines. Share progress publicly so stopping is embarrassing.

The perfection trap

“It’s not ready.” Maybe the code needs cleaning. Maybe the design needs polish. Maybe you need to add error handling for edge cases that might never happen.

Perfection is an excuse. It sounds responsible — “I want to deliver quality.” But it’s actually fear disguised as conscientiousness. Fear of judgment. Fear of failure. Fear of discovering the idea was bad.

Shipping imperfect work is terrifying and necessary. Nobody’s first version was good. You can’t iterate toward good without shipping something mediocre first.

The technical quagmire

Some projects die in infrastructure. Setting up authentication. Configuring deployment. Dealing with some bug that doesn’t affect functionality but bothers you anyway.

You spend weekends on things that aren’t the actual product. Eventually, you’ve lost the thread. What were you building again? The vision faded while you fought with configuration files.

Modern tools exist specifically to avoid this. Use them. Frameworks that handle auth for you. Deployment platforms that just work. AI tools that handle the boring parts. Your job is to ship, not to prove you can configure everything from scratch.

The isolation problem

Working alone means no accountability. Nobody knows you stopped. Nobody is waiting for a deliverable. The project exists only in your head, and that’s where it dies — silently, with no witnesses.

Tell people what you’re building. Show them early progress. Make stopping embarrassing. Public commitment creates pressure that works in your favor.

This doesn’t mean getting co-founders or teammates. Just means not building in secret. A tweet, a post, a message to a friend. “I’m building X.” Now someone knows.

“The difference between shipped and abandoned isn’t skill. It’s finishing systems.”

What finishers do differently

They define done before starting. Not vaguely. Specifically. “The project is done when it does X, Y, and Z.” That’s the list. Nothing else makes the list later.

They timebox ruthlessly. “I have two weeks. Whatever I have at the end ships.” The constraint forces prioritization. You can’t add scope when the deadline is fixed.

They ship early. The first public version is embarrassing. They ship it anyway. Because an embarrassing thing that exists beats a perfect thing that doesn’t.

They have finish lines, not horizons. A horizon recedes as you approach it. A finish line doesn’t. Know your finish line.

The question

Look at your current project. Can you define exactly what “done” means? Can you describe the specific, narrow version that ships this month?

If the answer is vague, that’s the problem. Not time. Not skill. The vagueness is where projects go to die.