The Sunk Cost Architecture
Why Teams Can’t Stop Investing in What Isn’t Working
The Migration That Cannot Be Stopped
An engineering organization is eighteen months into a microservices migration. The original timeline was twelve months. The original budget was $1.2 million. They have spent $1.8 million, and the platform team estimates eighteen more months to completion. The monolith still handles 70% of production traffic. The new services handle 30% and have twice the incident rate. Feature velocity has dropped by 40% since the migration began because engineers are maintaining two systems simultaneously.
In any rational accounting, this is a failing investment. The migration has exceeded its budget by 50%, will take at least three times the original timeline, and has produced measurable degradation in both reliability and delivery speed. If this were a financial investment, the fund manager would cut losses. If this were a construction project, the contractor would renegotiate or cancel the contract.
But when the VP of Engineering asks whether to stop the migration and stabilize the monolith, the room goes quiet. The CTO says, “We’ve already invested $1.8 million. We can’t walk away from that.” The director who proposed the migration says, “We’re 60% done. Stopping now would waste everything we’ve built.” The platform team says, “If we stop, the partially migrated system will be even harder to maintain than the original.”
Every argument references what has already been spent. None evaluates whether the future costs are justified by the future benefits. The $1.8 million is gone regardless of the next decision. The only question that matters is: will the next $1.8 million produce enough value to justify spending it? Nobody in the room is asking that question.
Every argument for continuing references what has already been spent. None evaluates whether the future costs are justified by the future benefits. This is the sunk cost fallacy operating at an organizational scale.
This is the sixth and final essay in the Economics of Software Architecture series. Essay 1 quantified the architecture tax. Essay 2 measured the opportunity cost. Essay 3 identified the principal-agent dynamics that generate bad decisions. Essay 4 showed how technical debt compounds. Essay 5 revealed why collective cloud over-consumption persists. This essay answers the question that every preceding essay left open: if the costs are so visible and the losses so large, why can’t organizations change course?
The answer is the sunk cost fallacy: the human tendency to continue an endeavor because of what has already been invested, regardless of whether the future returns justify the future costs. In economics, sunk costs are costs that have already been incurred and cannot be recovered. Rational decision-making ignores sunk costs and evaluates choices based solely on future costs and future benefits. But humans are not rational decision-makers. And organizations are composed of humans.
The Psychology of Architectural Inertia
In 1985, Hal Arkes and Catherine Blumer published foundational research on sunk cost effects, demonstrating that people systematically factor irrecoverable past investments into future decisions, even when they know, in the abstract, that they should not. Daniel Kahneman, who won the 2002 Nobel Prize in Economics, connected the bias to loss aversion: the psychological pain of losing is roughly twice as powerful as the pleasure of an equivalent gain. Richard Thaler, who won the 2017 Nobel Prize, formalized the sunk cost fallacy as a core feature of how humans actually make economic decisions, rather than how textbooks say they should.
In software architecture, five psychological mechanisms make the sunk cost trap deeper than in most other domains.
Loss Aversion
Canceling a $1.8 million migration does not feel like saving $1.8 million in future costs. It feels like losing $1.8 million in a past investment. The psychological accounting is asymmetric. The money already spent registers as a loss that must be recovered, not as a cost that is gone regardless of the next decision. And the “loss” is not just financial. It includes the reputation of the people who proposed the migration, the credibility of the team that has been building it, and the narrative that the organization told itself about why the migration was necessary.
Identity Fusion
When an architect spends a year designing and championing a system, their professional identity fuses with the architecture. Abandoning the architecture feels like abandoning part of themselves. Meta’s metaverse investment illustrates this at corporate scale: the company renamed itself around the architectural bet, investing an estimated $70-77 billion before pivoting. The stock rose 4% on news of the pullback. The market was relieved. The company had been trapped by its own identity. In engineering organizations, the director who proposed the microservices migration cannot advocate for canceling it without undermining their own standing, their team’s work, and the professional narrative they have built around the decision.
Escalation of Commitment
Psychologist Barry Staw’s research showed that decision-makers who are personally responsible for an initial investment are more likely to increase their commitment when the investment goes wrong, not less. The logic is internally consistent: if I invest more, the project might succeed, which validates my original decision. If I stop, the project will certainly fail, which confirms that my original decision was wrong. In software, this manifests as the perpetual “one more sprint” conversation. The migration needs just one more sprint. The rewrite is almost done. The platform is about to reach feature parity. Each additional sprint is a small bet that the cumulative investment will eventually pay off. The small bets add up to enormous expenditures that no one approved individually.
Status Quo Bias
Even when the current path is painful, it is a known quantity. The alternative (stopping the migration, reverting to the monolith, starting a different approach) is uncertain. Status quo bias causes decision-makers to weight the certain pain of the current path lower than the uncertain risk of an alternative, even when the expected value of switching is higher. In architecture, this is compounded by the partially-migrated state: the system is now a hybrid of old and new, and neither reverting nor completing feels safe. The half-finished migration has created a condition worse than either the original or the target, and the sunk cost of reaching that condition makes both forward and backward movement feel like a waste.
Organizational Momentum
Once an architectural direction has organizational backing (budget approval, team allocation, roadmap positioning, executive sponsor), reversing course requires overcoming social gravity. People who approved the decision must admit they were wrong. Teams that were hired for the migration must be reassigned. Conference talks submitted on the migration must be withdrawn. The organizational infrastructure built around the architectural decision creates its own gravitational pull. Stopping is not just a technical decision. It is a social and political one, and in many organizations, the social costs of reversing course exceed the financial costs of continuing.
Canceling a $1.8 million migration does not feel like saving $1.8 million in future costs. It feels like losing $1.8 million in a past investment. Psychological accounting is asymmetric, and this asymmetry traps organizations in failing architectures.
The Two-System Penalty
The cruelest aspect of architectural sunk cost is the two-system penalty. When an organization is mid-migration, it maintains both the old and new systems. The architecture tax from Essay 1 doubles. The opportunity cost of Essay 2 increases because engineers are maintaining two codebases instead of building features on a single codebase. The technical debt from Essay 4 compounds on both systems. The cloud spend from Essay 5 covers infrastructure for both. The partially migrated state is the most expensive state an organization can occupy. And the sunk cost fallacy is the mechanism that keeps them there.
This connects to the Nash Equilibrium analysis from the game theory work in this series. A system with forty-seven microservices, where every team knows the architecture is too complex, but no single team can simplify their piece without breaking contracts with the other forty-six. The coordination lock (no team can move unilaterally) and the investment lock (the organization’s sunk cost makes abandonment intolerable) reinforce each other, creating a trap that is stronger than either mechanism alone.
Fred Brooks observed that the second system is always over-engineered: the team builds in every lesson from the first system, plus every feature they wished they had. In the two-system penalty, the organization pays the operational cost of the over-engineered second system while still paying the full maintenance cost of the first. The migration that was supposed to reduce costs has increased them. The Standish Group’s data is relevant here: only 16-31% of IT projects are completed on time, on budget, and with full scope. Fifty percent are challenged. Nineteen to thirty-one percent are canceled outright. The base rate for a large architectural migration to succeed as planned is remarkably low, and the sunk cost fallacy is what keeps challenged projects alive long past their expiration date.
Telling an organization to “just stop the migration” is the sunk cost equivalent of telling a prisoner’s dilemma player to “just cooperate.” It ignores the incentive structure. The CTO who approved the migration cannot cancel it without admitting a million-dollar mistake. The director who championed it cannot reverse course without damaging their career (a callback to Essay 3’s principal-agent analysis: the agent’s career incentive prevents the organizationally correct decision). The engineers who built the new services cannot see their work discarded without feeling their effort was wasted. The game must be changed, not the players.
Organizations That Broke Free
The sunk cost trap can be escaped. But escape requires evaluating the future without reference to the past. Three organizations demonstrate what that looks like.
37signals: Evaluating the Future, Not the Past
37signals had invested years in AWS infrastructure. Their operations were built around it. Their team was trained on it. Their deployment pipeline assumed it. Leaving the cloud meant writing off that accumulated investment in skills, tooling, and process. The sunk cost was real and substantial. But David Heinemeier Hansson and the team evaluated the decision based on a single question: what will the next five years cost on AWS versus on owned hardware? The past investment in AWS was irrelevant to that calculation. The result: $2 million per year in savings, projected $10 million over five years, with no increase in operational headcount. The courage was not in the math. The math was straightforward. The courage was in ignoring the past.
Segment: Acknowledging the Architecture Was Wrong
Segment had invested years in building and maintaining 140 microservices. Each service had its own database, deployment pipeline and monitoring. Three engineers maintained the infrastructure full-time. The sunk cost of building those 140 services was enormous. Consolidating meant acknowledging that the architectural direction had been wrong. It meant abandoning services that teams had spent months building. But Segment evaluated the decision in terms of future costs: the cost of continuing (three engineers on permanent maintenance, $450K-$600K per year in direct costs, and millions in opportunity cost from unshipped features) versus the cost of consolidating (temporary disruption, the emotional cost of admitting the architecture was wrong). They consolidated. Engineering velocity returned. The sunk cost was gone regardless. The future cost was not.
Amazon Prime Video: Replacing the Textbook
Amazon’s Prime Video team built a distributed architecture using AWS Step Functions and serverless components. The architecture was textbook cloud-native. It was also financially ruinous, hitting a scaling wall at 5% of expected load. The sunk cost of the distributed architecture included design and implementation time, as well as the organizational credibility invested in “cloud-native best practices.” The team consolidated to a single-process architecture. Cost dropped 90%. Capacity increased to handle thousands of streams. The architecture that was “correct” by industry standards was replaced by the architecture that was correct by financial standards.
The Counter-Examples
For every 37signals and Segment, there are organizations that cannot escape the trap. The enterprise has been four years into a microservices migration with no end in sight and no measurable improvement in delivery speed. The startup that cannot pivot because its entire infrastructure was built for a market hypothesis that proved wrong, and the founders cannot bear to abandon the technical investment. The 42% of microservices adopters who are now consolidating (CNCF 2025) represent the organizations that have overcome the bias. Many in the remaining 58% are still trapped. Not because the math supports continuing. Because the psychology demands it.
For every organization that escapes the sunk cost trap, there are many that stay. Not because the math supports it. Because the psychology demands it. The $1.8 million already spent has no bearing on whether the next $1.8 million will produce value. But it feels like it does.
Kill Criteria: Mechanism Design for Architectural Exit
If sunk cost bias is a predictable cognitive error, organizations can design mechanisms that counteract it. The same principle that applied in Essays 3, 4, and 5 applies here: do not rely on better judgment. Design better structures.
Pre-Commitment Kill Criteria
Before any major architectural investment begins, define the conditions under which it will be stopped. This is the most direct mechanism for defeating sunk-cost bias because the decision to stop is made before the emotional investment begins. Kill criteria might include: if the project exceeds 150% of the budget, it is paused for executive review. If delivery speed has not improved within six months, the approach is reconsidered. If the two-system penalty exceeds 30% of engineering capacity for more than two quarters, the migration is suspended. These thresholds are established when the team is still rational about the investment (before money is spent) and enforced when they are most likely to be irrational (after money is spent).
Independent Architecture Audits
Staw’s escalation research confirms that the people who made the original decision are the most susceptible to sunk-cost bias regarding that decision. An independent auditor, someone with no involvement in the original decision and no identity investment in its success, can evaluate the architecture on future merits without the psychological weight of past investment. This is the Simplicity-First Complexity Audit, reframed as a sunk-cost countermeasure. The auditor asks one question: given what we know today, would we make this same architectural decision again? If the answer is no, the past investment is irrelevant to what comes next.
The Retrospective Future Test
A decision-making technique for counteracting sunk cost bias in real time: imagine you are a new CTO who arrived at the company yesterday. You have no history with any architectural decision. You see the current system, costs, and velocity. Would you approve starting the migration that is currently in progress? Would you continue funding the rewrite? Would you maintain the current architecture? If the answer is no, the only thing keeping the project alive is the sunk cost. Not the future value. This reframe removes the emotional attachment by removing the decision-maker’s identity from the decision.
Sunset Clauses for Architectural Initiatives
Essay 3 introduced sunset clauses for technology adoption. Essay 5 introduced them for cloud resources. This essay extends the mechanism to architectural initiatives: every migration, every rewrite, every platform investment should have a scheduled review date, during which the initiative must demonstrate that its future benefits justify its future costs. Past investment is explicitly excluded from the evaluation. The sunset clause transforms “we’ve invested too much to stop” into “the next review will tell us whether to continue.” The review date is fixed before the project starts, when the team can still think clearly about exit conditions.
The Simplicity-First Filters as Exit Ramps
The three filters, applied retrospectively to an in-progress architectural initiative, serve as exit ramp triggers. The 2 AM Test: is the new system easier to debug at 2 AM than the old one? If not after eighteen months, the migration is producing complexity rather than reducing it. The Half-Rule: have we built more than half of what was planned? If so, is the half we built delivering value on its own? If the first half has not improved anything, the second half will not either. Primary Path First: does the new architecture serve the 95% case better than the old one? If not, the architectural investment is serving the 5% edge case at the expense of the primary business.
The question is not whether you can afford to stop. The question is whether you can afford to continue. The money already spent is gone, regardless. The only money that matters is the money you have not yet spent.
~ ~ ~
The Six Economic Blind Spots
This series has built a complete economic diagnosis of why software architecture is the largest unmanaged cost center in most organizations. Six blind spots. Six economic concepts. One unified argument.
The Architecture Tax: architectural decisions carry financial weight equivalent to major capital expenditures, yet receive none of the financial scrutiny. The visible infrastructure cost is a fraction of the total, which includes operational overhead, coordination burden, cognitive load, and opportunity cost.
Opportunity Cost: every hour maintaining unnecessary complexity is an hour not shipping features, not learning from users, not responding to competitive threats. Delay is 8x more expensive than overspend. The opportunity cost is the largest cost category and the one nobody measures.
The Principal-Agent Problem: architects are rational agents in a system that rewards complexity. 82% believe trending tech advances their careers. 69% leave within two years. The person making the ten-year decision will not be present for the consequences. Mechanism design, not monitoring, is the solution.
Technical Debt Interest Rate: technical debt compounds through workaround cascades. A 20% debt burden at 15% annual growth reaches 45% in seven years and 67% in ten. AI accelerates principal accumulation at machine speed. The debt ceiling is the point at which all engineering effort goes toward servicing existing debt.
The Cloud Commons: cloud infrastructure operates as a commons where the benefit of over-provisioning is private and the cost is socialized. FinOps addresses symptoms. Chargeback fails at attribution, gaming, granularity, and the architecture ceiling. Ostrom’s governance principles offer the structural fix.
The Sunk Cost Architecture: even when organizations recognize all five preceding problems, they cannot change course because of what they have already invested. Loss aversion, identity fusion, escalation of commitment, status quo bias, and organizational momentum lock teams into failing architectures. Pre-commitment kill criteria, independent audits, and sunset clauses are the escape mechanisms.
The Final Diagnostic
For your most significant architectural initiative, answer six questions.
What is the total cost of the architecture, including infrastructure, operations, coordination, cognitive load, and opportunity cost? What could you have built instead with the engineering hours consumed by this architecture? Who proposed this architecture, and are they still present to bear the consequences? What is the carrying cost of the technical debt this architecture has created, and what is the interest rate? How much of your cloud spend is attributed to specific teams with clear ownership? If a new CTO arrived tomorrow with no history, would they approve continuing this initiative?
If the answers are uncomfortable, the diagnosis is clear. And the prescription is consistent across all six essays: make the invisible visible, make the incentives point toward simplicity, and design mechanisms that force the right decisions rather than hoping the right people will make them.
The profession has operated without financial accountability for too long. Architectural decisions are capital allocation decisions dressed in technical language. They deserve the same rigor, the same scrutiny, and the same willingness to cut losses as any other capital expenditure.
The architecture tax is what you pay. Opportunity cost is what you lose. Misaligned incentives are why you keep paying and losing. Compound interest is the mechanism that makes it unsustainable. The commons is the reason the bill keeps growing. And the sunk cost fallacy is the reason you cannot stop.
Fix the incentives. Calculate the costs. Design the mechanisms. And when the math tells you to stop, stop.
The money you already spent is gone. The money you have not yet spent is the only money that matters.