When does building internally pay off versus continuing to pay a vendor? Crossover point is the answer.
№ 207 · Build vs buy payback curve
Definition
MetricCumulative cost of building and running internally against cumulative vendor cost, read at the crossover point
Unitcumulative cost in currency, plus the crossover month
Two cumulative cost curves: internal build (front-loaded then flat) vs vendor spend (linear). Crossover is the answer. Build by modeling internal cost (eng plus ops) vs vendor pricing over time. Example: Build crosses below Buy at M24 (build wins long-term if you survive M24).
Benchmarks
| Bottom 30% | Median | Top 30% |
|---|---|---|
| no crossover inside 5 years once fully loaded, or a crossover that only exists because the build line was drawn flat after launch | crossover at 30 to 42 months | honest crossover inside 24 months once maintenance and an overrun allowance are loaded |
Enterprise IT build projects. The overrun distribution comes from Flyvbjerg and Budzier's analysis of 1,471 IT projects and the McKinsey and University of Oxford study of large IT projects; the maintenance tail comes from software total cost of ownership convention. Bands are constructed from those inputs rather than observed as a distribution of crossover months. · This is the weakest evidence base in the section and the reason is structural: nobody publishes a panel of build against buy crossover points, because the counterfactual is never run. The defensible inputs are the overrun distribution and the maintenance tail, and the strongest of those are 2011 and 2012 vintage. Flyvbjerg and Budzier's 1,471 project sample and the McKinsey and Oxford work both predate cloud infrastructure economics and AI-assisted development, and no comparable large-sample replacement exists, so they are used here as the best available rather than as current. Nearly all 2025 and 2026 material on build against buy is vendor marketing and has been excluded. The single most important structural point is that the build line is not a project line: roughly 80% of a system's total cost arrives after launch, so a curve that flattens at go-live is wrong by construction and will produce a crossover that does not exist.
Category split omitted: No two independent Tier 1-2 sources publish build against buy crossover by software category; the available category material is vendor marketing.
When it looks bad
The build line is drawn as a one-off capital cost that stops rising after launch, so the two curves cross early and the crossover is an artefact of the missing maintenance tail rather than a real finding.
Build modelled at 480,000 with the line flat from month 9 against a vendor at 14,000 a month gives a crossover at month 34. Add a 27% overrun allowance and 18% a year maintenance and the crossover moves past month 60.
What to do about it
- Draw the build line as a perpetual line rather than a project. Roughly 80% of a system's total cost lands after launch, so any build curve that flattens at go-live is wrong before the first number is entered (Forrester, via Neontri).
- Add an overrun allowance to the build side before comparing. The mean IT project in a 1,471 project sample overran 27%, and one in six overran 200% on cost and almost 70% on schedule, so a point estimate is the wrong input and a distribution is the right one (Flyvbjerg and Budzier, 2011).
- Break the build into pieces small enough to fail cheaply and re-decide at each boundary. CHAOS data puts small project success near 90% against large project success below 10%, with size the strongest single predictor, and each additional year of runtime adding about 15% to overrun (Standish Group, 2020).
- Price the exit on both sides of the curve. Vendor lock-in cost and the cost of maintaining an internal system that nobody wants to own are the two real failure modes, and neither appears on a chart that only counts spend.
Sources
- Bent Flyvbjerg and Alexander Budzier, Harvard Business Review Average cost overrun 27%, but one in six projects was a black swan with a cost overrun of 200% on average and a schedule overrun of almost 70%. The risk is the fat tail rather than the mean. Flagged as 2011 data in a 2026 reference. arxiv.org ↗
- Bent Flyvbjerg and Alexander Budzier The average black swan project overruns cost by 130% in real terms and falls 41% behind schedule. Separately, half of public sector IT projects in the four year window studied suffered an average budget cut of 75%, a second and different failure mode. Flagged as 2013 data. arxiv.org ↗
- McKinsey and University of Oxford, reported by BudgetOverrun Large IT projects run 45% over budget and 7% over time while delivering 56% less value than predicted. 17% of large IT projects go so badly that they threaten the existence of the company. Underlying study is Bloch, Blumberg and Laartz, 2012, so the data is dated. budgetoverrun.com ↗
- Standish Group, reported by Rockstar Developer University Small projects achieve roughly 90% success rates while large projects succeed less than 10% of the time. Each additional year a project runs increases cost overruns by about 15%. Project size is the strongest single predictor in the dataset. rockstardeveloperuniversity.com ↗
- Zylo Total cost of ownership is underestimated on both paths, usually by a factor of two to three. AI-assisted development has changed the arithmetic only for a narrow slice of low-stakes internal tooling; faster build does not lower the maintenance bill, and the relevant horizon is the five to seven years after launch. zylo.com ↗
- Forrester and Altexsoft, reported by Neontri Roughly 80% of a software system's total cost occurs after the initial launch. Commercial off-the-shelf and SaaS solutions deploy 40 to 60% faster than custom-built alternatives, which is the time-to-value side of the same decision. neontri.com ↗
- CIO.com survey, reported by Keyhole Software A majority of organisations misestimate AI system costs by more than 10%, with nearly a quarter underestimating by 50% or more. The largest costs emerge after initial deployment, in maintenance, data management, integration and compliance rather than in build. keyholesoftware.com ↗
- SoftwareSeni Internal maintenance of an adopted open source stack typically requires 1 to 3 dedicated full-time staff, and integration and compatibility work is consistently underestimated at 20 to 40% of implementation effort. Commercial support contracts for enterprise open source run 15 to 30% of equivalent proprietary licence cost. softwareseni.com ↗