When a business decides to use AI for something real, like claims processing, customer support, or forecasting, the first big question is usually framed as build vs buy AI. That framing misses the option that decides whether either one works: upskilling the people who’ll choose, integrate, and run the system.
This post gives business leaders a practical way to make the call, and explains why upskilling sits underneath both of the other options rather than beside them.
What the evidence says about build vs buy AI
In 2025, MIT’s Project NANDA published The GenAI Divide: State of AI in Business 2025, which looked at a few hundred enterprise generative AI initiatives. According to Fortune’s coverage of the report, buying AI tools from specialized vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded only about a third as often.
As reported in coverage of MIT NANDA’s 2025 study. Internal builds were described as succeeding about one-third as often
Source: Fortune, August 2025, reporting on MIT NANDA. The 22% is one-third of 67%, our calculation from the reported comparison.
Two cautions before you treat that as a verdict. The sample was small, and much of the commentary repeating it comes from vendors who benefit from the “buy” message. Still, the direction matches what many leaders see: internal builds often stall because the team is learning the technology and the business problem at the same time.
That’s the point. Buying succeeded more often partly because a vendor brings skills the company doesn’t have yet. If you build, you have to bring those skills yourself.
The three options, honestly compared
| Build | Buy | Upskill | |
|---|---|---|---|
| What it means | Your team designs and runs the system | You license a product and configure it | You train your people to choose, integrate, and govern AI well |
| Best when | The use case is a real competitive advantage, or your data can’t leave your environment | The problem is common across companies and good products exist | Always, alongside one of the other two |
| Time to first value | Slowest | Fastest | Weeks to months, depending on the role |
| Main risk | The project stalls before production | Lock-in, and a product that doesn’t fit your workflow | Training that isn’t tied to a real project |
| What it fails without | Engineers who can build and operate AI | People who can evaluate vendors and integrate the product | A use case to apply the training to |
The last row is why upskilling isn’t a third option you pick instead of the others. A purchased product still needs someone to judge whether its output is good enough, connect it to your systems, and decide where a human must review its decisions. A built system needs all of that plus the engineering.
Five questions to make the call
| Question | Leans toward build | Leans toward buy |
|---|---|---|
| Would a competitor gain from having the same tool? | Yes, it’s part of how you win | No, it’s back-office or common |
| Can the data leave your environment? | No, or only with heavy restrictions | Yes, under a normal vendor agreement |
| Does a mature product already do this? | No, or only partly | Yes, several |
| How soon do you need results? | You can wait two or three quarters | This quarter |
| Who will maintain it in two years? | You have, or will hire, a team for it | You’d rather the vendor did |
If your answers split, a common middle path is to buy a platform and build on top of it: use a vendor’s models and tooling, and build only the part that’s specific to your business.
What to upskill, and who
| Who | If you buy | If you build |
|---|---|---|
| Leaders who fund and approve AI work | Use case selection, vendor evaluation, governance | The same, plus realistic timelines and stage gates |
| Architects | Integration, security, and cost review of the vendor’s product | System design, platform choice, cost modeling |
| Product owners and managers | Acceptance criteria and evaluation of the product’s output | Feature scoping, evaluation design, human review rules |
| Engineers | Integration and configuration | Building, deploying, and operating the system |
Notice that leaders, architects, and product people need training either way. Only the engineering row changes much between build and buy.
Where AgileFever fits
We train people for both routes, so we have an interest in this question. Take that into account.
Our AI Transformation for Business Leaders course spends one of its nine modules on vendor and platform evaluation, specifically build vs buy vs partner. It’s 16 hours with no coding, currently $1,000 in the US or ₹65,000 in India. For architects, product owners, and engineers, the corporate AI training guide maps each role to a program.
Additional discounts are available. Contact us to know more.
FAQ
Is buying always safer?
No. Buying reduces the engineering risk but adds vendor risk: lock-in, pricing changes, and a product that does 80% of what you need. It’s safer only if you have people who can tell whether the product actually fits.
Should we upskill before choosing?
Train the decision-makers first, at least lightly. It’s hard to evaluate vendors or scope a build when nobody in the room can tell a good AI proposal from a weak one.
What about partnering with a consultancy?
It sits between build and buy. It can work well, but make sure the partner leaves knowledge behind, or you’ll be dependent on them for every change.
Further reading
For the organizational reasons AI projects fail, see AI Transformation for Business Leaders: The Complete Guide, which covers RAND’s 2024 research on the root causes.
