I spent six months building a SaaS product that nobody wanted.

The code was beautiful. The architecture was solid. I’d invested countless nights and weekends. I’d turned down freelance work to focus on it. I’d told everyone it was going to be “the one.”

And the market response was… crickets.

Any rational person would’ve shut it down and moved on.

Instead, I spent another six months trying to “make it work.” I pivoted. I added features. I changed the pricing. I rewrote the landing page seventeen times.

Why? Because I’d already invested so much. Surely all that time couldn’t be wasted, right?

Wrong. I was trapped by the sunk cost fallacy, and it cost me a year of my life.

What is the Sunk Cost Fallacy?

The sunk cost fallacy is the tendency to continue investing in something (time, money, effort) simply because you’ve already invested in it—even when continuing makes no rational sense.

The logic error: “I’ve already spent $10,000 and 500 hours on this project. If I quit now, all that investment is wasted. So I need to keep going.”

The truth: That $10,000 and 500 hours are already gone regardless of what you do next. They’re sunk. The only question that matters is: “Given what I know now, is this the best use of my next dollar and next hour?”

The fallacy makes us throw good money after bad, stay in failing relationships, finish terrible books, and watch boring movies to the end—all because we’ve “already invested” in them.

The Psychology Behind It

Why do smart, rational people fall for this?

Loss Aversion on Steroids

Humans hate losing more than we enjoy winning. This is loss aversion, and it’s deeply wired into us.

When you abandon a project, you’re not just losing future potential—you’re acknowledging that your past investment was a loss. That stings.

Your brain screams: “If I quit, I’m admitting I wasted six months. But if I keep going, maybe I can still salvage it and prove it wasn’t a mistake.”

The trap: You’re not making a forward-looking decision. You’re trying to justify a past decision.

The Commitment Consistency Principle

We have a deep need to be consistent with our past choices. Once we’ve publicly committed to something, changing course feels like admitting we were wrong.

I told my family I was building a startup. I posted on Twitter about my progress. I turned down a job offer because I was “building something.”

Shutting it down meant admitting to everyone (and myself) that I’d been wrong. So I kept going, not because the project made sense, but because I’d already said I would.

The Completion Bias

Humans crave closure. Unfinished things create psychological tension. We want to see things through to the end.

“I’ve already built 90% of the features. Just a few more weeks and it’ll be done!”

But “done” doesn’t mean “successful.” A completed product that nobody wants is still a failure.

Escalation of Commitment

Here’s the really insidious part: the more you invest, the harder it becomes to quit.

It’s not just about the initial investment. It’s that each additional investment makes the total investment larger, which makes quitting feel even more costly.

This creates a spiral:

  • Invest $1,000 → Hard to quit
  • Invest another $1,000 → Even harder to quit
  • Invest another $1,000 → Nearly impossible to quit

You end up in a death spiral, pouring resources into something that should’ve been killed long ago.

Real-World Examples from Tech and Startups

Let me share some painful (but educational) examples.

Example 1: The Rewrite That Never Shipped

The scenario:

A startup with a working (but messy) Ruby on Rails app decides to rewrite it in Go “to scale better.”

The timeline:

  • Month 1: “This will take 3 months max. The architecture will be so much cleaner.”
  • Month 3: “We’re 60% done. Just need to finish the payment system and admin panel.”
  • Month 6: “We’ve come so far. Can’t stop now. Just a few more weeks.”
  • Month 9: “The old codebase is falling apart. We HAVE to finish the rewrite.”
  • Month 12: Still rewriting. Meanwhile, competitors have shipped 10 features. Users are churning.

The sunk cost trap:

They kept investing in the rewrite because they’d already invested six months. The right decision at month 3 was probably to stop and return to the working app. But admitting that would mean those three months were “wasted.”

Reality: The three months were already wasted whether they stopped or continued. Continuing wasted another nine months.

I’ve seen this exact pattern at three different companies. The rewrite almost never ships, or ships so late that it doesn’t matter anymore.

Example 2: The Feature Nobody Asked For

My personal story:

I built a feature for my EdTech platform: an elaborate gamification system with points, badges, leaderboards, and achievement trees.

The investment:

  • 2 months of development
  • Complex database schema
  • Real-time leaderboard calculations
  • Beautiful UI animations

User response: “This is confusing. Can you just show me my progress percentage?”

The rational response: Remove it and build what users actually want.

What I actually did: “But I spent two months on this! Users just don’t understand it yet. I need to add a tutorial, make it more prominent, add more badge types…”

Spent another month trying to make users care about a feature they didn’t want.

The lesson:

