Should regulated industries build more in-house?

Counterintuitively, no — over-building is a top failure mode in regulated sectors. Buy commodity capability from vendors with the right controls, and build only the compliance-aware workflow layer that's specific to you.

What's the biggest build-vs-buy mistake?

Building the foundation model layer or generic orchestration in-house "for control," then buying a generic workflow product that doesn't fit — exactly backwards.

How does this affect cost?

Renting commodity layers keeps fixed cost low and lets you switch as models improve; concentrated build effort on the moat is where spend actually compounds into advantage.

Isn't relying on a vendor a lock-in risk?

The bigger lock-in is to your own legacy build. Renting commodity layers behind a clean internal interface keeps you free to switch providers as the market moves; your moat — data and workflow — stays yours.

← Guides

guides 10 June 2026 2 min read

Build vs. buy for enterprise AI

Diego Santana

For enterprise AI, the rule is simple: buy or partner for commodity capability, build only your moat. The model, generic tooling, and undifferentiated plumbing are rentable; your proprietary data, redesigned workflow, and hard-to-copy integrations are where in-house engineering earns its keep. Most failed programs invert this — they build the commodity and buy the moat.

Why the instinct to build is usually wrong

Building feels like control, and control feels like safety — especially in regulated sectors. But the data points the other way. MIT's research found that buying from specialized vendors and forming partnerships succeeded about 67% of the time, while internal builds succeeded only about a third as often. The instinct to build everything in-house is one of the most reliable predictors of failure, because it spends scarce engineering on problems vendors have already solved and starves the part that actually differentiates you.

A decision rule

How to find your moat

Your moat is the thin layer competitors cannot trivially copy: the proprietary data you uniquely hold, the workflow you redesigned around it, and the integrations that bind it to how your business actually runs. Everything else is rentable. A useful test: if a competitor could buy the same capability off the shelf next quarter, it is not your moat — so don't spend your build budget there. Spend it on the ~10% that is defensible and rent the ~90% that isn't.

Total cost over time, not at purchase

Build-vs-buy is often argued on upfront price, which is the wrong frame. Renting commodity layers keeps fixed cost low and lets you switch as models improve every few months — you inherit the frontier for free. A large internal build locks you to today's approach and carries the hidden, recurring cost of maintenance, security, and staffing. Concentrated build effort on the moat is the only place spend reliably compounds into advantage.

How this fits the bigger picture

Build-vs-buy is downstream of two earlier decisions: which workflow you're rebuilding AI-first, and which use case comes first. Once those are clear, the build-vs-buy line usually draws itself — and getting it right is a core part of closing the AI implementation gap.

A short checklist before you build

Is this capability available off the shelf from a credible vendor? If yes, default to buy.
Would building it create a durable advantage competitors can't copy? If no, don't.
Will you still want to maintain it in two years, through model and security churn?
Does building it pull engineers off your actual moat? If yes, the opportunity cost is the real price.

FAQ

Should regulated industries build more in-house?: Counterintuitively, no — over-building is a top failure mode in regulated sectors. Buy commodity capability from vendors with the right controls, and build only the compliance-aware workflow layer that's specific to you.
What's the biggest build-vs-buy mistake?: Building the foundation model layer or generic orchestration in-house "for control," then buying a generic workflow product that doesn't fit — exactly backwards.
How does this affect cost?: Renting commodity layers keeps fixed cost low and lets you switch as models improve; concentrated build effort on the moat is where spend actually compounds into advantage.
Isn't relying on a vendor a lock-in risk?: The bigger lock-in is to your own legacy build. Renting commodity layers behind a clean internal interface keeps you free to switch providers as the market moves; your moat — data and workflow — stays yours.