Half-finished projects have a gravity. The more time and money you've poured into one, the harder it is to kill, even when everyone quietly knows it's not working. That pull has a name, the sunk-cost fallacy, and it's one of the best-documented biases in decision-making. It's why teams keep shipping things that should have been cancelled months ago.
Key Takeaways
- The sunk-cost fallacy is letting past investment drive decisions it shouldn't (Arkes & Blumer).
- In a classic experiment, 85% continued a doomed project when prior spending was mentioned, versus 10% who'd start it fresh (Arkes & Blumer).
- Rationally, only future costs and benefits should decide whether to continue.
- The cutting question: "would I start this today, knowing nothing was spent yet?"
The Research
The definitive work is Hal Arkes and Catherine Blumer's 1985 paper "The Psychology of Sunk Cost" (Arkes & Blumer). One of their experiments is famous. People were asked about a nearly-finished aircraft project that a competitor had just rendered pointless. When the scenario mentioned the money already invested, 85% chose to finish the doomed project. When the same doomed situation was described without the sunk cost, only 10% chose to invest. The only thing that changed was whether past spending was mentioned, and it flipped the decision almost completely.
That's the trap in one number: the money already spent is gone either way, yet it dominates the choice. Rationally, the past investment should be irrelevant; only the future costs and benefits of continuing versus stopping should matter. Humans do the opposite.
Why It Hits Software So Hard
Software projects are especially prone, because the investment is so visible and the ego is so involved. A team spends six months building a feature, the market shifts or the approach proves flawed, and killing it feels like admitting six months were wasted, so they keep going, spending month seven, eight, nine on something that's still not right. Sunk cost also feeds technical debt: teams keep patching an architecture they should replace because they've "already invested so much" in it.
The Question That Cuts Through
There's a single question that dissolves the bias: "If I were starting fresh today, with nothing already spent, would I choose to begin this project or keep going on this path?" (sunk cost in software). If the honest answer is no, then you're being held by sunk costs, not by the project's real merits. The money and time are gone regardless of what you decide next. The only live question is what the future looks like from here.
| The sunk-cost trap | The rational frame |
|---|---|
| "We've spent so much, we can't stop" | "Spent money is gone either way" |
| Past investment drives the choice | Only future costs/benefits matter |
| "Finishing" honors the effort | "Would I start this today?" |
A Concrete Version
A startup has spent five months on a big feature when a competitor ships something that makes it irrelevant. Everyone senses it's dead, but nobody wants to say "cancel it" after five months, so they push to finish "since we're almost there." Three more months go in. The feature ships, lands with a thud, and now it's eight months instead of five, plus the opportunity cost of everything they didn't build. The honest question in month five, "would we start this today?", answered no. The sunk cost kept it alive for three expensive extra months.
The Honest Counterpoint
Persistence is not always the sunk-cost fallacy, and "kill anything that's struggling" is its own bad rule, plenty of worthwhile projects go through a hard middle before they pay off. The distinction is what's driving the decision. Continuing because the future case is still strong is rational commitment. Continuing because you can't bear to "waste" the past is the fallacy. The test is forward-looking: would I choose this path today on its merits alone, setting aside what's been spent? If yes, push on. If the only argument left is what you've already spent, that's your signal.
What This Means for Teams
Killing a doomed project early is one of the highest-value and hardest calls in engineering leadership, and experienced leaders are better at it because they've felt the sunk-cost pull and learned to name it. It connects to the planning fallacy (projects run longer than you think, deepening the sunk cost) and to resisting big rewrites for the same "we've invested so much" reason. Building a team and culture that can stop, reassess, and cut losses without ego is a real competitive advantage. See available engineers.
Frequently Asked Questions
What is the sunk-cost fallacy?
The tendency to let money, time, or effort already spent drive decisions, when rationally only future costs and benefits should. Arkes and Blumer's research showed prior investment flips choices toward continuing doomed projects.
How strong is the effect?
In a classic experiment, 85% of people chose to finish a doomed project when the prior investment was mentioned, versus only 10% who would start it fresh. The sunk cost nearly reversed the decision.
How do I avoid it?
Ask: "If I were starting today with nothing spent, would I begin this or keep going?" If the honest answer is no, you're being held by sunk costs. Decide on future merits only.
Isn't quitting also a risk?
Yes. Not every struggle is the sunk-cost fallacy, some good projects have a hard middle. The test is whether the forward-looking case is still strong. Continue on future merit, not to honor past spending.
The Bottom Line
"We've already spent so much" is the worst reason to keep going, and the research shows how powerfully it warps decisions, flipping 10% support into 85% just by mentioning what's been invested. The money is gone either way. Ask whether you'd start the project today with nothing spent, and let the forward-looking answer, not the sunk cost, decide.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
