Guide · AI
Build, buy, or neither.
Most enterprise AI gets bought when it should be built, built when it should be bought, and started when it should wait. We have no platform to sell, so this call is honest. Here is the frame, and why most internal builds fail.
This guide, in 6 parts
Buy by default. Build the thin layer that is your edge.
The evidence points one way. Bought tools reach deployment far more often than internal builds, and most internal builds never show a measurable result at all. The default should be to buy.
The exception is narrow and it matters. There is usually one thin layer, sitting on top of bought tools, that encodes what actually makes you different. That layer is worth building and owning. Almost nothing else is.
And there is a third answer most frames leave out: do neither yet. When the process is broken or the data is a mess, building automates the chaos and buying scales it. The honest move is to wait and fix the ground first.
« Buy the commodity. Build the edge. Wait on the rest. »
The build, buy, or neither table.
Find the row that matches your situation. The marked cell is the call.
| Situation | Build | Buy | Do neither |
|---|---|---|---|
| A commodity capability everyone has (chat, summarise, transcribe, draft) | No edge to win | Mature tools, days to live | Only if there is no use case |
| A thin layer on top of bought tools that encodes your actual edge | This is the part to own | No vendor sells your edge | Not while it differentiates |
| No proprietary data, no in-house ML talent, no multi-quarter runway | Malpractice | Buy and learn first | Or wait for a real case |
| The model itself is the product you sell to customers | Own it, do not rent it | You rent your own margin | Not an option here |
| Vendor pricing scales per seat or per call against a thinning margin | Build to cap the cost | The bill grows with you | Renegotiate, then decide |
| The process is broken and the data is a mess underneath | Automating chaos | Buying chaos at scale | Fix the workflow first |
| Leadership wants AI but no one can name the number it moves | A build with no target | A licence with no target | Find the metric first |
● marks the recommended call. Scroll the table sideways on a phone.
Build, buy, neither: the short version.
If you read nothing else, read these three lists. Most decisions fit one of them cleanly.
When to build
- The capability is genuinely your competitive edge, and no vendor sells it.
- You have proprietary data, in-house talent and the runway to maintain it.
- The model itself is the product, or vendor pricing scales against your margin.
When to buy
- The capability is a commodity. Someone already sells it, mature, today.
- You lack the data, the talent or the runway to build and keep it alive.
- Speed to a measurable result matters more than owning the plumbing.
When to do neither yet
- The process is broken and the data is a mess underneath it.
- No one can name the number the AI is supposed to move.
- It is being done to look busy, not to change a result.
Three times building is malpractice.
These are the builds that produce the failure rate in the numbers above. Each is avoidable, and visible before any code.
It is a commodity capability
Chat, summarise, transcribe, draft, classify. The whole market sells these, mature and cheap. Building your own version is a multi-quarter project to land roughly where a subscription lands in a week, with no edge to show for it. You are funding a worse copy of something on the shelf.
You have no data, no talent, no runway
An internal build needs proprietary data to learn from, people who can maintain a model in production, and the budget to keep doing it long after launch. Missing any one of the three and you are not building a capability, you are building a liability that the original team leaves behind.
You are building only to own the IP
Owning the code is not the same as owning an advantage. If the only reason to build is so it is yours, you will spend the budget, miss the deadline, and end up with a system that does what a bought tool already did. Own the thin layer that is truly your edge. Rent the rest.
There is a cost trap underneath all three. Across industry analyses the software licence is only about a quarter to a third of the true total; integration, data work and upkeep are the rest. Treat that as directional, not gospel, but compare full cost to full cost when you decide.
Two times buying locks you in.
Buying is the default, not a reflex. In two specific cases, renting the capability quietly costs you the thing you were trying to protect.
The model itself is your edge
When the model is the product your customers pay for, renting it from a vendor means renting your own differentiation, on their roadmap, at their price, with their right to change both. The one place worth the cost and the risk of building is the place a competitor could not simply buy.
Vendor pricing scales against your margin
Per-seat or per-call pricing that looks fine in a pilot can grow into a tax on your own growth. If the bill rises in lockstep with the volume that makes you money, a bought tool quietly converts your scale into the vendor's revenue. At that point, capping the cost is a reason to build.
There is a second-order trap worth naming too: where the money goes. The biggest realised return tends to be in unglamorous back-office automation, yet over half of generative-AI budgets go to sales and marketing. Build or buy, point the spend at the work with a number on it.
Frequently asked.
Should we build or buy our enterprise AI?
Buy by default. The evidence is one-sided: bought tools reach deployment far more often than internal builds, and most internal builds never show measurable impact. Build only the thin layer that is genuinely your competitive edge, the part no vendor can sell you. Buy everything around it, and do neither yet if the process or the data underneath is not ready.
Why do most internal AI builds fail?
Usually for one of three reasons. The capability was a commodity, so the build only reproduced something already on the shelf. The organisation lacked the data, the talent or the runway to keep a model alive in production. Or it was built to own the IP rather than to win an advantage. None of those is a model problem. All three are decision problems, and they are visible before a line of code.
Is buying always cheaper than building?
Not always, and the headline price hides most of the cost. Across industry analyses the software licence is only about a quarter to a third of the true total. Integration, data work and ongoing upkeep are the rest. Buying is usually still the better bet, but compare full cost to full cost, not a licence fee to a build estimate.
When does buying lock us in?
In two cases. When the model itself is the product you sell, renting it means renting your own edge on someone else's terms. And when vendor pricing scales per seat or per call against a thinning margin, the bill grows with your success until it becomes a tax on your own scale. In both, capping that exposure is a real reason to build.
What if we are not ready to do either?
That is a legitimate answer, and often the right one. If the process is broken and the data is a mess, building automates the chaos and buying scales it. If no one can name the number the AI should move, neither path has a target to hit. Fix the workflow and the data, find the metric, then choose. Doing neither yet beats doing the wrong thing fast.
You can make this call yourself. Most teams can read the table and land the decision without help.
Bring us in for the hard middle: separating the thin layer worth building from the commodity you should buy, before either bill lands. Our Hub Map is how we draw that line on your stack. See the Hub Map.
We have nothing to sell you but the right answer, then the build. When buying is right, we will say so. See AI in production.
Build, buy, or neither?
No deck, no gate. A working session on your real stack, with the operators who would build or integrate it.