--- # === IDENTITY === id: business/build-vs-buy/we-can-build-it-cheaper-trap/2026 canonical_question: "Why are internal build cost estimates systematically 2-5x too low?" aliases: - "we can build it cheaper fallacy" - "software build cost underestimation" - "planning fallacy software development" - "build cost optimism bias" - "internal build estimate too low" entity_type: concept domain: business > build-vs-buy > We Can Build It Cheaper Trap region: global jurisdiction: global temporal_scope: 2020-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: - "The 2-5x multiplier is a cross-industry average — highly regulated industries (healthcare, finance) skew higher while small internal tools skew lower" - "Reference class forecasting requires access to historical project data that many organizations do not systematically collect" - "Some cost categories (opportunity cost, organizational drag) are genuinely difficult to quantify even with awareness of the bias" - "The planning fallacy is a cognitive bias, not a moral failing — debiasing requires structural process changes, not just awareness" - "Estimates from experienced engineers are still subject to the same biases — expertise reduces but does not eliminate the gap" # === SKIP CONDITIONS === skip_this_unit_if: - condition: "User needs the overall build vs buy decision framework, not just cost estimation bias" 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 needs to estimate specific software development costs (not diagnose bias)" use_instead: "business/build-vs-buy/build-vs-buy-enterprise-software/2026" # === AGENT HINTS === inputs_needed: - key: "estimation_context" question: "What is the user's situation with build cost estimation?" type: choice options: - "Evaluating an internal team's claim that building is cheaper than buying" - "Trying to understand why a past build project exceeded its budget by 2-5x" - "Seeking debiasing techniques for more accurate software cost estimation" - "Building a business case and needs realistic cost multipliers for internal builds" # === DISTRIBUTION === canonical_source: "https://knowledgelib.io/business/build-vs-buy/we-can-build-it-cheaper-trap/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" - id: "business/build-vs-buy/build-vs-buy-integration-layer/2026" label: "Build vs Buy for Integration Layer" often_confused_with: - id: "business/build-vs-buy/build-vs-buy-enterprise-software/2026" label: "Build vs Buy for Enterprise Software (decision framework, not estimation bias)" depends_on: [] solves: [] alternative_to: [] # === SOURCES === sources: - id: src1 title: "Planning Fallacy" author: Wikipedia / Kahneman & Tversky url: https://en.wikipedia.org/wiki/Planning_fallacy type: academic_paper published: 2025-01-01 reliability: authoritative - id: src2 title: "The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution" author: Journal of Management Information Systems (Flyvbjerg & Budzier) url: https://www.tandfonline.com/doi/full/10.1080/07421222.2022.2096544 type: academic_paper published: 2022-10-01 reliability: authoritative - id: src3 title: "Project Cost Overrun: Data Reports 2026" author: WifiTalents url: https://wifitalents.com/project-cost-overrun-statistics/ type: industry_report published: 2026-01-01 reliability: moderate_high - id: src4 title: "Build vs Buy Software: Hidden Costs That Change Everything" author: Netguru url: https://www.netguru.com/blog/build-vs-buy-software type: technical_blog published: 2025-06-01 reliability: moderate_high - id: src5 title: "Planning Fallacy: Causes and Solutions for Project Expectations" author: Project Management Institute url: https://www.pmi.org/learning/library/planning-fallacy-causes-solutions-project-expectations-6374 type: industry_report published: 2024-01-01 reliability: high - id: src6 title: "The influence of selection bias on effort overruns in software development projects" author: Information and Software Technology (Jorgensen & Grimstad) url: https://www.sciencedirect.com/science/article/abs/pii/S0950584913000633 type: academic_paper published: 2013-06-01 reliability: authoritative --- # The "We Can Build It Cheaper" Trap ## Definition The "We Can Build It Cheaper" trap is the systematic cognitive pattern where internal software build cost estimates are 2-5x lower than actual costs, driven by a convergence of the planning fallacy (optimistic inside-view estimation), hidden cost blindness (omitting maintenance, infrastructure, and opportunity costs), and organizational incentive structures that reward underestimation to secure project approval. [src1] Research across IT projects shows a mean cost overrun ratio of 1.8x, with software projects averaging 66% cost overrun and the distribution exhibiting fat-tailed (power-law) characteristics where extreme overruns are far more common than normal distributions predict. [src2] ## Key Properties - **Overrun magnitude**: Software projects average 66% cost overrun; large IT projects (>$15M) run 45% over budget on average; the distribution is fat-tailed, meaning 5-10x overruns are more frequent than expected [src2] [src3] - **Root cause taxonomy**: Three distinct drivers — cognitive bias (planning fallacy/optimism), information gaps (hidden costs not modeled), and strategic misrepresentation (deliberate underestimation to win approval) [src1] - **Hidden cost categories typically omitted**: Ongoing maintenance (40-60% of initial build cost per year), infrastructure and security, testing and QA, documentation, onboarding/training, talent retention risk ($15K-$30K per replacement), and opportunity cost of engineering time [src4] - **Cognitive mechanism**: The "inside view" — estimators focus on the specific project's unique features and best-case scenario rather than base rates from similar past projects [src1] - **Selection bias amplifier**: Projects with the lowest (most optimistic) estimates are most likely to be approved, creating a systematic filter that selects for underestimation [src6] - **Scope creep contribution**: Scope creep affects 52% of IT projects, contributing additional cost increases beyond the initial estimation error [src3] ## Constraints - The 2-5x multiplier is a cross-industry average derived from meta-analyses. Highly regulated industries (healthcare, finance) typically skew higher due to compliance costs, while small internal tools with narrow scope may overrun less. [src2] - Reference class forecasting (the primary debiasing technique) requires access to historical data from comparable completed projects. Many organizations do not systematically collect this data, making the technique difficult to apply. [src5] - Some cost categories are genuinely difficult to quantify even with full awareness of the bias — opportunity cost of engineering time, organizational drag from context-switching, and second-order effects on team morale and retention. [src4] - The planning fallacy is a cognitive bias rooted in how humans process information, not a failure of effort or intelligence. Debiasing requires structural process changes (external review, reference classes), not just telling estimators to "be more realistic." [src1] - Experienced engineers produce slightly better estimates than juniors but are still subject to the same directional biases. Expertise reduces variance but does not eliminate systematic optimism. [src5] ## Framework Selection Decision Tree ``` START — User asking about software cost estimation or build vs buy costs ├── What's the core question? │ ├── "Why did our build project go over budget?" │ │ └── The "We Can Build It Cheaper" Trap ← YOU ARE HERE │ ├── "Should we build or buy this software?" │ │ └── → Build vs Buy for Enterprise Software │ ├── "How do we choose between build, buy, and partner?" │ │ └── → Build vs Buy vs Partner Decision Tree │ └── "How do we estimate software costs more accurately?" │ └── The "We Can Build It Cheaper" Trap ← YOU ARE HERE ├── Is the user evaluating a specific estimate right now? │ ├── YES → Apply the 6 Hidden Cost Categories audit (Application Checklist below) │ └── NO → Provide the bias taxonomy and debiasing techniques └── Has the project already started and is over budget? ├── YES → Focus on sunk cost fallacy prevention + realistic re-estimation └── NO → Focus on pre-mortem and reference class forecasting ``` ## Application Checklist ### Step 1: Audit the estimate for hidden cost categories - **Inputs needed**: The current internal build cost estimate, line items included, and assumptions - **Output**: Gap analysis showing which of the 6 hidden cost categories are missing or underestimated - **Constraint**: If the estimate does not include separate line items for ongoing maintenance, infrastructure/security, testing/QA, documentation, training/onboarding, and talent retention risk, it is systematically too low. All 6 must be present. [src4] ### Step 2: Apply the maintenance multiplier - **Inputs needed**: Initial development cost estimate - **Output**: 5-year total cost of ownership including maintenance - **Constraint**: Annual maintenance typically costs 40-60% of initial development cost. If the estimate shows maintenance below 30% of initial cost, it is almost certainly underestimated. Multiply initial estimate by 3-4x for a realistic 5-year TCO. [src4] ### Step 3: Perform reference class forecasting - **Inputs needed**: 5-10 comparable completed projects (internal or industry benchmarks) with actual vs estimated costs - **Output**: Probability distribution of likely actual cost based on historical base rates - **Constraint**: The reference class must consist of genuinely comparable projects (similar scope, technology, team size). Cherry-picking successes invalidates the exercise. If no reference class is available, apply the industry-average 1.8-2.5x multiplier to the bottom-up estimate. [src2] [src5] ### Step 4: Run a pre-mortem exercise - **Inputs needed**: The project plan, team composition, and stakeholder list - **Output**: List of 10-15 specific failure modes with cost impact estimates - **Constraint**: The pre-mortem must be conducted by people who are NOT the original estimators and do NOT have a stake in project approval. Estimators running their own pre-mortem reproduce the same biases. [src1] ### Step 5: Compare adjusted build cost to buy alternatives - **Inputs needed**: Adjusted build TCO (from Steps 1-4), vendor quotes for buy alternatives (including implementation and 5-year maintenance) - **Output**: Apples-to-apples cost comparison with uncertainty ranges - **Constraint**: If the adjusted build cost exceeds 150% of the buy alternative's 5-year TCO, building is almost never justified unless the capability is a core competitive differentiator. [src4] ## Anti-Patterns ### Wrong: Estimating build cost as (number of developers x months x salary) Teams estimate build cost using only direct engineering labor, arriving at figures like "$400K for 4 developers x 6 months." This misses infrastructure, security, testing, documentation, project management overhead, and the 40-60% annual maintenance tax that follows. The actual 5-year cost is typically $1.2M-$2M. [src4] ### Correct: Using a full-loaded TCO model with all 6 cost categories Include direct engineering, infrastructure/DevOps, security/compliance, testing/QA, documentation/training, and ongoing maintenance. Then add a 15-20% contingency for scope changes and a talent retention risk premium. Compare 5-year TCO, not first-year build cost. [src4] ### Wrong: Letting the team that proposed building also estimate the cost The team advocating for a build has a structural incentive to produce low estimates — their preferred project gets approved, they get to work on interesting technology, and the estimate is evaluated before reality checks it. This is strategic misrepresentation, and it accounts for a significant portion of underestimation in organizational settings. [src1] [src6] ### Correct: Using independent estimation with reference class data Have the cost estimate reviewed or produced by a team that does not have a stake in the build/buy decision outcome. Anchor the estimate in reference class data from comparable completed projects, not in the specific project's optimistic scenario. [src5] ### Wrong: Citing a past successful build as proof that "we can do it again" Survivorship bias — the organization remembers the one project that came in on time and budget while forgetting or rationalizing the three that did not. The successful project may also have had advantages (smaller scope, experienced team, stable requirements) that do not transfer to the current project. [src3] ### Correct: Using the full distribution of past project outcomes Collect actual vs estimated costs for ALL past projects, not just the successes. Plot the distribution and identify the median and 80th percentile outcomes. Plan for the median, budget for the 80th percentile. [src2] ## Common Misconceptions - **Misconception**: Experienced engineers produce accurate estimates because they have "been through it before." **Reality**: Research consistently shows that experience reduces variance but does not eliminate the directional bias. Senior engineers are somewhat better calibrated but still systematically optimistic. The planning fallacy affects experts and novices alike because it stems from taking the "inside view" of the specific project rather than consulting base rates. [src1] [src5] - **Misconception**: Agile methodology eliminates estimation risk because you "discover as you go." **Reality**: Agile reduces the risk of building the wrong thing but does not reduce the total cost of building the right thing. Iterative development still incurs infrastructure, maintenance, security, and organizational costs. In some cases, agile increases total cost by enabling continuous scope expansion without a fixed budget constraint. [src3] - **Misconception**: The 2-5x multiplier is exaggerated — most projects are only slightly over budget. **Reality**: The distribution of cost overruns follows a power law (fat-tailed distribution), not a normal distribution. While the mode is near 0% overrun, the mean overrun is 66% for software projects, and extreme overruns (5-10x) occur far more frequently than a normal distribution would predict. A small number of catastrophic overruns pull the average significantly higher than the median. [src2] - **Misconception**: Adding a "buffer" or "contingency" of 20-30% to the estimate solves the problem. **Reality**: If the base estimate is missing entire cost categories (maintenance, infrastructure, talent retention), a 20-30% buffer on an incomplete estimate is still far below reality. The buffer needs to be applied to a complete estimate, and empirical data suggests 50-100% buffers are necessary for accurate coverage at the 80th percentile. [src2] [src5] ## Comparison with Similar Concepts | Concept | Key Difference | When to Use | |---|---|---| | "We Can Build It Cheaper" Trap | Diagnoses WHY estimates are too low (cognitive + structural causes) | When evaluating whether an internal build estimate is realistic | | Build vs Buy for Enterprise Software | Full decision framework with cost benchmarks | When making the build/buy/hybrid decision for ERP/CRM/HCM | | Build vs Buy vs Partner Decision Tree | General framework including partner option | When the decision space includes outsourcing or partnering | | Planning Fallacy (general) | Broad cognitive bias across all project types | When understanding estimation bias beyond software specifically | ## When This Matters Fetch this when a user is evaluating an internal team's claim that building software is cheaper than buying, when a build project has exceeded its budget and the user wants to understand why, when someone needs debiasing techniques for software cost estimation, or when building a business case that requires realistic cost multipliers for internal development. This card is specifically about the estimation bias itself, not the broader build vs buy decision. ## 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) - [Build vs Buy for Integration Layer](/business/build-vs-buy/build-vs-buy-integration-layer/2026)