The two months were sunk. I couldn’t get them back by forcing users to care. I should’ve cut my losses and moved on.

Example 3: The Dying Tech Stack

The pattern:

Company built their product on a now-obscure framework (let’s say Meteor.js or Backbone.js—no offense to these, but they’re not mainstream anymore).

The problem:

  • Hard to hire developers who know it
  • Limited library ecosystem
  • Framework is barely maintained
  • Every new feature takes 3x longer than it should

The sunk cost reasoning: “We’ve built so much on this stack. Switching would mean rewriting everything. We can’t throw away five years of work.”

What actually happens:

They limp along for years, spending 10x more on development than they would if they’d switched. The “cost” of switching grows larger in their minds every month, even though the actual cost of staying is enormous.

The math:

  • Cost to switch: $200,000 and 6 months
  • Cost to stay: $100,000/year in inefficiency forever

After two years, staying has cost more. But they still can’t pull the trigger because “we’ve come too far.”

Example 4: The Conference Talk Nobody Wants

The scenario:

You submitted a talk proposal to a conference: “Building Microservices with Rust.”

It got accepted! You’re excited! You start preparing.

But then you realize:

  • You don’t actually have a compelling story to tell
  • Your Rust experience is limited
  • The topic has been done to death
  • You’re not enjoying the preparation

The sunk cost trap:

“I’ve already spent 20 hours preparing. I’ve told people I’m speaking. I can’t back out now.”

So you spend another 40 hours preparing a mediocre talk, deliver it poorly, and waste the audience’s time.

The alternative:

Withdraw from the conference, be honest about it, and spend those 40 hours on something valuable.

Yes, you “wasted” 20 hours. But better to waste 20 than 60.

How to Recognize the Sunk Cost Fallacy in Real-Time

Here are the warning signs you’re falling for it:

Red Flag #1: “I’ve Already Invested Too Much to Quit”

If this phrase crosses your mind, you’re probably in a sunk cost trap.

The moment you’re justifying continuing based on past investment rather than future value, you’ve stopped thinking rationally.

Better question: “If I were starting from scratch today, knowing what I know now, would I begin this project?”

If the answer is no, you should probably quit.

Red Flag #2: “Just a Little More…”

“Just one more week.” “Just one more feature.” “Just one more pivot.” “Just a little more money.”

This is the death spiral. Each “just a little more” is justified by all the previous investments.

Reality check: Define specific, measurable success criteria BEFORE investing more. “If X doesn’t happen by Y date, I stop.”

No moving goalposts.

Red Flag #3: “I Can’t Waste All That Work”

The work is already wasted or not—continuing won’t change that.

You can’t un-waste past effort by adding more effort. That’s like saying “I ate a bad meal, so I should keep eating it to make it worth the money.”

Red Flag #4: You’re Defending It To Yourself

If you’re having internal conversations justifying why you should continue, that’s a warning sign.

Genuinely good decisions rarely need elaborate internal justification. You don’t have to convince yourself to work on something that’s clearly working.

Red Flag #5: Everyone Else Sees the Problem

Friends: “Why are you still working on this?” Mentors: “Have you considered moving on?” Colleagues: “Are you sure this is worth your time?”

If multiple trusted people are questioning your continued investment, listen.

They’re not emotionally attached to your sunk costs. You are.

The Rational Decision-Making Framework

Here’s how to actually make decisions without falling for sunk costs:

Step 1: Ignore What You’ve Already Spent

Imagine someone else is facing this decision with no prior investment.

Example:

Sunk cost version: “I’ve spent $50,000 building this app. Should I spend another $50,000 to finish it?”

Rational version: “There’s an app that’s 70% built. Should I invest $50,000 to finish it?”

If you wouldn’t advise someone else to make that investment from scratch, you shouldn’t make it either.

Step 2: Define Success Criteria Upfront

Before investing more, write down EXACTLY what success looks like and when you’ll evaluate.

Bad criteria:

  • “Keep working until it’s successful”
  • “Give it more time”
  • “See how it goes”

Good criteria:

  • “If we don’t get 100 beta signups by March 1st, we stop”
  • “If engagement doesn’t improve by 20% after this redesign, we pivot”
  • “If we can’t close a paying customer by Q2, we shut down”

Make them:

  • Specific (numbers, not feelings)
  • Time-bound (actual dates)
  • Binary (yes/no, not subjective)

Step 3: Separate Evaluation from Ego

Your decision to continue or stop is not a referendum on your intelligence or worth.

  • Quitting doesn’t mean you’re a quitter
  • Stopping doesn’t mean you’re weak
  • Changing course doesn’t mean you’re indecisive

