Build vs Buy Economics and Investment Decisions

The memo below is illustrative, though its shape will be familiar to many investment committees. A regional water authority wants software that listens to acoustic sensors on its pipes and flags likely leaks. Two options reach the committee on a single page.

The memo is tidy, confident and wrong in a way that is easy to miss. It sets a three-year subscription against the cost of reaching the first day of service. It says nothing about who runs the built system afterward, how long each option takes to start working, what the in-house team would otherwise be doing, or what happens if the vendor raises its price or the build runs late. Every one of those items has a number. This chapter puts them in.

The core idea

Build vs Buy vs Partner, in Module 04, settled the strategic question with two tests: would we still have an advantage if rivals had this capability, and how badly would a vendor’s change hurt us? This chapter takes the answer that survives those tests and prices it.

The idea is simple to state. Compare the decision, not the quote. Count both options on one boundary over the same service life, then add the costs that a price list never shows: time, scarce people, risk and exit. The output is not “build” or “buy”. It is a recommendation with the conditions under which it would change.

The steps borrow nothing exotic. Management accountants have taught the make-or-buy decision this way for decades: compare only the costs that differ between the options, ask what the freed capacity could do instead, and weigh factors such as supplier reliability¹. AI adds two twists. Its prices move faster than most components, and both options carry far more running cost than their headline suggests.

Buying is not zero engineering; building is not one-off

The two options hide their costs in opposite places. A purchase looks like a single run cost, but it still needs integration with the authority’s sensor platform and work-order system, data mapping, acceptance testing, a team to triage alerts and someone to manage the vendor. A build looks like a single project cost, but once it is live the authority owns everything the vendor would have carried: compute and storage, monitoring, security, on-call support, retraining and every model upgrade.

The cure is the module’s single definition of total cost of ownership, set out in Understanding AI Total Cost of Ownership: build plus run plus operate plus change, over the system’s whole life. Apply it to both options, on the same volume, for the same length of service. For the authority, whose figures here and below are invented for illustration, assume 4,000 sensors and three years of service from the day each option goes live.

The purchase costs 400,000 to integrate and test. The subscription is 200 per sensor a year, or 800,000, so run comes to 2.4 million over three years. Alert triage and vendor management add 350,000 a year, or 1.05 million, and configuration changes and renewal work add 50,000 a year, or 150,000. The three-year total is 4.0 million.

The build costs 1.2 million to reach its first day. Compute and storage run at 50 per sensor, or 200,000 a year: 600,000 over three years. Triage plus monitoring, security and on-call support come to 450,000 a year, or 1.35 million. Retraining and upgrades add 150,000 a year, or 450,000. The three-year total is 3.6 million.

On a like-for-like boundary the build still wins, but by 0.4 million, a tenth of the purchase cost, rather than the memo’s 1.2 million. That margin is small enough for the remaining steps to overturn.

The price of waiting

Options differ in when they start paying back, and the delay has a price. Donald Reinertsen, writing about product development, called it the cost of delay: the value lost for each unit of time that something useful is late. His advice was blunt: if you quantify only one thing, quantify the cost of delay². Many investment memos quantify everything else and leave this one out.

The vendor’s service can be live in four months. The build needs twelve. Suppose that, once live, the system is worth about 100,000 a month in water not lost, bursts avoided and crews sent to the right street. That is 25 per sensor a month at 4,000 sensors. Eight months of extra waiting costs 800,000, which by itself wipes out the build’s 0.4 million advantage and lifts the build to 4.4 million, above the purchase.

The estimate of monthly value will be uncertain, and that is not a reason to leave it out. A rough figure, stated with its range, is more honest than an implied value of zero. It also forces the useful question: is speed really worth that much here? For a capability that protects revenue or safety, it often is. For an internal convenience, it may be close to nothing, and then the build’s lower run cost deserves more weight.

Whose time does a build use?

A build estimate prices engineers at their salary. The real cost of using them is what they would otherwise have delivered. Accountants call this opportunity cost, and in make-or-buy decisions it works in both directions: buying frees capacity that can be applied to other work¹.

Suppose the authority’s data team is five people and the build would take them for a year. If they would otherwise deliver the pressure-management program the regulator has asked for, the build’s true cost includes the value of that program arriving a year late, net of what the team costs. If the team has spare capacity, the opportunity cost is close to zero and the salary is the right number. The question for the committee is therefore not “what does the team cost?” but “what is the team’s best other use, and is that our bottleneck?”

This cost is easy to leave out, because it never appears on any invoice. Yet in organizations where skilled AI engineers are the scarcest resource, it can decide the matter. Price it, or at least name the work that will wait.

Risk-adjust both options

An investment decision compares expected outcomes, not best cases, so each option needs a risk adjustment, and the two options carry risks of different shapes. On the build side, Building the Multi-Year AI Roadmap sets out how IT projects overrun and why the tail matters more than the average; here the committee simply budgets the average overrun of about 27 percent³.

Applied to the authority’s 1.2 million build, that average adds about 0.32 million and lifts the build, already at 4.4 million with delay, to 4.72 million. It is the gentle case. The committee does not need a probability model to go further. It needs to ask what the build costs if it goes badly, how much later it would then arrive, and whether the organization could absorb both.

