Build vs Buy AI: What UK Mid-Market Companies Should Build in 2026 (and What They Should Not)
76% of enterprise AI use cases are now bought rather than built, up from 53% a year earlier. Yet 78% of builders expect to build more in 2026. Both are true. Here is how to sort your own list into four buckets.
By Ivan Pylypchuk, CEO of SoftBlues
76% of enterprise AI use cases are now bought rather than built, up from 53% a year earlier (Menlo Ventures, December 2025). The same year, a survey of 817 builders found 35% had already replaced at least one SaaS tool with something they built themselves, and 78% expected to build more in 2026 (Retool, February 2026).
Those two numbers point in opposite directions, and both are true. Companies are buying their AI capability and building their own software on top of it. So the useful question has moved on from build or buy to something more specific: which layer do you buy, and which layer has to be yours?
The short answer for a UK mid-market company: buy the model and the assistant, build the workflow that encodes how your business actually works, and be honest about the third option, which is leaving a process alone until it is worth touching.
Key facts
Why has the buy side won so decisively?
Because the thing most companies were going to build got commoditised while they were writing the business case. In 2023 a lot of mid-market firms sketched plans to fine-tune their own model on their own documents. By 2025 a general-purpose assistant with a connector to their document store did the job better, cost a licence fee, and worked on the Tuesday you bought it.
That is the honest reason for the swing from 47% built to 24% built in a year. Not a loss of nerve. The available product got good enough that building the same thing became an expensive way to arrive second.
What has not been commoditised is your process. No vendor knows that your quotes need a director's approval above £40,000, that three of your largest customers have bespoke reporting formats, or that your month-end depends on a spreadsheet one person maintains. That knowledge is the part worth building around, and it is also the part that makes generic tools feel almost right and never quite right.
What are the four buckets, and how do you sort a capability into one?
Every candidate falls into one of four, and the mistake is treating everything as bucket three.
Buy it when the workflow is common to every company in your sector and a mature vendor already sells it. Payroll, e-signature, expense capture, transcription. You will not out-build a company whose entire business is that one problem, and you should not want to.
Configure it when a platform gets you most of the way and the remaining distance is settings, prompts and connectors rather than code. This is where most Claude and Copilot work sits, and it is the biggest bucket in a mid-market company. It looks like buying on the invoice and like building in the effort it takes to do well.
Build it when the capability depends on data or judgement that only exists inside your business, and when getting it right changes your economics. A pricing engine that reflects how you actually quote. A triage workflow that knows your service levels. These are small, specific builds on top of a bought model.
Leave it when the process is annoying but rare, or when the volume does not justify the maintenance. This bucket is real and almost never used. A workflow that runs eleven times a year does not need automating, however irritating those eleven times are.
How do you decide? Four questions, in order
1. Is this a differentiator or a utility? If a competitor could buy the identical capability tomorrow and it would not change your position, it is a utility. Buy utilities. Build differentiators. Most companies get this backwards, buying the thing that makes them distinctive and building the thing that does not.
2. Does the value depend on data a vendor cannot see? Your ten years of quotes, your engineer notes, your dispute history. If the answer is yes, the workflow around that data is a build, even if the model underneath it is bought.
3. What happens when the person who built it leaves? This is the question that kills more internal builds than cost ever does. A tool that only one person understands is a liability with a productivity gain attached. If you cannot answer it, buy instead, or build with someone who will document and hand over.
4. Can you leave it for another six months? Sometimes the answer is yes, and that is the cheapest decision available. The vendor landscape is moving quickly enough that waiting two quarters occasionally turns a build into a purchase.
What does each route actually cost?
Comparing a licence fee to a build cost is the classic error, because the licence recurs and the build has a tail. The shapes are different, so compare shapes.
| Route | Best for | Avoid if | Cost shape |
|---|---|---|---|
| Buy a point solution | A common workflow with a mature vendor and a clear owner internally | You will need three of them and they do not talk to each other | Per-seat monthly licence, low setup, rises with headcount |
| Buy a platform and configure it | Broad assistant use across several departments, where the win is adoption not code | Nobody owns configuration, so it becomes an expensive chat window | Per-seat licence plus real internal effort on prompts, connectors and training |
| Build on a bought model | One or two workflows where your data and rules are the advantage | You have no internal owner and no appetite for maintenance | Project cost once, then model usage and ongoing upkeep |
| Build from the ground up | Almost nobody in the mid-market | You do not have an ML team and a reason it must be yours | High and open-ended. If you are considering this, get a second opinion |
Put numbers on it before you decide. Our AI total cost of ownership breakdown sets out what UK mid-market companies actually spend across licences, integration and internal time, and how to measure the ROI of an AI implementation covers the return side.
What about the software people are already building without asking?
Take it seriously. 60% of surveyed builders wrote software outside IT oversight in the past year (Retool, February 2026). In a mid-market company that usually means an operations manager with an AI coding tool has quietly built the thing procurement was still evaluating in March.
Two facts about that software. It often works, and it is usually unreviewed. AI-generated code carries a known security profile, which is why we wrote about auditing code written by AI before you scale it. We ran exactly that exercise for a food producer whose customer-facing app had been AI-built, and the code audit case study is the honest version: an audit and a rebuild proposal, not a finished deployment.
The productive response is a governed path rather than a ban. Say what people may build, what has to be reviewed before it touches customer data, and who reviews it. Our AI governance guide has the one-page version.
Where we land, and where we would tell you to buy
We build on Claude rather than from scratch, and we say no to builds fairly often. If your requirement is a general assistant for a hundred knowledge workers, the answer is a licence, a configuration project and a proper adoption programme, not custom software. If your requirement is one workflow where your own data and rules decide the outcome, that is worth building, and it is usually smaller than people expect.
We run our own company this way. Six of our departments operate on Claude with a set of internal skills and connectors we built ourselves on top of a bought platform, written up in our Claude operating system case study. We use it before we sell it. The proportion is roughly what we recommend to clients: buy the platform, build the thin layer that is genuinely you.
If you are not sure which side of the line your idea sits on, run it as a proof of concept first. A three-week test costs less than a wrong six-month build.
Frequently asked questions
Is building a custom AI tool still expensive in 2026? Less than it was, which is why the Retool respondents expect to build more. AI-assisted development has cut the cost of the first working version substantially. What has not fallen is the cost of maintenance, security review and handover, and that is where build budgets actually go.
If 76% of use cases are bought, why build anything? Because the 24% that get built are frequently the ones tied to how a company makes money. The split is not a verdict on quality. It reflects that most AI use cases are ordinary, and ordinary work should be bought.
We already pay for Microsoft 365. Should we just use Copilot? Quite possibly. If your data lives in SharePoint and Teams and your requirement is drafting and summarising inside those tools, Copilot is the shortest path and we will tell you so. The case for Claude gets stronger when the work involves long documents, mixed systems and workflows you want to shape yourself. We compared them in ChatGPT Enterprise vs Claude Enterprise vs Microsoft Copilot.
How do we stop a build becoming shelfware? Name an owner before you start, and set one number it has to move. Most abandoned internal tools were never anybody's job after launch. The pattern is covered in why companies buy AI and nobody uses it.
Can we start by buying and build later? That is usually the right sequence. Buy the platform, watch which workflows people bend it into, and build the two that clearly resist configuration. You get evidence instead of assumptions, and you find out whether adoption is real before you commit to a build.
What is a realistic timeline for a build on a bought model? We work to 90 days from start to production for a defined workflow, at a fixed price, with money back if it does not make it. Anything materially longer than that in a mid-market context is usually a scope problem rather than an engineering one.
Who should own this decision internally? Whoever owns the process, with the CFO on cost and IT on security. If the decision sits with IT alone you tend to get technically sound tools nobody wanted. If it sits with the business alone you get the 60% shadow-build figure.
Does an AI vendor count as a supplier we need to assess? Yes, and the assessment is not the same as for ordinary SaaS. We publish the questions we would send in the AI vendor security questionnaire every UK buyer should send.
We are a registered Anthropic Partner Network member and a Google Cloud partner, working with UK and Ireland companies that have 50 or more knowledge workers. We deploy in 90 days at a fixed price, with a money-back guarantee if it does not reach production, and we will tell you when the right answer is a licence rather than a project. More on how we approach it on our business automation page.
Fewer spreadsheets, more thinking. Book a call.
See it in production
Systems we have built and run for clients, with the numbers that came out of them.
Related Articles
Shadow AI at Work: What UK Companies Should Do About Unapproved AI Tools
AI-Built Apps: How to Audit Code Written by AI Before You Scale It