It means you’re updating your beliefs based on new information. That’s rationality, not failure.

Reframe:

  • ❌ “If I stop, I’m admitting I wasted six months”
  • ✅ “I learned valuable lessons in six months. Now I’m applying those lessons by making a smart choice about the next six months”

Step 4: Calculate Opportunity Cost

Every hour and dollar you spend on Project A is an hour and dollar you’re NOT spending on Project B.

Framework:

List your options:

Option 1: Continue current project

  • Cost: $50k + 6 months
  • Expected value: 10% chance of success = $500k
  • Expected ROI: 0.1 × $500k = $50k

Option 2: Start new project based on validated idea

  • Cost: $30k + 4 months
  • Expected value: 40% chance of success = $300k
  • Expected ROI: 0.4 × $300k = $120k

Option 3: Take that job offer

  • Cost: 0 additional investment
  • Expected value: $180k guaranteed salary
  • Expected ROI: $180k

When you calculate it out, the sunk cost becomes irrelevant. Only forward-looking value matters.

Step 5: Use Pre-Commitment Devices

Make the decision to quit BEFORE you’re emotionally invested.

Examples:

Startup: “If we don’t reach $10k MRR by month 18, we shut down. No exceptions. No pivots. We shut down.”

Write this down. Share it publicly. Make it your rule.

Side project: “I’ll work on this for 3 months. If I’m not enjoying it or seeing traction by then, I stop. No ‘just one more month.’”

Relationship: “If we’re still having the same fight six months from now, we go to couples therapy or break up.”

The key: decide BEFORE you’re in too deep.

Step 6: Run a “Regret Minimization” Test

Jeff Bezos calls this the “regret minimization framework.”

Imagine yourself at 80 years old, looking back at this decision.

Ask: “Will I regret quitting this project?” “Will I regret spending another year on it?”

Usually, you’ll regret wasting time more than you’ll regret abandoning sunk costs.

Advanced Technique: The “Zero Base” Method

Here’s a powerful exercise from zero-based budgeting adapted for decisions:

The thought experiment:

“All my current projects have been cancelled. My slate is completely clean. I have [X resources] to allocate from scratch.”

Now, looking at all possible projects (including your current ones), where would you allocate resources?

If you wouldn’t choose to fund your current project when compared against all other options, you shouldn’t continue it.

Example:

You’re running three side projects:

Project A: SaaS tool for designers (your current focus, 8 months invested)

  • Progress: 10 users, $200 MRR
  • Feels: Struggling, not enjoying it

Project B: Technical blog (wrote 3 posts)

  • Progress: 5,000 monthly readers, getting job offers
  • Feels: Energizing, people asking for more

Project C: Open source library you maintain

  • Progress: 500 GitHub stars, used in production
  • Feels: Rewarding, people contributing

Zero-base question: If you had 20 hours/week to allocate, how would you split it?

Rational allocation: 0% to Project A, 60% to Project B, 40% to Project C

Actual allocation (sunk cost version): 80% to Project A, 10% to Project B, 10% to Project C

The only reason you’re spending 80% on Project A is because you’ve already invested eight months. That’s the sunk cost fallacy.

When Persistence is Actually Rational

Important caveat: Not all “keep going despite challenges” is sunk cost fallacy.

Sometimes persistence is the right choice.

Persistence is rational when:

1. You Have Real Evidence of Progress

Sunk cost version: “We’ve been at this for 18 months. We can’t quit.”

Rational persistence: “Our MRR grew 15% last month, 20% this month. We’re seeing actual traction. Let’s keep going.”

2. The Fundamentals Have Changed

Sunk cost version: “I’ve spent so long learning Java, I can’t learn a new language.”

Rational persistence: “Java is still highly valuable in enterprise. My skills are in demand. Keep deepening expertise.”

3. You’re in the Expected “Messy Middle”

Every project has a phase where it sucks. That doesn’t mean you should quit.

The difference:

Sunk cost: It’s been hard from day one, no signs of improvement, you hate it, but you’ve invested so much.

Rational persistence: You knew it would be hard, you’re seeing progress, you still believe in it, the hard part is temporary.

4. You Have Clear Reason to Believe Next Iteration Will Work

Sunk cost version: “Maybe if I try just one more thing…”

Rational persistence: “I interviewed 20 customers. They all said they’d pay for feature X. I’m adding feature X. This is based on data, not hope.”

5. You’re Learning Valuable Skills

Even if the project fails, if you’re gaining valuable skills or relationships, continuing might make sense.

But be honest: Are you actually learning, or are you just familiar with your specific (dying) project?

How to Actually Quit

