Should we build our own AI or buy it? How do I decide?

"Our engineers want to build it themselves and the board wants to buy something off the shelf, and both of them are looking at me to settle it without any of us really knowing the trade-off." That is the sentence behind half the AI stand-offs landing on a chief executive's desk this quarter. Two capable groups, one open question, and you cast as the tie-breaker on a call none of you has the data to make with real confidence.

Here is the short answer, before the meeting reconvenes. Build versus buy is the wrong axis to argue, because the technology can be built either way; the question that decides whether the thing survives contact with your business is where your organisation can carry the load once it launches. Buying tends to win on speed and on odds. Building wins where the capability is your edge and you can resource it for years, not for a quarter. Choose by ownership, not by who holds the strongest opinion in the room.

Why does the build-vs-buy AI decision keep stalling at my desk?

Because it is being framed as a contest of competence, and competence is not the constraint. Your CTO is right that the team could build it. Your board is right that something off the shelf would ship faster. Both are arguing about the engineering, and neither is arguing about the part that actually decides the outcome: whether anyone adopts and governs the thing after it ships.

The market has already made this call for you. Menlo Ventures' 2025 State of Generative AI in the Enterprise report, which tracks where enterprise AI spending actually goes, found that 76% of AI solutions are now purchased from specialists rather than built internally, a reversal from a year earlier when the split sat at roughly 47% built and 53% bought. When the people spending the money shift that far, that fast, they are telling you something about where the difficulty really lives.

And the cost of leaving the question open is measurable. A 2025 survey of 250 senior product and engineering leaders by A.Team with Riviera Partners (a US executive search firm that places technology leaders) found that while 67% expected AI to transform their organisation, only 36% had a defined vision for getting there and only 36% had reached production. The rest sat in what the researchers called prototype purgatory. The debate itself is the failure mode.

Does buying actually beat building, or is that just the safe answer?

It is not the safe answer. It is the better-odds answer, and the gap is wider than most boards assume.

MIT's 2025 study of enterprise AI, drawn from 150 leader interviews, a survey of 350 employees and analysis of 300 public deployments, found that buying tools from specialised vendors and building external partnerships succeeded about 67% of the time, roughly twice as often as building it in-house. Read that twice. The same body of work is where the now-familiar figure comes from: about 95% of enterprise generative AI pilots delivered no measurable impact on the profit and loss account, and only about 5% achieved real revenue acceleration.

This is the bit your engineers will resist, so frame it plainly. The vendor advantage is not because external code is better. It is because a specialist has already absorbed the hard part, the failure modes, the edge cases, the governance scaffolding, across many deployments before yours. When you build in-house, you are paying to learn all of that for the first time, on your own clock, with your own customers as the test set. That is a price worth paying where the capability is your competitive edge.

So when does building it ourselves become the right call?

When the capability is the thing customers come to you for, and when you can resource it as a permanent muscle rather than a project. For almost everyone else, the data points toward a blended answer. Gartner's 2025 survey of 782 infrastructure and operations leaders found that only 28% of AI use cases fully met their return expectations, and that the most common reason given for failure was expecting too much, too fast, ahead of weak data and ahead of the model itself. Translation: the projects break on pace and people, not on engineering. A.Team's research with Riviera Partners points the same way: blended teams, specialist external talent working alongside your own people, were twice as likely to reach the advanced stages of AI maturity.

So the strongest position is rarely pure. Buy the commodity layer from a specialist who has already paid the learning cost. Aim your scarce, expensive engineering talent at the workflow redesign and the proprietary advantage that no vendor can hand you, because that is where the durable value sits. The bottleneck is no longer the technology. The real question is whether your organisation can adopt, govern and keep alive whatever you install.

How do I actually run the decision this week?

Take it off pride and put it on ownership. Walk the room through these in order.

1. Name the capability with precision. Is this the thing customers choose you for, or is it plumbing that everyone needs and no one differentiates on? Plumbing gets bought.
2. Locate the real work. Map who owns the workflow redesign, the governance and the adoption for the next two years. If you can name those owners today, you are ready to build; if you cannot, building is a longer commitment than the room thinks.
3. Price the maintenance, not the build. A build is cheap to start and expensive to keep alive. Ask what it costs to staff this in year two, once the launch team has dispersed.
4. Run the blend. Buy the commodity layer, and reserve your own engineers for the proprietary edge. This is the position the maturity data rewards.
5. Decide who keeps it coherent. Name the single accountable owner for governance and outcomes before you sign anything. That role is the real difference between the 5% and the 95%.

Settle it on that footing and the meeting stops being a contest. Your engineers keep the work that makes them proud and gives you an edge. Your board gets the speed and the odds it wanted. And you hold a frame you can defend at the next board meeting, because it is built on where the value actually comes from, not on who argued hardest.

About the author

Thomas Green

British technology futurist, AI keynote speaker and advisor. Thirty years across enterprise technology and AI strategy, helping leaders navigate the future of work. The futurist who died.