Written by Gowtham Raj, Director at TartLabs, who leads AI development services and custom software engagements for manufacturing, logistics, and enterprise clients.
The Short Answer
Buy anything that many companies need in the same way. Build only where the AI touches your own data, your own workflow or your own competitive edge. In our experience most companies end up doing both, and the useful question for each use case is which side of that line it falls on.
The market has already moved. Menlo Ventures' 2025 report, based on a survey of 495 U.S. enterprise AI decision-makers fielded in November 2025 and published in December, found that 76% of AI use cases are now purchased rather than built internally. The five tests below help you decide whether a given project belongs in that 76% or in the smaller group worth building.
Key Takeaways
- 76% of enterprise AI use cases are purchased rather than built, according to Menlo Ventures' 2025 report, based on 495 U.S. enterprise decision-makers surveyed in November 2025.
- MIT's NANDA research, as reported by Fortune, found that purchased tools and partnerships succeed about 67% of the time, with internal builds succeeding about a third as often, in Fortune's wording.
- Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls.
- Run five tests per use case: differentiation, data, speed, team and total cost. In our experience, portfolios split into buy, build and blend.
What Companies Are Actually Doing
Menlo Ventures reports, from 495 U.S. enterprise decision-makers, that in 2024, 47% of enterprise AI solutions were built internally and 53% were purchased. In 2025 the purchased share of use cases reached 76%. Menlo also estimates enterprise generative AI spending at $37 billion in 2025, up from $11.5 billion in 2024.
Two cautions apply. Menlo's 2024 figure counts "solutions" and its 2025 figure counts "use cases," so the jump from 53% to 76% overstates the shift somewhat. And the sample is U.S. enterprises, so a mid-market company in India or Europe may sit elsewhere. The direction is still clear: most organisations now start by looking for something to buy.
The outcome data points the same way. MIT's NANDA study, as reported by Fortune in August 2025, found that "purchasing AI tools from specialized vendors and building partnerships succeed about 67% of the time," while internal builds succeed about a third as often. Fortune's coverage says the research drew on 150 leader interviews, a survey of 350 employees and an analysis of 300 public AI deployments.
Read that result with care. The same study's headline claim, that 95% of pilots deliver no measurable return, drew wide debate. Our reading is that vendors may also be handed the better-defined projects, which would flatter the buy numbers. We use the comparison as one directional signal and do not treat it as proof that buying always wins.
Buying has its own failure mode. Gartner's June 2025 warning on "agent washing" says many vendors rebrand chatbots, assistants and RPA as agentic AI, and estimates only about 130 of the thousands of agentic AI vendors are real. Buying well takes as much diligence as building well. Our guide to choosing an AI development partner covers the questions to ask.
Five Tests for Each Use Case
Run these per use case, never per company. In our experience an organisation builds a few use cases and buys many.
1. Differentiation: would a competitor gain from the same tool?
If a rival could buy the identical product tomorrow and get the same benefit, you have no reason to build it. Meeting summaries, email drafting, generic coding assistants and standard support deflection fall here. If the value comes from something only you have, such as proprietary process data or a pricing model refined over a decade, building has a case. Our view: if you cannot name what is unique about the use case in one sentence, buy.
2. Data: does the value depend on your own data?
A bought product is as good as the data it can reach. If it needs deep access to your ERP, your field-service records or your claims history, check how much integration it requires and who does that work. In our experience, heavy integration with messy internal data tends to turn "buy" into "buy and customise," which has build-level costs. Our guide on why legacy systems block AI adoption covers that integration work in detail.
3. Speed: how soon does this need to work?
In our experience a purchased tool can usually be piloted within weeks. A custom build needs data preparation, evaluation, security review and integration before it earns trust. If the business needs a result this quarter, that favours buying, even when the long-term plan is to build. A common route is to buy first, learn what the workflow really needs, then build the part that proved valuable.
4. Team: can you run it after launch?
Building commits you to maintaining it. Models change, costs shift, prompts drift and evaluation sets go stale. Ask whether you have, or can hire, people who will own monitoring, retraining and incident response for years. If the honest answer is "a contractor will hand it over and leave," plan the handover and run costs before you start. See our post on how many engineers you need now that AI writes the code for sizing that team.
5. Total cost: have you priced three years, not three months?
Compare subscription or usage fees against build cost plus run cost, and count integration, security review, monitoring and the engineers' time on both sides. Buying looks cheap per seat and can get expensive at scale. Building looks expensive up front and can become cheap per transaction at volume. The right comparison is cost per outcome over three years. These cost shapes come from our delivery experience, not from a published benchmark, so test them with your own numbers.
How the Tests Add Up
| If your use case... | Lean toward | Why |
|---|---|---|
| Is generic and common across industries | Buy | No edge from building; vendors spread their cost over many customers |
| Needs light integration and a fast result | Buy | A pilot in weeks beats a build in months |
| Depends on proprietary data or process | Build or blend | The value sits in your data, not in the model |
| Is core to how you compete | Build | You want control of roadmap, data and economics |
| Has strict data residency or compliance rules | Build or blend | Control over where data and models run |
| Is new and poorly understood | Buy first | Learn the workflow before committing to custom code |
The Blend: Buy the Platform, Build the Layer That Matters
In our view the most sensible answer is usually a hybrid. Buy the foundation model access, the infrastructure and any commodity tooling, and build the orchestration, the data connections and the evaluation that reflect how your business works. Our experience is that this keeps the differentiating logic in your hands and leaves the commodity parts to vendors who maintain them.
Three habits keep a blend healthy:
- Keep the seams clean. Put a thin interface between your own logic and any vendor so you can switch providers without a rewrite.
- Own the evaluation set. A set of real cases with agreed right answers is yours regardless of which model or tool you use, and it is the quickest way to compare options.
- Write down the exit. Know what happens to your data, prompts and fine-tuned assets if you leave a vendor.
For the wider planning picture, including where this decision fits into an AI roadmap, see our AI strategy guide for software companies.
Mistakes We See Leaders Make
These are our own observations from client work.
- Deciding once for the whole company. Build-versus-buy is a per-use-case decision, and a blanket policy in either direction wastes money.
- Treating a demo as proof. A vendor demo uses clean data. Ask for a trial on your own data before you commit.
- Underpricing the run. Teams budget the build and forget monitoring, retraining, support and cloud costs that continue every month.
- Building to prove a point. In our experience, "we have a strong engineering team" is a poor reason to build something a vendor already sells well.
- Buying without an exit. Lock-in is cheap to avoid at the start and costly to fix later.
The Bottom Line
Build-versus-buy is a per-use-case choice. Buy what is common, build what is yours, and blend the rest with clean seams and a written exit. The market is already leaning toward buying, with 76% of use cases purchased in Menlo's 2025 survey, so the burden of proof sits with the build.
If you would like a second opinion on a specific use case, or help running these five tests on your own portfolio, get in touch or read our AI strategy guide first.
