The Build vs Buy Decision Is Broken: How Executives Actually Get It Wrong

Every technology leader has sat through the build-vs-buy meeting. Engineering wants to build. Finance wants to buy. The CTO makes a spreadsheet comparing cost, timeline, and control. Everyone argues for two hours. Then the highest-paid person in the room makes a gut call, and the spreadsheet is never opened again.

This process is broken. Not because the frameworks are wrong (they capture the right variables), but because executives systematically miscalculate the inputs. They undercount building costs by 2-5x. They overcount vendor risk by conflating inconvenience with catastrophe. And they let organizational politics drive what should be an economic decision.

The result: companies build things they should buy, buy things they should build, and almost nobody makes this decision well. Across dozens of documented build-vs-buy decisions in financial services and technology companies, the same mistakes appear. Here's where the thinking actually goes wrong, and how to fix it.

Mistake #1: Undercounting the True Cost of Building

When an engineering team proposes building a system in-house, the cost estimate almost always includes three things: developer salaries for the build phase, infrastructure costs, and a timeline. Something like "four engineers for six months, plus $2,000/month in AWS costs."

This estimate is wrong. It's wrong every time. Not because engineers are bad at estimating (though they are, and so is everyone else), but because the estimate structurally excludes the majority of the actual cost.

Maintenance is the iceberg. Building a system takes 6-12 months. Maintaining it takes forever. After launch, the system needs bug fixes, security patches, dependency updates, performance optimization, and feature enhancements. The industry rule of thumb is that annual maintenance costs 15-25% of the original build cost. Over a five-year period, maintenance typically exceeds the original build cost by 2-4x.

A system that costs $500,000 to build will cost $375,000 to $625,000 to maintain over the next five years. The total five-year cost is $875K to $1.1M. The original estimate of $500K captured less than half of the real number.

Opportunity cost is invisible but real. Those four engineers spending six months building an internal tool are NOT building the product features that drive revenue. If your company generates $10 million in annual revenue and those four engineers represent 10% of your product capacity, the opportunity cost of diverting them for six months is roughly $500,000 in delayed or forgone product development. This never appears in the build-vs-buy spreadsheet because it's a counterfactual, but it's one of the most significant costs.

Hiring and retention compound the problem. Specialized systems require specialized knowledge. When the two engineers who built the internal system leave (and engineers change jobs every 2-3 years on average), the knowledge walks out the door. Hiring replacements who can maintain a custom codebase they didn't write takes months and carries a productivity ramp of 3-6 months. Meanwhile, the system accumulates technical debt as remaining team members patch rather than properly maintain it.

The real calculation: If you're comparing a $50,000/year SaaS vendor to a $500,000 internal build, you're not comparing $50K to $500K. You're comparing $250K over five years (vendor) to $875K-$1.1M over five years (build + maintain + opportunity cost + knowledge loss). The build is 3-4x more expensive than the original estimate suggested.