--- # === IDENTITY === id: business/build-vs-buy/sunk-cost-build-decisions/2026 canonical_question: "When should you kill an internal build and switch to buy - sunk cost decision framework?" aliases: - "sunk cost fallacy software projects" - "when to kill internal build" - "abandon failing software project" - "pivot from build to buy" - "kill switch criteria software" entity_type: concept domain: business > build-vs-buy > Sunk Cost Build Decisions region: global jurisdiction: global temporal_scope: 2024-2026 # === VERIFICATION === last_verified: 2026-03-09 confidence: 0.88 version: 1.0 first_published: 2026-03-09 # === TEMPORAL VALIDITY === temporal_validity: status: stable last_breaking_change: null next_review: 2026-09-05 change_sensitivity: low # === CONSTRAINTS === constraints: - "Kill criteria must be established before project inception — retrofitting criteria during a crisis invites motivated reasoning and goal-post shifting" - "Financial thresholds alone are insufficient — projects can be within budget yet strategically dead (market shifted, competitor launched, requirements obsoleted)" - "This framework addresses the continue/kill decision, not the original build-vs-buy decision — if the project never should have been built, use the general build-vs-buy framework instead" - "Organizational politics often override rational kill decisions — executive sponsors protect their projects regardless of evidence, requiring escalation paths beyond the sponsor" - "Sunk cost awareness does not eliminate the bias — studies show that even people who understand the fallacy still fall prey to it under pressure" # === SKIP CONDITIONS === skip_this_unit_if: - condition: "User is making the initial build vs buy decision, not evaluating an in-progress build" use_instead: "business/build-vs-buy/build-vs-buy-enterprise-software/2026" - condition: "User needs the general build vs buy vs partner decision tree" use_instead: "business/build-vs-buy/build-vs-buy-vs-partner-decision-tree/2026" - condition: "User is evaluating whether to walk away from an ERP implementation already purchased" use_instead: "business/erp-selection/when-to-walk-away-erp-implementation/2026" # === AGENT HINTS === inputs_needed: - key: "build_situation" question: "What is the user's situation with their internal build?" type: choice options: - "Internal build is over budget and behind schedule — should we keep going or switch to buy?" - "A commercial alternative has emerged that covers most of our requirements — is it too late to switch?" - "Key engineers have left the project — can we still finish or should we abandon?" - "Leadership wants to kill the project but the team insists it is almost done" # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/business/build-vs-buy/sunk-cost-build-decisions/2026" suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-09)" # === RELATED UNITS === related_kos: related_to: - id: "business/build-vs-buy/build-vs-buy-enterprise-software/2026" label: "Build vs Buy for Enterprise Software" - id: "business/build-vs-buy/build-vs-buy-vs-partner-decision-tree/2026" label: "Build vs Buy vs Partner Decision Tree" often_confused_with: - id: "business/erp-selection/when-to-walk-away-erp-implementation/2026" label: "When to Walk Away from ERP Implementation (buy-side abandonment, not build-side)" depends_on: [] solves: [] alternative_to: [] # === SOURCES === sources: - id: src1 title: "How to avoid sunk cost fallacy in software projects" author: Equal Experts url: https://www.equalexperts.com/blog/our-thinking/how-to-avoid-sunk-cost-fallacy-in-software-projects/ type: technical_blog published: 2024-03-15 reliability: high - id: src2 title: "How To Avoid Sunk Software Development Costs" author: Emergent Software url: https://www.emergentsoftware.net/blog/what-is-sunk-cost-fallacy-and-how-to-avoid-sunk-software-development-costs type: technical_blog published: 2024-06-01 reliability: moderate_high - id: src3 title: "Implementing Kill Switch Criteria for Project Success" author: Productive Patty url: https://www.productivepatty.com/implementing-kill-switch-criteria-for-project-success/ type: technical_blog published: 2024-09-01 reliability: moderate_high - id: src4 title: "Build vs. Buy Software: A 3-Model Decision Framework" author: Neontri url: https://neontri.com/blog/build-vs-buy-software/ type: technical_blog published: 2025-01-15 reliability: moderate_high - id: src5 title: "Sunk Cost Fallacy: Definition, Examples, How to Avoid" author: Asana url: https://asana.com/resources/sunk-cost-fallacy type: technical_blog published: 2025-04-01 reliability: moderate_high - id: src6 title: "The Sunk Cost Fallacy" author: The Decision Lab url: https://thedecisionlab.com/biases/the-sunk-cost-fallacy type: primary_research published: 2024-01-01 reliability: high --- # Sunk Cost Build Decisions ## Definition The sunk cost decision framework for internal builds is a structured evaluation process that forces teams to assess whether to continue, pivot, or abandon an in-progress software project based exclusively on forward-looking costs and benefits, deliberately excluding money, time, and effort already spent. [src1] The framework counteracts the sunk cost fallacy — the well-documented cognitive bias where decision-makers continue investing in a failing project because of what has already been invested rather than what remains to be gained. Over 35% of large enterprise custom software initiatives are abandoned, and projects that should have been killed earlier consume 2-3x the resources of a timely termination. [src6] ## Key Properties - **Core principle**: Only forward-looking costs and benefits matter — past investment is irrelevant to the continue/kill decision [src1] - **Kill criteria timing**: Must be established before project inception, not during a crisis — retrofitting criteria introduces motivated reasoning [src3] - **Stage-gate checkpoints**: Formal review points (typically every 3-6 months or at major milestones) where pre-defined kill criteria are evaluated against actual progress [src3] - **Quantified thresholds**: Budget overrun >15%, schedule slip >30%, or market demand decline >30% are common trigger thresholds for termination review [src3] - **Stop-Start-Continue model**: Three options at every checkpoint — stop the project entirely, start a new approach (pivot to buy), or continue with current path [src1] - **Behavioral bias persistence**: Even teams aware of sunk cost fallacy still exhibit the bias under pressure — structural safeguards (independent reviewers, pre-committed criteria) are required [src6] ## Constraints - Kill criteria must be established before project inception. Retrofitting criteria during a crisis invites motivated reasoning and goal-post shifting. [src3] - Financial thresholds alone are insufficient. Projects can be within budget yet strategically dead because the market shifted, a competitor launched, or requirements were obsoleted. [src4] - This framework addresses the continue/kill decision for in-progress builds, not the original build-vs-buy decision. If the project never should have been built, use the general build-vs-buy framework. [src1] - Organizational politics often override rational kill decisions. Executive sponsors protect their projects regardless of evidence, requiring escalation paths beyond the sponsor. [src6] - The "almost done" trap is the most dangerous form of sunk cost reasoning. Projects that are "90% done" frequently require as much remaining effort as the first 90% consumed. [src2] ## Framework Selection Decision Tree ``` START — User has an in-progress internal build that may need to be killed ├── Is this about the initial build vs buy decision? │ ├── YES → Build vs Buy for Enterprise Software [skip] │ └── NO → Continue here ← YOU ARE HERE ├── Is the project over budget, behind schedule, or missing requirements? │ ├── YES → Apply the kill criteria evaluation (Step 1 below) │ └── NO → Has the competitive/market landscape changed? │ ├── YES → Apply strategic viability review (Step 2 below) │ └── NO → Project may be healthy — revisit at next stage gate ├── Has a commercial alternative emerged that covers >60% of requirements? │ ├── YES → Run the forward-looking cost comparison (Step 3) │ └── NO → Killing the build leaves you with no solution — evaluate pivot options ├── Have you lost key engineering talent? │ ├── YES (>30% of core team) → Strongly consider kill — rebuilding team knowledge is often costlier than starting fresh with buy │ └── NO → Talent is not the trigger — evaluate other criteria └── Is the project "almost done" (team says 2-4 weeks remaining)? ├── YES → Apply the 90/90 rule: the last 10% often takes as long as the first 90% │ ├── Has the team said "almost done" before? → RED FLAG — kill bias is high │ └── First time → Set hard deadline, evaluate at deadline └── NO → Continue stage-gate evaluation ``` ## Application Checklist ### Step 1: Evaluate against pre-defined kill criteria - **Inputs needed**: Original kill criteria (budget threshold, schedule threshold, market demand threshold), current project actuals, remaining work estimate - **Output**: Pass/fail assessment against each criterion - **Constraint**: If kill criteria were not set at project inception, establish them now using industry benchmarks (>15% budget overrun, >30% schedule slip, >30% market demand decline) but acknowledge the higher risk of motivated reasoning. [src3] ### Step 2: Run forward-looking cost-benefit analysis - **Inputs needed**: Remaining cost to complete the build (with 50-100% buffer), cost of switching to buy (license + implementation + migration + retraining), value of the completed build vs the buy alternative - **Output**: Net value comparison for continue vs kill, using only future costs and benefits - **Constraint**: Deliberately exclude all past spending from the analysis. The question is not "we have spent $2M, should we waste it?" but "given where we are today, does spending $X more deliver more value than spending $Y on an alternative?" [src1] ### Step 3: Assess strategic viability - **Inputs needed**: Current competitive landscape, commercial alternatives available today (not when the build started), customer/user feedback on the in-progress build, remaining engineering capacity - **Output**: Strategic viability assessment — is the build still solving a problem worth solving, in a way that no commercial alternative can match? - **Constraint**: If a commercial solution has emerged since the build started that covers >60% of requirements at lower forward cost, the strategic case for continuing the build is severely weakened regardless of progress. [src4] ### Step 4: Make the stop/start/continue decision - **Inputs needed**: Kill criteria evaluation, forward-looking cost comparison, strategic viability assessment - **Output**: Decision with specific next action — continue (with revised timeline/budget), pivot to buy (with migration plan), or stop entirely - **Constraint**: The decision must be made by someone other than the project sponsor, or by a review board that includes at least one person with no political stake in the project continuing. [src6] ## Anti-Patterns ### Wrong: "We have already spent $2M — we cannot walk away now" This is the textbook sunk cost fallacy. The $2M is gone regardless of the decision. Continuing to invest because of past spending is like staying at a bad movie because you already bought the ticket. The only relevant question is whether future investment delivers more value than the alternatives. [src1] ### Correct: "What is the cheapest path from here to a working solution?" Evaluate the forward cost of completing the build against the forward cost of switching to buy. Include migration costs, retraining, and timeline. The answer may still be "continue building" — but the reasoning is sound because it ignores sunk costs. [src1] ### Wrong: "The team says it is almost done — just two more sprints" The "almost done" claim is the most dangerous trigger for sunk cost escalation. Software projects that are reportedly "90% done" frequently require as much remaining effort as the first 90% consumed — this is known as the 90/90 rule. If the team has claimed "almost done" more than once, the project is not almost done. [src2] ### Correct: "Set a hard deadline and evaluate objectively at that point" If the team claims the project is nearly complete, set a firm, non-negotiable deadline. At that deadline, evaluate whether the deliverable meets the original acceptance criteria. If it does not, trigger the kill criteria review regardless of how close it appears to be. [src3] ### Wrong: "Killing the project means admitting failure" Organizations that punish project termination create a culture where teams hide problems and escalate commitment to failing projects. The real failure is consuming additional resources on a doomed project instead of reallocating them to higher-value work. [src6] ### Correct: "Killing a failing project is a success — it freed resources for better use" Establish a culture where timely termination is valued as a skill. Run post-mortems that celebrate what was learned and how resources were redirected, not who is to blame. Companies like Amazon explicitly celebrate "two-way door" decision-making, where reversibility is a feature. [src5] ## Common Misconceptions - **Misconception**: Understanding the sunk cost fallacy makes you immune to it. **Reality**: Awareness does not eliminate the bias. Studies show that even behavioral economists and trained decision-makers exhibit sunk cost behavior under organizational pressure. Structural safeguards — independent reviewers, pre-committed criteria, mandatory stage gates — are required, not just education. [src6] - **Misconception**: If a project is over budget, it should be killed immediately. **Reality**: Budget overruns alone do not justify killing a project. A project can be over budget but still deliver more value forward than any alternative. The kill decision requires a forward-looking comparison, not a backward-looking audit of past spending. [src3] - **Misconception**: The sunk cost framework only applies to large enterprise projects. **Reality**: Sunk cost bias affects projects of all sizes — from a startup's MVP that pivoted too late, to a team's internal tool that should have been replaced by a SaaS product months ago. The framework scales: smaller projects need lighter stage gates (monthly check-ins) but the same forward-looking evaluation. [src5] - **Misconception**: Pivoting from build to buy means all prior work was wasted. **Reality**: The knowledge gained during the build — detailed requirements, integration points, edge cases, performance needs — is directly transferable to vendor evaluation and implementation. Organizations that attempted to build first typically run faster, more accurate vendor evaluations because they deeply understand the problem space. [src2] ## Comparison with Similar Concepts | Concept | Key Difference | When to Use | |---|---|---| | Sunk Cost Build Decisions | Forward-looking kill/continue framework for in-progress builds | When an internal build may need to be abandoned | | Build vs Buy for Enterprise Software | Initial decision framework before any build starts | When deciding whether to build or buy from scratch | | Build vs Buy vs Partner Decision Tree | General-purpose framework including the partner option | When evaluating all three options for any capability | | When to Walk Away from ERP Implementation | Buy-side abandonment (walking away from a vendor) | When an already-purchased implementation is failing | ## When This Matters Fetch this when a user asks about killing or abandoning an internal software project, dealing with sunk cost in technology decisions, evaluating whether to continue or stop a build that is over budget or behind schedule, or deciding whether to pivot from an in-progress build to a commercial solution. Also relevant when someone asks about stage-gate processes for software projects or kill switch criteria. ## Related Units - [Build vs Buy for Enterprise Software](/business/build-vs-buy/build-vs-buy-enterprise-software/2026) - [Build vs Buy vs Partner Decision Tree](/business/build-vs-buy/build-vs-buy-vs-partner-decision-tree/2026) - [When to Walk Away from an ERP Implementation](/business/erp-selection/when-to-walk-away-erp-implementation/2026)