27 side projects since 2018. Shipped: 3. That's an 89% failure rate, and it's not unusual. Browse any build-in-public thread on X and you'll see the same story repeated endlessly.
The strange thing is, most of these weren't bad ideas. Several had paying customers lined up. A few had competitors who later raised funding. The ideas weren't the problem. The builder was the problem.
After talking to many builders, the patterns that kill projects become clear, as do the habits that actually lead to shipping.
The Five Ways Projects Die
1. Building Before Asking
The pattern: you have an idea, get excited, immediately open your IDE, and start building. Three weeks later you have a working MVP and zero evidence anyone wants it.
Sometimes you discover the lack of demand explicitly. You finally talk to potential users and get polite indifference. Other times you just lose motivation without understanding why. The "why" is usually that deep down you know you're building for an audience of one.
One hour of research can save three weeks of pointless development.
2. The Scope Monster
"I'll just add one more feature before launching."
This sentence has killed more projects than bad ideas ever could. The MVP that was supposed to take two weeks grows into a three-month odyssey. By the time you're "ready," you're exhausted and the market has moved on.
Scope creep is fear in disguise. Adding features feels productive while conveniently avoiding the scary part: showing your work to real people who might reject it.
The mantra: "If you're not embarrassed by v1, you waited too long."
3. Wrong Idea, Wrong Builder
Some projects are doomed from the start, not because the idea is bad, but because it's wrong for the person building it.
One founder spent four months on a mobile app for real estate agents. The market was real. People paid for similar products. But they'd never sold a house, didn't know any estate agents personally, and had no idea how to reach them. They also found the domain deeply boring.
A mismatch between builder and idea is a slow-motion failure. You can muscle through for a while, but eventually the friction wins.
4. Life Wins
Side projects compete with jobs, families, health, friendships, and Netflix. A demanding week at work becomes a demanding month, and suddenly your project has lost all momentum.
This isn't a character flaw. It's a design problem. Projects that require big blocks of uninterrupted time are fragile. When those blocks inevitably disappear, progress stops.
- Break every task into chunks you can finish in under an hour
- Keep detailed notes so you can resume after gaps without losing context
- Lower activation energy: dev environment always ready, next task always clear
- Aim for 30 minutes daily rather than 8-hour weekend marathons
Consistency beats intensity. Thirty minutes every day adds up to 180+ hours a year.
5. The Shiny Object
Week three of Project A. You're past the honeymoon phase and hitting real challenges. The code is messier than you'd like. User feedback requires changes you didn't anticipate. Progress feels slow.
Then Project B appears in your mind, fully formed and beautiful. It has none of these problems (because you haven't started it yet). The thought creeps in: "Maybe B is actually the better opportunity."
What Finishers Do Differently
I've watched people who consistently ship. They're not smarter or more talented. They've just built different habits.
Finishers commit to two-week experiments, not products. Experiments have defined endpoints, produce learning instead of just features, and turn "failure" into data instead of defeat.
Telling people what you're building creates accountability. When you've posted about your project, abandoning it stings in a way that private failure doesn't.
"This ships in 2 weeks." "Only these three features." "Only tools I already know." Constraints eliminate decision fatigue and force creative solutions.
Done = one person who isn't my friend used it. Done = it's live on the internet. Done = I learned what I needed to learn. A shipped imperfect product beats unshipped perfection.
The Permission to Quit
Not every project deserves to be finished. Sometimes the right call is to stop.
But quit intentionally, not by default. Ask yourself:
- Have I learned what I set out to learn?
- Has new information genuinely changed the picture?
- Am I quitting because it's hard, or because it's wrong?
"This experiment taught me X" is a valid ending. "I forgot about it" is not. The difference is intentionality.
A System for Finishing
Your Project Doesn't Have to Fail
The patterns that kill side projects are predictable. That means they're preventable.
Pick an idea that fits you. Define the smallest version. Set a deadline. Build in public. Push through the middle.
But those 3 taught them more than the other 24 combined. And one of them still generates revenue today.
Your next project can ship. The question is whether you'll do things differently this time.