Every software company has a version of this meeting. Someone raises a concern about the current architecture, tooling, or platform. The room goes quiet. Then a senior leader says it:
“We’ve already invested two years in this.”
Meeting over. The sunk cost wins. Everyone nods, files out, and goes back to building on foundations they know are wrong.
This has always been irrational. The sunk cost fallacy is one of the most well-documented cognitive biases in behavioral economics: past investment should not influence future decisions. Only expected future costs and benefits should matter. But in corporate software, the fallacy has always had a plausible disguise: the future cost of switching genuinely was enormous. Rebuilding a production system took as long as building it the first time. So defending the past investment felt like pragmatism.
AI just took that disguise away.
The Math Changed
The old calculus worked like this: you built your platform over 18 months with a team of 8. Rebuilding on a different stack would take roughly the same. Factor in the learning curve, the lost institutional knowledge, the migration risk. The rational move genuinely was to stay, even if the current platform was suboptimal. The cost of switching exceeded the cost of tolerating.
The new calculus: agentic coding tools can scaffold a working replacement in days. Not a production-ready, battle-tested replacement. But a functional one that proves the concept, validates the architecture, and gives you real data on whether the switch is worth completing.
The cool thing about AI code is it’s ephemeral. As fast as you build it, you can nuke it with little sunk cost or time invested.— @levelsio on X
Levelsio built an Uptimerobot clone with Claude Code in five hours. Then nuked it two days later when someone pointed out a better open-source alternative. No anguish, no committee meeting, no post-mortem about wasted effort. He just deleted it and moved on.
That’s the new economics. The rebuild cost collapsed. And when rebuild costs are low, every sunk cost argument loses its rational foundation.
The Boardroom Problem
The math changed. Corporate culture didn’t.
Decision-makers in enterprise software still reason about platform choices the way they did in 2020. “We’ve already built our mobile app in Flutter” means “we’re staying in Flutter.” “We migrated to microservices last year” means “we’re not discussing the architecture again.” “We chose Salesforce” means Salesforce forever.
The reasoning sounds responsible. It sounds like fiscal discipline. But strip away the framing and it’s the same bias that keeps people watching a bad movie because they paid for the ticket.
Research shows the sunk cost fallacy costs organizations billions annually. 70% of mergers fail, 66% of IT projects end in partial or total failure, and companies like Kodak, Nokia, and Blockbuster continued investing in dying models while competitors captured their markets. The common thread: defending past investment over future opportunity.
The corporate version is especially pernicious because it’s reinforced by incentive structures. The VP who championed the platform choice has their reputation tied to it. The team that built it has their identity tied to it. Admitting the choice was wrong feels like admitting failure. So the organization optimizes for face-saving instead of value.
The market already figured this out. When Anthropic demoed Cowork plugins doing enterprise research and analysis, Thomson Reuters fell 16% and LegalZoom dropped 20%. Investors understood instantly that the moat around “we already built this” was evaporating. The boardroom is the last place to catch up.
Meanwhile, startups with no legacy investment and a Claude Code subscription are building the same functionality in a fraction of the time. They’re not smarter. They’re just not anchored to anything.
”What If Google Kills Flutter?”
This question has haunted Flutter developers for years. Google has a reputation for killing products. The Flutter team had layoffs. Blog posts titled “Is Flutter Dead?” appear every few months like clockwork.
The old answer was: “We’d be screwed. We’ve built everything on it. A rewrite would take years.”
The new answer should be: “We’d rebuild. It would be painful but not catastrophic. The AI-assisted rewrite would take weeks or months, not years.”
That’s not hypothetical optimism. The former Amazon exec Dave Clark described rebuilding three things over a single weekend that previously would have taken months. Y Combinator reported that 25% of its Winter 2025 batch had codebases that were 95% AI-generated. The rebuild velocity is real.
This doesn’t mean you should panic-rewrite your Flutter app. It means the fear of being locked into a platform choice should carry less weight in your decision-making. The exit cost dropped. The lock-in is weaker than it feels.
The 90/90 Rule Still Applies
Here’s where the nuance matters.
Tom Cargill’s famous observation: “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”
AI is devastatingly good at the first 90%. Scaffolding, boilerplate, standard patterns, CRUD, plumbing. The part that used to take months now takes hours. But the last 10%: edge cases, integration with legacy systems, production hardening, performance tuning, compliance requirements, the weird business rules that live in a spreadsheet on someone’s desktop: that’s still hard. AI doesn’t magically solve the parts that were always hard.
A pattern keeps showing up in engineering communities: a team builds something with AI, it works, everyone celebrates. Three months later nobody can explain how the code works. The original prompts are lost, the architecture is a mystery, and making changes breaks things in unexpected ways. The rebuild cost is low. The finish cost isn’t.
So the argument isn’t “you can rebuild anything in a weekend.” The argument is that the threshold for when switching becomes rational just moved dramatically. A rebuild that was a 2-year, 8-person project might now be a 2-month, 2-person project. That changes the calculus even if the last 10% still hurts.
What This Means for Decision-Makers
If you’re a CTO, VP of Engineering, or technical founder, here’s what the collapsing rebuild cost actually changes:
- Platform bets are less permanent. Choosing Flutter, React Native, or SwiftUI is no longer a decade-long commitment. It’s a choice you can revisit in 18 months if the landscape shifts. Evaluate based on current merit, not switching cost.
- “We already built it” is no longer a valid argument. Challenge this every time it appears in a decision. Ask instead: “What would it cost to rebuild today?” The answer might surprise you.
- Proof-of-concept rewrites are cheap. Before committing to another year on the current stack, spend a week building a proof-of-concept on the alternative. You’ll learn more from a working prototype than from six months of committee deliberation.
- The real lock-in is cultural, not technical. The hardest part of switching isn’t the code. It’s the organizational willingness to admit the previous choice was wrong. That’s the actual sunk cost: the reputational investment of the people who made the call.
The Flip Side
Intellectual honesty requires acknowledging the opposite failure mode: the grass-is-greener trap. Just because you can rebuild doesn’t mean you should.
Some platforms are the right choice even when they’re frustrating. Some architectures are suboptimal but functional. The cost of constant rewriting: context loss, team fatigue, the perpetual “v2” that never ships: can exceed the cost of tolerating imperfection.
The sunk cost fallacy says “we stay because we already invested.” The grass-is-greener fallacy says “we switch because something new exists.” Both are irrational. The correct approach is evaluating the future cost of staying vs. the future cost of switching, with no weight given to past investment.
AI shifted that equation. It didn’t eliminate the need for judgment.
AI is moving too fast for sunk cost thinking. What matters now is how fast you can learn and pivot. If your identity is tied to past effort, change will feel like a threat instead of an opportunity.
The Uncomfortable Truth
The sunk cost fallacy persists in corporate software not because decision-makers are stupid. It persists because admitting a past decision was wrong threatens careers, budgets, and org charts. The fallacy is useful. It protects the people who made the call.
AI didn’t just change the rebuild cost. It made the gap between “what we should do” and “what we’re doing to protect past decisions” painfully visible. When rebuilding was genuinely expensive, you could hide behind the economics. When a two-person team can scaffold a replacement in a week, the only thing left defending the status quo is ego.
The sunk cost fallacy isn’t dead because we got smarter. It’s dead because the economics stopped covering for it.
For builders like us, though? It’s never looked so bright. The people who thrive in this environment aren’t the ones clinging to what they built last year. They’re the ones who can let go, pick up new tools, and build the next thing faster than anyone thought possible. The anchor is only heavy if you refuse to cut the chain.
Related Posts
