On 8 July 2026 Intercom published a page comparing what an AI support agent costs. Fin: 99 cents per resolved outcome. Zendesk: $1.20 to $1.50 per verified resolution if you commit, closer to $2 if you do not. Salesforce Agentforce: $2 per conversation, or Flex Credits at $500 per 100,000 credits, roughly 10 cents a standard action, sitting on top of Service Cloud Enterprise at $175 per user per month and an implementation somewhere between $50,000 and $150,000.
Three vendors. Three different units of account. It is Intercom’s own comparison page, so read the framing with the suspicion it deserves. The prices are still the prices.
I read it twice. Then I opened the build versus buy model I have used for a decade and realised there is no cell to put any of that in.
The thesis
Cost is no longer the deciding variable in build versus buy. Build got cheap enough that the number stopped being decisive. Buy stopped producing a number you can forecast at all. The variable that replaced cost is reversibility: how many days it takes to undo the choice you just made.
What actually changed
Two things moved at once, in opposite directions.
Build got cheap at the front and expensive at the back. New Relic surveyed 200 US technology decision makers, manager level and above, published 10 June 2026.
67% said AI now generates or significantly refactors between 51% and 75% of their weekly code output. Google has publicly put its own figure near 75%, Microsoft around 30%, GitHub Copilot 46%. Whatever the real number inside your organisation, the first working version of an internal tool is no longer a two-quarter project with a business case attached.
The same survey carries the other half. 78% reported a measurable spike in production incidents tied to AI-written code. 86% saw senior engineers spending more time firefighting. 74% said at least a quarter of AI-written code needed significant rework after deployment. The report puts AI-generated code at roughly 1.7 times more critical runtime issues.
The build got cheap. The run got expensive. That is a different shape of decision, not a smaller one.
Buy stopped being a fixed price. Zylo’s 2026 SaaS Management Index covers 40 million licences and $75 billion in spend under management. Median SaaS spend per employee: $9,455. Licences sitting unused: 36%. AI-native application spend in organisations above 10,000 people: up 393% year on year. Large enterprises are adding 21 applications a month.
The figure that matters most sits in their survey of 218 IT leaders. 78% reported unexpected charges from consumption-based or AI pricing models. 61% were forced to cut projects because of unplanned SaaS cost increases.
Read that second number again. Three in five technology organisations killed work they had already committed to, because a vendor bill landed above forecast. That is not a procurement problem. That is a budget that has stopped being a budget.
For scale: Gartner put worldwide software spend at $1,468 billion for 2026, growing 15.5%, against IT services at $1,570 billion growing 5.3%. The money is moving into the category that just became unforecastable.
Three cases
D23.io. I run a managed Apache Superset service. Superset is Apache-licensed and costs nothing to acquire. Nobody has ever paid me for the software. They pay for version upgrades that do not break their dashboards, for someone answering the phone when a query melts a warehouse, for the security posture. The decision there was never about build cost, because build cost was zero. It was about who carries the run. That is the question the cost comparison never asks.
D30. I built forensic extraction over ASX annual reports myself rather than buying a data feed. Not because I could not buy one. Because the extraction path and the articulation gates are the product. Buying that layer means renting the only part a customer cannot get somewhere else, from a supplier who can reprice it annually. When a capability sits directly on your differentiated data, buying it hands someone else pricing power over your margin.
The support agent, priced out. Take 40,000 support conversations a year. At Agentforce’s $2 per conversation that is $80,000 before platform fees and before implementation. At Fin’s 99 cents per resolved outcome your cost depends entirely on resolution rate, which you do not know until you are live. At Zendesk’s committed $1.20 it is $48,000, if your volume matches the commitment you signed. Same capability, three cost curves, none of them modellable over three years without traffic data you do not have yet. Zendesk also absorbed its Advanced AI add-on into all Suite plans in May 2026, which moved the line again mid-year.
That is the cell that does not exist in the spreadsheet.
Where this breaks
The reversibility test is a luxury of small commitments.
If the capability is your system of record, nothing is reversible. Moving a general ledger, a core banking platform or a policy administration system is a two-year programme whichever way you originally decided, and for those, cost and vendor viability come straight back to the top of the list. Do not apply my test to a core system.
The bigger problem is the assumption underneath all of it: that build actually did get cheap for your team. METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real issues, on repositories they had contributed to for years, averaging over a million lines of code and 22,000 stars. With AI tools available, they were 19% slower. They had expected to be 24% faster. After finishing, they still believed AI had made them 20% faster.
That result should sit badly with anyone quoting the 67% figure, including me. On a mature codebase, with senior people who already hold the context in their heads, build cost may not have fallen at all. It may have risen while everybody felt quicker. If that describes your team, this thesis weakens a lot, and the honest move is to measure your own cycle time before you rearrange policy around somebody else’s survey.
What I would do on Monday
Pull twelve months of vendor invoices and compute variance, not average. Any line above 20% month-on-month variance has become a risk decision rather than a cost decision. Those are your first candidates to cap or bring in-house.
Write the exit paragraph before you sign. Ninety days, where the data goes, in what format, who does the work, what it costs. If nobody in the room can write that paragraph, you are not buying a tool. You are merging with a vendor.
Put a hard ceiling on every usage-priced contract, with a stop and not an alert. An alert tells you after the money has gone. Ask for the ceiling in the contract, in writing, and expect resistance.
For anything you build, name the person who owns it in eighteen months. No name, no build. What you have otherwise is a prototype and a future problem, and the New Relic firefighting numbers tell you who inherits it.
Run a licence utilisation report this week. If 36% is anywhere near right for you, you are already paying monthly for a buy decision that went wrong. That money is the budget for whatever you decide next.
Close
I went back to the model and deleted the cost comparison tab.
What replaced it is one column: days to undo this. Under 90, buy it and cap the term at twelve months. Over 90, it either touches the data that makes you money, in which case build it and own the path, or it does not, in which case put an agency on it under a six month cap and keep the repository in your own organisation.
The spreadsheet is smaller now. It is also the first version of it that survives contact with a pricing page.
Most of what I write about here started as a client problem. If you have one, bring it to me.