Build vs buy vs partner for AI capabilities
Buy when the capability is common across companies and a product already does it well, like meeting notes or general coding assistants. Build when the capability differentiates your business and depends on your data and workflows, and you have people to run it for years. Partner when you need it specific to you but don't yet have the team, and make knowledge transfer part of the deal.
Common mistake
Companies build commodity tools in-house and buy generic tools for their core differentiator, which is the wrong way round. A custom meeting summariser costs engineering time every month, while an off-the-shelf one costs a licence.
What the research says
MIT NANDA's 2025 research, as reported by Fortune, found purchased tools and partnerships succeeded about 67% of the time, and internal builds about a third as often. Internal builds still make sense for your differentiators, as long as you have the people to run them after launch.
Decision questions
| Question | Points to |
|---|---|
| Does every competitor need the same thing? | Buy |
| Does it depend on our proprietary data or workflow? | Build or partner |
| Do we have people to run it in production for years? | Build |
| Do we need it in 3 months? | Buy or partner |
| Is it regulated and must it stay on-prem? | Build, or partner with on-prem expertise |
| Does an existing product already solve it and work with our systems? | Buy, and don't build a custom agent |
Building has a running cost
A custom system needs monitoring, model upgrades, eval maintenance and someone on call. Building something to learn is different from building something a company has to pay to maintain, so for a company you have to justify owning the implementation.
Partnering well
- The partner builds with your team, not for them.
- Your engineers review code and own deployment.
- Documentation, evals and runbooks are deliverables.
- A clear exit: what happens when the contract ends.
Check your list
Classify your top ten AI needs as buy, build or partner, with a one-line reason each, and look for anything you're building that a product already does.
From the floor
A company can make the right AI decision and create no work for an AI engineer: if an existing product already solves the problem, works with their systems and meets the requirements, there's no reason to build a custom agent. In consulting, the valuable part is sometimes telling the company they don't need a custom AI project, even when you could have sold one, and asking yourself honestly whether you're recommending an architecture because the problem requires it or because it's what you sell.
Related
- Vendor evaluation scorecard
- Cloud APIs vs open-source LLMs
- Structuring an AI team
- ROI and cost estimation