All articles
Lessons 10 min read

Side Project Graveyard: A Post-Mortem on 30 Failed Ideas

23 deleted repos. Most never saw a single user. A post-mortem on a decade of abandoned side projects and what they teach us.

23 deleted repos. Some hadn't been touched in four years. Most never saw a single user. This is a post-mortem on a decade of abandoned side projects, and what they teach us about why we keep repeating the same mistakes.

If you've built software long enough, you have your own graveyard. Half-finished apps. Domains that auto-renewed twice before you noticed. Landing pages that never got a signup form.

Going through it systematically reveals patterns. Here's what the wreckage teaches us.

The Body Count

Before we get to the lessons, the raw numbers:

A typical side project graveyard (2014-2024)
Projects started 31
Reached MVP 12
Got a paying customer 4
Still running today 1
Success rate 3%

That 3% isn't unusual. Most founders have similar numbers if they're honest. The difference between people who succeed and people who don't isn't the ratio. It's learning from the failures.

Cause of Death: The Autopsy

When you categorise abandoned projects by what actually killed them, patterns emerge:

No validation (9 projects)

Built something nobody asked for. Assumed the problem existed. Never talked to potential users before writing code.

Wrong market (6 projects)

Built for people who don't pay for software. Consumer apps. Student tools. Markets that sound big but have no money.

Scope creep death (5 projects)

The MVP grew until it wasn't minimal. "Just one more feature" until the project collapsed under its own weight.

Shiny object syndrome (4 projects)

Abandoned for a newer, more exciting idea. The grass was always greener in the next repo.

Technical over-engineering (4 projects)

Spent so long building the perfect architecture that motivation ran out before launching.

Life happened (3 projects)

Job changes, moves, relationships. External circumstances made the project impossible to continue.

Notice what's missing: competition, funding, and technical ability. Projects don't fail because someone else is better or because founders lack skills. They fail because of choices made.

The Projects That Almost Made It

The most painful entries in the graveyard are the ones that got close. They had users. They had potential. They died anyway.

Project #14: Recipe Scaler

Post-mortem summary

The idea: Automatically scale recipe ingredients based on serving size.

What happened: Built a beautiful app. Got 2,000 users. Couldn't figure out monetisation. Home cooks don't pay for software.

The lesson: B2C is brutal. Same app targeted at catering companies might have worked.

Project #19: Meeting Cost Calculator

Post-mortem summary

The idea: Chrome extension showing real-time cost of meetings based on attendee salaries.

What happened: Went viral on Hacker News. 15,000 installs in a week. Then Google Calendar changed their interface and broke everything. I didn't have the energy to rebuild.

The lesson: Platform dependency is a real risk. Success can be more demanding than failure.

Project #23: Developer Portfolio Generator

Post-mortem summary

The idea: Generate beautiful portfolio sites from GitHub profiles.

What happened: Got 500 paying users at $5/month. But developers kept building their own alternatives. Churn was 15% monthly. Couldn't grow faster than I was losing.

The lesson: Selling to developers is hard. They'll always think they can build it themselves.

Patterns in the Wreckage

Looking across all 31 projects, certain patterns emerge:

The failure patterns
1
Building before talking
Every project that failed early shared this trait. Assuming the problem is understood without validating it. Code comes first, customer conversations never come.
2
Optimising for fun, not revenue
Gravitating toward interesting technical problems, not profitable business problems. The most fun projects to build are the least likely to make money.
3
Underestimating marketing
Build it and they will come. Except they won't. Spending 90% of time on product and 10% on distribution. Those ratios should be reversed.
4
Quitting too early (or too late)
Some projects deserved more persistence. Others should have been killed sooner. Without a framework for knowing which was which.

What the One Success Had Different

The project that survived had specific characteristics the others lacked:

Validated before building

The first version sold before a line of code was written. Pre-orders from real customers with real money.

Boring but profitable

Not a sexy product. Not technically interesting. But businesses pay for it every month without complaining.

Narrow focus

One feature. One audience. One price. No scope creep. No pivots. Just refinement of what already worked.

Built-in distribution

The product lived where customers already were. No cold outreach. No paid ads. Just presence in the right ecosystem.

The Real Cost of Failure

Side projects feel low-stakes. They're not. Here's what 30 failures actually cost:

The hidden costs
Hours spent ~4,000
Domains purchased 47
Hosting/tools over years ~$8,000
Opportunity cost (consulting rate) ~$400,000

That opportunity cost number is uncomfortable to look at. Four thousand hours at $100/hour. Instead of 30 abandoned projects, that time could have gone into one project with extreme focus, with money to fund its growth.

The biggest cost of abandoned projects isn't what you spent. It's what you didn't build because you were spreading yourself too thin.

What to Do Differently

With the benefit of hindsight:

1
Start with money
Don't build anything until someone pays for it. A landing page with a payment form. Pre-orders. Consulting gigs that become products. Revenue first, code second.
2
Pick boring markets
B2B. Small businesses. Professional services. Industries that aren't sexy but have money and don't mind spending it.
3
Ship in weeks, not months
If it takes longer than two weeks to get something in front of users, the scope is too big. Cut until it fits.
4
Use a decision framework
Score ideas systematically. Compare them objectively. Don't let excitement override analysis. Have criteria for what makes an idea worth pursuing.
5
Set kill criteria upfront
Before starting, decide what would make you quit. No signups after X weeks. No revenue after Y months. Then honour those criteria.

Cleaning Out the Graveyard

Deleting old repos is cathartic. Each one represents not just failed code but failed assumptions about what should be built.

The graveyard teaches that ideas are cheap. Execution matters, but only on the right idea. And finding the right idea requires being honest about why the wrong ones failed.

The exercise worth doing

Go through your own graveyard. List every abandoned project. Categorise the cause of death. Look for patterns. The failures you've already experienced are the best teachers you'll ever have.

Your next project doesn't have to end up in the graveyard. But it will, unless you learn from the ones that already did.

Put this into practice

IdeaBadger helps you capture and score your ideas using the Joy-Ease-Opportunity framework. Stop overthinking, start building.

Try it free