Buying carries risk too. Vendors reprice when their own costs or strategies change, as AI Unit Economics and Economics at Scale showed with documented cases from 2025. Suppose the authority expects a 20 percent increase at renewal, applied to the third year: that adds 160,000 and lifts the purchase to 4.16 million. Against the build’s 4.72 million, the purchase now leads by about 0.56 million.

Vendors can also change products, degrade service or fail. Those risks are priced in the next step.

Price the exit before you sign

Every purchase is also a future migration. Carl Shapiro and Hal Varian showed that lock-in is an economic condition, not a moral failing: it exists whenever switching costs are high, and the time to evaluate them is before the first commitment, when the buyer still has leverage⁴. Build vs Buy vs Partner asked whether you could leave. The economic version asks what leaving would cost.

For the authority, a move to another provider or to its own model would mean reintegrating the sensor feeds, rebuilding the history of alerts and confirmed leaks, and running two systems in parallel for a few months. Suppose that is about 300,000. It is paid only if the authority leaves, so it sits beside the three-year comparison rather than inside it: any later move to building must save more than 300,000 to be worth making. The number also sets the contract terms worth negotiating: export of all sensor data, alert history and confirmed-leak labels in a usable format, a term short enough to revisit, and price protection at renewal. Each term lowers the cost of leaving, and a lower cost of leaving is worth paying for.

Find the point where the answer flips

The risk-adjusted comparison favors buying at 4,000 sensors. It is not a permanent verdict. The two options have different cost structures: the purchase is cheap to start and expensive per sensor, the build expensive to start and cheap per sensor. As AI Unit Economics and Economics at Scale showed with break-even volume, a higher fixed cost needs volume to pay for itself. So the useful output is the volume at which the answer flips.

On the chapter’s assumptions the risk-adjusted purchase costs about 640 per sensor over three years plus 1.6 million of fixed cost, while the build costs about 350 per sensor, including its share of the delay, plus 3.32 million. The lines cross near 5,900 sensors. The figures are undiscounted for simplicity; whether the winning option is worth funding at all is a business-case question, answered with the method in Module 03.

The flip point turns a one-off argument into a managed decision. The authority can buy now, on a two-year term with the exit terms above, and write down the trigger: if the sensor network is funded beyond about 6,000 units, or the vendor’s renewal price rises more than expected, the build case reopens. The actual volumes and costs will come from the monthly FinOps rhythm described in Cost Optimization and AI FinOps, which treats a forecast as something to compare with actuals and correct⁵⁶. Buying first is not a failure to decide. It buys time and evidence for the bigger commitment, at a price the committee can see.

Story: rent the model, or keep building?

Put yourself in a boardroom in Cupertino in March 2025. At its developer conference in June 2024, Apple had announced a more personalized Siri that would understand a user’s own context and act across apps. On 7 March 2025 it said publicly: “It’s going to take us longer than we thought to deliver on these features”⁷. The company had its own models, its own chips, its own private cloud and one of the largest cash flows in business. It also had a flagship feature a year late. Do you keep building the model yourself, or rent a stronger one from a rival?

Apple tested models from three outside providers. In November 2025, Bloomberg reported, in an account summarized by other outlets, that Apple was nearing a deal to pay roughly 1 billion a year for a custom model from Google, and that Apple saw the arrangement as temporary until its own models were strong enough. Neither company confirmed the price⁸. On 12 January 2026 the two companies announced a multi-year collaboration under which the next generation of Apple’s foundation models would be based on Google’s Gemini models. Apple said it had chosen this “after careful evaluation”, and that Apple Intelligence would continue to run on Apple devices and its own Private Cloud Compute⁹.

Read the decision through this chapter’s steps. The cost of delay had become the dominant number: every further year of building was a year of a promised feature missing from the most important product in the company. The reported rental was large in absolute terms and small against that delay. Apple bought the layer where outside providers were ahead and kept the layers that carry its privacy promise, the devices and the private cloud. And by calling the arrangement temporary it kept a written route back to building, the flip point stated in public. Whether the bet pays off is not yet known. The shape of the decision is the lesson.

What this means for leaders

Refuse any build-versus-buy comparison that sets a subscription against a build estimate. Ask for both options on the module’s four-family boundary, at the same volume, for the same service life. Then ask for three numbers that memos often leave out: the monthly value lost while waiting, the work the build team would otherwise do, and the cost of leaving the vendor. Treat overrun and repricing as expected costs, not footnotes. And never approve a sourcing decision without its flip point, the volume, price or capability change at which you would decide differently, with a date to look again.

Check yourself

1. A vendor’s annual price can be compared directly with an internal build estimate.MythFact
2. Buying an AI capability removes the need for engineering work.MythFact
3. The value lost while an option is not yet live is a real cost of that option.MythFact
4. The cost of an internal team is its salary.MythFact
5. Budgeting the average IT overrun covers the risk of a build.MythFact
6. Buying first can be a sound way to keep the option to build later.MythFact

Reflection: reprice one decision

What comes next

This chapter priced one decision. An AI portfolio holds many, each with its own costs, delays, risks and flip points, and they share budgets, platforms and people. The final chapter of the module, Module 08 Synthesis — Making AI Economically Sustainable, brings the cost structure, scaling economics and investment decisions together into one way of running AI as a sustainable investment.