The Data Settled the Argument and Named the Exception
Two years ago, every capable engineering team wanted to build its own AI.
The market changed its mind in one year. Menlo Ventures, surveying close to 500 enterprise decision-makers, found 76% of AI use cases purchased rather than built in 2025, up from 53% the year before. Buying overtook building faster than any procurement shift in recent software history.
The reason is not fashion. It is completion rates.
What the Failure Data Shows
MIT’s NANDA study of enterprise deployments found that vendor-led builds reached production roughly 67% of the time, against about a third for systems built entirely in-house. Two teams, same budget, same models, and one of them is twice as likely to finish.
RAND puts overall AI project failure near 80%, about double the rate of conventional IT work.
None of this says internal engineers are weak. It says the failure lives in a place engineering skill does not reach: the corpus, the integrations, the evaluation loop, the operating budget, the authority to change how people work. Vendors who have shipped this before arrive holding those pieces. Internal teams assemble them once, slowly, on a live business.
Building is cheaper right up to the moment it takes fourteen months.
When Each Answer Is Correct
The decision is not a philosophy. It is four tests.
| Buy when | Build when |
|---|---|
| The workflow looks like everyone else’s | The workflow is the differentiator |
| Your data resembles industry-standard records | Your data is proprietary and hard to replicate |
| Speed to production decides the value | Control of the system decides the value |
| A vendor already runs it at scale elsewhere | Residency, regulation, or sovereignty rules block a vendor |
| The capability is table stakes by 2027 | The capability is the reason customers choose you |
Read down the left column. Most requests land there. Buy those, cleanly, and spend the saved months on the one or two systems in the right column that actually separate the business.
Companies that got this backwards paid for it. The pattern is well documented: a custom build starts before anyone validates the use case, and roughly a year of engineering time disappears into a system the business never adopts.
The Third Answer
The framing hides the option most enterprises actually need.
You do not build a model. You do not buy a system. You buy the parts and assemble the system around your workflow.
- Buy the model. It is a commodity. Building one is a decision about capital, not capability.
- Buy the components. Vector storage, orchestration, observability, evaluation tooling. All of it is mature and none of it differentiates you.
- Build the connective layer. The mandate, the corpus, the integrations, the review loop, the operating plan. That layer is specific to your company and no vendor sells it.
Nothing in the bought stack knows your invoice rules, your escalation paths, or the twenty-year-old database your operations run on. That knowledge is the system, and it stays yours. As the documentation layer argued, most of it starts as structured text long before anyone writes code.
Assembly is the work. It is also the part that survives your next vendor change.
Four Questions Before You Commit Either Way
- Can we name a vendor already running this workload at our scale
- Does this workflow differentiate us, in a sentence a customer would recognise
- Do we own a corpus a competitor cannot assemble
- Does a regulator, a contract, or a residency rule prevent us from buying
Four yes answers on the right-hand side justify a build. One or none, and the honest answer is to buy and assemble. Most companies asking the question have already answered it and are looking for permission to build anyway.
Buy the Parts and Build the System
The build-versus-buy argument was really an argument about where advantage sits. It does not sit in the model, which is priced the same for everyone. It does not sit in the tooling, which is a subscription.
It sits in the assembly, the fit to your operation, and the discipline to keep the thing running after launch. Buy everything that a competitor could also buy. Build the layer that only you can.
Software is only the surface. Infrastructure is the rest.
Build there.
ORKA Briefings are strategic readings on the systems shaping AI in Canada. Source data: Menlo Ventures, 2025 State of Generative AI in the Enterprise; MIT Project NANDA, The GenAI Divide, 2025; RAND Corporation. ORKA AI builds the assembly layer and stays to run it. To scope a build against a buy, open an inquiry.
