Your scientists were so preoccupied with whether they could
In Jurassic Park, Ian Malcolm delivers the line that every technology leader should keep on the wall. Your scientists were so preoccupied with whether they could, they never stopped to think if they should. It’s a good line to consider in build or buy AI.
The park worked on opening day. The gates opened, the fences held and the animals performed. Then one person triggered a security shutdown, no one knew how to fix it and it all fell apart.
In Blog 4 on orchestration I promised to come back to build or buy AI. The IT department often wants to build the orchestration layer itself. So let us take that seriously, because sometimes building is right.
Day one is the only day the build wins
Every build business case is written for day one. On day one, bespoke genuinely wins. The solution fits your process exactly, because you designed it around your process.
Then twelve months arrive. You want a new feature. However, the developers moved to the next priority, and there is no roadmap to join.
At twenty four months you want an integration. Meanwhile the platform underneath you has changed twice.
At thirty six months you find a bug. The person who wrote that module left the business two years ago.
You did not buy software. Instead, you took on a dependent.
There is a newer cost too. Build your own, and you inherit the token bill. Moreover, consumption is variable, hard to forecast, and usually nobody owns it. So you did not just take on maintenance. You took on a running cost nobody budgeted.
The maintenance nobody budgets
Here the research is unusually consistent. Organisations spend between 50% and 80% of a system’s lifetime cost after it goes live, not before.
Furthermore, budget roughly 15% to 25% of the original build cost every year just to stand still.
Now look at what that maintenance actually is. The classic Lientz and Swanson breakdown still holds. Only about 21% is fixing defects. Around 50% is perfective work, which means the improvements and small features people ask for. Another 25% is adaptive work, simply keeping pace with the platforms beneath you.
So three quarters of the cost is not bugs. It is change. Change is exactly what a build cannot promise you. Blog 5 on why implementations disappoint shows what that looks like in practice.
Abandonment is what that cliff looks like from outside. S&P Global found 42% of companies abandoned most of their AI initiatives in 2025. Meanwhile a year earlier that figure was 17%. Moreover, the average organisation scrapped 46% of its proofs of concept before production.
The market has already voted
Menlo Ventures surveyed around 500 US enterprise decision makers in 2025. In 2024, enterprises built 47% of their AI solutions and purchased 53%. By 2025, purchased use cases had risen to 76%.
So the build share fell by half in a single year. These are the organisations with the deepest engineering benches, and they stopped.
MIT’s NANDA research points the same way. Vendor led projects succeed roughly twice as often as internal builds.
Gartner puts numbers on the gap. Building a custom generative AI application runs to millions upfront. Buying runs to hundreds of thousands. Per user, the ongoing gap is wider still.
Zip’s 2026 research adds a sharper number. They surveyed 1,050 procurement, finance, IT and operations leaders at enterprises above 1,000 staff. However, only 17% could demonstrate clear ROI from AI. Among those deploying widely, 39% could. Meanwhile among those still piloting, only 6.5% could.
One word, two meanings
Zip calls its high performing group Builders. A group that sees 6x the return of the bystanders.
So does that contradict everything above? No. Their Builders are organisations that deploy AI deeply across their processes. It is not a measure of who writes their own software.
Therefore the two findings say the same thing. Deploy deeply, and buy the engine that lets you.
I have built the perfect solution
It works brilliantly, on Day One. In my IBM consulting days we built beautiful bespoke software solutions. They worked to solve complex client issues and delivered great value. The client signed off delighted.
Then six months later they asked for one new feature. However, the team had rolled onto the next engagement. The knowledge had walked out of the door.
Later IBM bought software companies. That is when the lesson landed properly. We were expert consultants. Nevertheless, we were amateurs at the ongoing development of enterprise software.
Building something once is a project. Keeping it alive for a decade is a completely different business. QA, software engineering, architecture, tech support and much more is needed to keep software or AI fit for purpose.
So what is your company actually for?
Here is the question that decides it, and it is not a technology question.
If the intelligence itself is your competitive advantage, build. Perhaps the intelligence is in your model, your proprietary data or your way of reasoning. Key differences that customers pay for. Further peel back the model to find the real differentiators. Those, you want to lock away so your competitors cannot also buy. Then build has a strong case.
However, if your edge is bespoke customer solutions, category expertise or delivery, then think hard. Building the engine means quietly funding a software company you never intended to run.
Even where building AI locks competitive differences, ask how much of the model is genuinely yours. Often it is 10%, and the other 90% is generic.
The option nobody names
There is a third path, and it is the one IT usually proposes. Build it on the platform we already own.
That sounds like buying. However, it is building, with a head start. You still write the intake routing, the approval matrix, the risk tiering and the three way match exceptions. The platform gives you a workflow engine. Meanwhile the procurement logic is still yours to build, and yours to maintain.
So apply the same test. Who owns that configuration in three years? Furthermore, a generic platform usually needs permanent functional specialists to translate procurement into it. One practitioner puts that at two to three full time roles.
The test I would apply
First, ask whether customers pay you for this capability. If not, buy it.
Next, ask who owns it in three years, by name and by budget line. Silence is your answer.
Then ask what happens at the next platform change. Someone must absorb it.
Finally, consider the middle path, sometimes called buy to build. Buy the engine, then build your advantage on top of it, inside guardrails you govern.
Ultimately, most procurement functions drive real profit growth from the cost line. Whilst we desire to and sometimes do support the revenue line, sales normally do that better. It does steer you to think procurement should buy the orchestration and build the judgement.
Wondering whether to build or buy AI in your environment? No slides and no pitch. Book a virtual coffee with me: pdigweed@spvalue.com.au.
This is The Hollywood Procurement Blogs S1 E7. Material created by Paul Digweed with support by AI team member.
External Links to references: Menlo Ventures, 2025: The State of Generative AI in the Enterprise | Menlo Ventures
Zip, The State of AI in Spend 2026, 1,050 leaders at enterprises above 1,000 staff, published 23 July 2026, https://zip.com/resources/state-of-spend.
S&P Global Market Intelligence via CIO Dive: AI project failure rates are on the rise, https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/.
Art of Procurement: The State of AI in Procurement: Who is Getting the ROI? https://artofprocurement.com/blog/podcast-the-state-of-ai-in-procurement-whos-getting-the-roi.
Pure Procurement, Purpose Built Procurement Tools Always Win the Build vs Buy Debate, https://newsletter.pureprocurement.ca/p/why-purpose-built-procurement-platforms-win-every-time (sponsored by Oro Labs)