Build vs buy for enterprise AI
Use this framework to compare three-year ownership costs, switching costs, and the questions vendors may not address.
Build-versus-buy decisions usually happen component by component. Choosing the right level of detail matters more than a single overall verdict.
Framed as a program-wide choice, the question produces bad answers. "We will buy our AI" leads to a stack of tools that do not integrate and cannot be governed as one. "We will build everything" leads to a team reinventing infrastructure that was never a differentiator. The useful question is narrower: for this component, what is the right call?
Price the system you will actually run
Vendor pricing compares a subscription to a salary and declares buying cheaper. That comparison is usually wrong, because it prices the demo, not the production system. Build the three-year total cost of ownership for each option, including integration, monitoring, evaluation, support, and the cost of the seats and tokens at real volume. The picture often changes once the full system is in view.
The cheapest tool to adopt can be the most expensive one to leave.
Weigh the switching cost
A tool that is easy to adopt and hard to leave is a strategic liability. Before committing, ask what it costs to move off the option in two years: who owns the data, who owns the prompts and the fine-tunes, and how much of the integration would have to be rebuilt. The answer should weigh heavily: lock-in is a cost even when nothing goes wrong.
A simple heuristic
Build where the capability is a genuine differentiator for your business, where doing it better than competitors creates value. Buy where the capability is undifferentiated plumbing that someone else maintains better than you would. Most enterprise AI systems are a deliberate mix: a bought model, a built orchestration and governance layer, a bought vector store, a built evaluation suite tuned to your task.
Questions vendors hope you will not ask
- What happens to our data and our prompts if we leave?
- How do we evaluate quality independently of your dashboard?
- What is the real cost at our production volume, not the pilot?
- Can this run in our environment, under our controls?
The answers tell you whether you are buying a capability or renting a dependency.
Key takeaways
- Decide per component, not per program: most systems are a mix of build and buy.
- Price the three-year total cost of ownership, including the system you will actually run.
- Weigh switching cost heavily; the cheapest tool to adopt can be the most expensive to leave.
- Build where the capability is a differentiator; buy where it is undifferentiated plumbing.