Okay, you’ve recognized the sunk cost fallacy. You know you should quit. But how?

Step 1: Acknowledge the Sunk Cost

“I invested six months and $30,000 in this project. That time and money are gone regardless of what I do next.”

Say it out loud. Write it down. Accept it.

Step 2: Grieve the Loss

It’s okay to be sad about wasted effort. Feel it, then move on.

Set a timer for 24 hours. Wallow, vent to friends, write an angry journal entry.

Then, when the timer goes off, you’re done. No more grieving. Only forward.

Step 3: Extract the Learnings

Make a list:

  • What did I learn?
  • What mistakes did I make?
  • What would I do differently?
  • What skills did I gain?

This transforms “wasted time” into “educational investment.”

I spent a year on a failed SaaS product. But I learned:

  • How to validate ideas before building
  • How to talk to customers
  • How to recognize sunk cost fallacy
  • How to shut things down gracefully

Those lessons have saved me years on subsequent projects.

Step 4: Announce It

Tell the people you told about the project.

“I’m shutting down [project]. It didn’t work out. Here’s what I learned.”

This:

  • Removes the “consistency” pressure
  • Makes it real
  • Prevents backsliding
  • Models healthy decision-making

Step 5: Delete / Archive / Hand Off

Make it hard to restart.

  • Archive the GitHub repo
  • Delete the production environment
  • Cancel the domain registration
  • Give away the assets

If you leave everything “ready to restart,” you’ll be tempted to fall back into it during moments of doubt.

Step 6: Immediately Start Something New

The best way to stop thinking about sunk costs is to focus on new opportunities.

Within 48 hours of shutting down a project, start exploring what’s next.

This prevents the “I have nothing now” feeling that makes you cling to dead projects.

The Shutdown Checklist

I keep this checklist for when I need to kill a project:

□ Have I honestly evaluated using the "zero base" method?
□ Have I separated my ego from the decision?
□ Have I acknowledged the sunk costs?
□ Have I extracted all learnings?
□ Have I told relevant people?
□ Have I made a public announcement (if appropriate)?
□ Have I archived/deleted to prevent backsliding?
□ Have I identified my next move?
□ Have I set a "no looking back" date?

Once all boxes are checked, I move on. No regrets.

Famous Examples of Sunk Cost Fallacy at Scale

Sometimes it helps to know even massive organizations fall for this:

The Concorde Fallacy

The supersonic Concorde jet program was so associated with sunk cost fallacy that economists literally called it the “Concorde Fallacy.”

The British and French governments kept funding it despite:

  • Clear evidence it would never be profitable
  • Massive cost overruns
  • Limited market demand
  • Environmental concerns

Why? “We’ve already invested so much.”

Final cost: Over $20 billion (adjusted for inflation). Commercial failure.

Microsoft Zune

Microsoft spent years and hundreds of millions trying to compete with the iPod.

Despite clear market dominance by Apple, they kept investing in Zune because they’d already committed.

Launched 2006. Discontinued 2011. Total waste.

The sunk cost? Pride and initial investment. The actual cost? Hundreds of millions that could’ve been invested in Xbox or cloud computing.

Yahoo had multiple chances to pivot away from their portal strategy when it was clear Google was winning search.

But they’d built their entire identity around being a portal. “We’ve been doing this for a decade. We can’t just abandon it.”

By the time they finally tried to pivot, it was too late.

Final Thoughts: The Freedom of Quitting

Here’s what I wish I’d known earlier:

Quitting is not failure. Quitting is data collection.

Every time you shut down a project that isn’t working, you’re:

  • Freeing up resources for better opportunities
  • Practicing rational decision-making
  • Learning what doesn’t work
  • Building the skill of letting go

I’ve shut down:

  • 3 SaaS products
  • 2 mobile apps
  • 1 online course
  • 5+ side projects
  • Multiple blog ideas that weren’t resonating

Each time got easier. Each time I got better at recognizing sunk costs early.

And here’s the beautiful part: The time you spend on failed projects isn’t wasted if you learn to fail faster.

My first failed project: 12 months to shut down My second: 6 months My third: 3 months My most recent: 2 weeks

I’m getting better at recognizing when something isn’t working and cutting my losses.

The goal isn’t to never fail. It’s to fail cheaply and quickly, learn, and move on.

Your sunk costs are not a reason to continue. They’re a reminder to choose wisely what you invest in next.

Now, if you’ll excuse me, I have a project to kill. I’ve been putting it off for three weeks, but writing this post gave me the clarity I needed.

Time to practice what I preach.

What projects are you holding onto because of sunk costs? What would happen if you let them go? I’d love to hear your stories.