Buy the commodity, build the moat

In October 2025 the UK government's AI incubator, i.AI, announced it was turning off Redbox, a tool it had built itself and that more than 6,000 civil servants¹ had used. Redbox let officials chat with documents. It ran on rented models, hosted on Azure with GPT-4o as the default², and if you preferred a different one you could pick it. Then Microsoft's Copilot chat became free across departments, and it "offered similar functionality"¹, as the incubator put it. The Cabinet Office moved to Gemini. Redbox was shut down, and what remained was the open-source code, which the team called "an asset" and which others have since forked.

Told as a story about buying versus building, that is a build that lost to a buy. I don't think that's what happened. An AI system is four things: the model, the infrastructure it runs on, the workflow built around it, and the data and evaluation that make the workflow yours. Redbox rented the model, which is why it could be swapped, and it was. What Redbox owned was the workflow, and that workflow was general chat, the one job a product was always going to sell to everyone. The build didn't fail. It owned the wrong layer. What outlasted it was the code and what the team learned, and that is worth noticing, because it tells you which layers survive contact with the market and which don't.

Procurement people have a term for the thing this article is about: switching cost, the money, time and retraining it takes to move from one supplier to another. Ask what the switching cost is at each of the four layers and the buy or build AI question mostly answers itself.

Where the cost of leaving really sits

At the model layer it is close to zero, and falling. Stanford's AI Index puts the price of a fixed level of capability, what a good model could do in late 2022, at more than 280 times³ less two years later. The prices themselves move at the vendor's convenience: in one month this summer OpenAI cut a flagship model by 20% on input and 33% on output⁴ for at least three months, and Anthropic cancelled a scheduled 50% rise⁵ three weeks before it was due. So a rented model is cheap, getting cheaper, and unpredictable, and none of that matters much, because it is the one part of the system you can swap by changing a setting. Redbox's default was a setting an administrator could change². The people who worry about being locked into a model vendor are worrying about the easiest layer to leave.

The layer below is another matter. In July 2025 the Competition and Markets Authority finished its investigation into cloud services and concluded that competition is "not working well"⁶. Fewer than 1% of customers switch provider in a year. The fees for moving data out, and the technical differences between clouds, "lock customers into their initial choice of provider"⁶, in the regulator's words. Its investigation team recommended binding rules for Microsoft and AWS. In March 2026 the CMA's board decided against that⁷ and accepted the two companies' own undertakings instead, with a review in six months. So the finding stands, and the remedy is a promise. Both companies are American. The regulator is British. If you are a UK buyer, the promise is what you're relying on, and every model you rent runs on somebody's cloud.

And there is a newer switching cost that the CMA's investigation was too early to see. Leaving a system used to mean migrating a database. Increasingly what makes an AI system useful is what it remembers: how you work, what you've corrected, the tools and habits built up around it. Much of that lives inside the vendor's product, and it is what the product learns from. "We don't train on your data" may well be true of the underlying model. Your prompts, your workflows and the way your people use the thing can still make the product better, for the vendor and for everyone else who rents it. It isn't only companies, either. If you have built your working habits into your employer's ChatGPT subscription, ask yourself what you'd be able to take with you.

Build the part that's yours

None of this is an argument for building everything. The two most quoted studies on the question point the same way once you read what each measured. MIT's Project NANDA found in 2025 that AI tools built with an outside partner reached deployment about 67% of the time⁸, against about 33% for tools built entirely in-house, and said itself that the figures were self-reported and did not prove causation⁸. McKinsey's survey this August found that 32% of organisations⁹ had decided against buying at least one piece of software because coding agents let them build it, and that about 20%⁹ already found AI running costs, tokens included, a constraint. More companies are building. The ones that get value are not the ones building everything. They are building the part that is specific to them on parts that are not.

Here is what that looks like in my own business. An agent runs our bookkeeping and payroll. On a schedule it checks the bank, finds the matching receipts and invoices in our email, reconciles them and keeps Xero up to date. At month end it produces the accounts and prepares the payroll, and a person approves at the points that matter: logins, checks, submission. None of the parts are special. Xero, HMRC's payroll software and the bank are things anyone can use. What's ours is the workflow that ties them together, the checks inside it, and the tests that tell us it still works when we change the model underneath. That is a small moat, and it is made entirely of commodity parts.

One thing about it breaks my own rule. The model runs on our hardware, not a vendor's, because payroll data is the kind you don't send out, and because a model you run yourself is a fixed cost rather than a bill that grows with every token. Not cheaper, necessarily. Predictable. It is the one case where the model stops being a commodity and moves inside the moat, and I suspect it will become more common as the token bills do what the CMA found the cloud bills doing.

The government's own teams, as it happens, have arrived at the same shape. i.AI's Consult tool, which analyses public consultation responses, keeps its own test suite¹⁰ and runs it across whichever models are available, so the team can tell whether swapping the model made things better or worse. Own the tests, rent the thing being tested.

A peer of mine, who has to present on this to clients, asked a group of us last week for "some sort of framework or decision tree to help the customer think about the right things in the correct order". I don't think it needs a framework. It needs one question, asked of every layer and of every supplier before anything is signed: what are we left holding on the day they leave? If the answer at the model layer is "a config change", rent it. If the answer at the cloud layer is "our data, at a price they set", know that before you sign, because the regulator has told you it will not be setting the price for you. If the answer at the workflow layer is "a process we rely on and cannot run, and the decisions it now makes for us", then the contract has created a dependency nobody chose. That is true whether you bought the product or paid a consultancy to build it, which is the same thing with the invoice relabelled unless your own people can change what was built once the contractors have gone. An earlier post on the NHS's ambient voice technology contracts follows one such dependency to the point where it bites, which is renewal.

Boards are under real pressure to approve all this, and I understand why. But a bundled AI product is a set of answers to those questions, made by someone else, on your behalf. What's actually in it? What does the vendor learn from how we use it? Where does our know-how end up living? A board that cannot answer those isn't making the decision. It is inheriting one.

Buy the commodity. Build the moat. And whichever you choose, know what you're handing over.