- Build vs buy is a false binary. An AI platform is a stack of layers, and the real question is what to build, what to buy, and how to compose the rest. Most mature enterprises orchestrate rather than pick a pure side.
- The guiding principle is to build only what differentiates you, buy the commodity, and refuse to build undifferentiated heavy lifting such as your own vector store or gateway that adds cost without a moat. The common winning pattern is to buy models, a vector database and a gateway, and build the thin domain, orchestration and data-integration layer on top.
- The decision is per-capability, not one global choice, and it is revisited as you mature. Each path carries a different total cost and demands a different talent profile, and a gateway is the abstraction seam that keeps models and providers swappable.
The question is not binary
Ask a room of executives whether the enterprise should build or buy its AI platform and you will get a vigorous debate that solves nothing, because the question contains its own error. Build versus buy assumes the platform is a single thing you can source a single way. It is not. An enterprise AI platform is a stack of layers, and each layer has its own economics, its own maturity, and its own relationship to what makes your company worth more than its competitors. Answering with one word for the whole stack guarantees you get several of the layers wrong.
Consider what actually sits in that stack: foundation models, an inference and serving path, a vector database, a model gateway, retrieval and data-integration plumbing, orchestration for agents and workflows, evaluation and observability, and the domain logic that encodes how your business actually operates. Some of these are commodities available from a dozen credible vendors. Some are your genuine advantage. Treating them as one decision means either buying away your differentiation or building the parts that a mature market already sells better than you can.
The honest reframing is three questions, resolved layer by layer. What do you build, because it is where your advantage lives and no vendor can sell it to you? What do you buy, because it is undifferentiated infrastructure that a specialist runs better and cheaper? And how do you compose the two into something coherent? For most enterprises past the pilot stage, the answer that emerges is not a pure side at all. It is to orchestrate: buy the commodity layers, build the thin layer that differentiates, and own the seams that hold them together.
Three options, honestly compared
Before applying the reframing per layer, it helps to name the three archetypes plainly, because each is a real strategy some enterprise is running today. Build means assembling your own stack from components and open source: you take open-weight models, an open vector store, an open orchestration framework, and you integrate, operate and harden them yourself. Buy means adopting an integrated vendor platform that ships models, retrieval, orchestration and governance as one product you configure rather than construct. Orchestrate is the middle path: a thin control plane you own that composes managed services, buying the heavy commodity pieces and building only the connective tissue and the domain logic on top.
The three are not equally good at everything, and the honest comparison is across the dimensions that actually decide the outcome: speed to value, control, total cost, lock-in, and the talent each demands. The pattern below is directional rather than absolute, since a well-run buy can beat a badly run build on every axis, but the shape holds often enough to reason from.
| Dimension | Build | Buy | Orchestrate |
|---|---|---|---|
| Speed to value | Slowest; you assemble and harden everything first | Fastest to a demo; configuration over construction | Fast; buy the hard parts, build only the thin layer |
| Control | Total; every layer is yours to change | Bounded by the vendor's roadmap and knobs | High where it matters, delegated where it does not |
| Total cost | High and mostly people; the run cost hides in operations | Predictable license, premium at scale, limited tuning | Moderate; pay for commodity, invest effort in the seam |
| Lock-in | Low to the vendor, high to your own code | Highest; the platform becomes your contract | Managed by design if the seams are yours |
| Talent needed | Platform and infra engineers, on staff | Strong vendor and product management | Integration engineers who compose services well |
Read the table as a menu, not a verdict. A single enterprise typically runs all three at once: it buys foundation models, builds the domain layer that encodes its business, and orchestrates the middle. The archetypes describe how you source a given capability, not a company-wide identity you must pick and defend.
The differentiation test
Every sourcing decision reduces to one test applied to each capability: does owning it create differentiation, or does it merely add cost? The principle is old and unglamorous, and it is violated constantly. Build only what differentiates you. Buy the commodity. The advantage of stating it so bluntly is that it exposes the most common and expensive mistake in enterprise AI programs, which is building the undifferentiated heavy lifting.
The trap has a recognizable shape. A capable platform team, given budget and enthusiasm, starts building its own vector store, its own model gateway, its own serving stack, its own evaluation harness from first principles. Each is a genuine engineering achievement. None of them, on its own, makes a single customer prefer your company. You have spent your best engineers and eighteen months rebuilding infrastructure that a specialist vendor sells as a commodity, and the result is not a moat. It is a maintenance burden dressed up as a platform. The market for these components is deep and moving fast; your homegrown version starts behind and falls further behind every quarter you are not the specialist.
So where does the real advantage actually sit? Almost never in the infrastructure, and almost always in the layers a vendor cannot ship because they are specific to you:
- Proprietary data and how you turn it into retrieval: your documents, your history, your labeled outcomes, and the pipelines that make them useful. No vendor has these.
- Domain logic and workflow: the encoded knowledge of how your business underwrites, prices, diagnoses or routes, which is the thing customers pay you for.
- The orchestration and evaluation of your specific tasks: how you decompose a real problem, chain the steps, and measure quality against your own definition of correct.
- The integration into your systems of record: the unglamorous plumbing into your ERP, CRM and data platform that makes AI act rather than merely answer.
Notice that none of these is a foundation model, a vector database or a gateway. Those are the commodity you buy. Your moat is what you compose on top of them and the data you feed through them, which is precisely why the middle path tends to win.
Why orchestrate usually wins
Once you apply the differentiation test layer by layer, the same answer keeps falling out, and it is neither pure build nor pure buy. Buy the models, the vector database and the gateway, because they are commodity infrastructure a specialist runs better than you will. Build the thin layer on top: the domain logic, the orchestration, and the data integration that are specific to your business and cannot be purchased. This is the orchestrate pattern, and it maps almost directly onto the reference architecture, where the lower layers are bought managed services and the upper layers are the code you own.
YOUR MOAT, so you BUILD it (thin, owned)
+---------------------------------------------+
| domain logic / business workflows |
| orchestration & agents |
| data integration into systems of record |
+---------------------------------------------+
| built on |
v v
COMMODITY, so you BUY it (managed services)
+----------+ +-------------+ +-------------+
| models | | vector DB | | gateway |
+----------+ +-------------+ +-------------+
Orchestrate wins on two things that matter more than they first appear. The first is speed to value. You are not rebuilding a vector store or a serving stack, so your scarce engineers spend their time on the domain layer that actually moves a business metric, and you reach production in quarters rather than years. The second is optionality. Because you bought the commodity layers behind interfaces you control, you can replace any one of them as the market moves without rewriting the layer above. The model that is best today will not be best in a year, and orchestration lets that be a swap rather than a rebuild.
The discipline that makes this work is keeping the built layer genuinely thin. The temptation, once you have an orchestration layer, is to let it grow tentacles into concerns the bought services should own. Resist it. The value of the pattern is that the boundary between what you build and what you buy is explicit, defensible, and drawn along the line of differentiation, not along the line of whatever felt convenient under deadline.
Lock-in and optionality
Lock-in is the cost that never appears in the business case and always appears at renewal. It comes in two flavors that are worth separating. Vendor lock-in is dependence on a specific platform whose request format, data model and pricing you have wired into your applications, so that leaving means a migration nobody has time for. Model lock-in is narrower and more insidious: your prompts, your evaluation suite and your agent behaviors are tuned to one model's quirks, so switching providers means re-testing everything even when the API looks the same. The buy path maximizes the first. Naive building can still incur the second.
The cost of exit is the real measure. A platform you can leave in a sprint is not lock-in; a platform whose departure would take a year and a reorganization is a strategic dependency you took on without pricing. The point is not to avoid all dependency, which is impossible and usually not even desirable, but to know what each one would cost to unwind and to accept it deliberately rather than discover it later.
The practical answer to model lock-in is the model gateway as an abstraction seam. When every application speaks to one internal interface and the gateway translates to whatever provider actually serves the request, a model swap becomes a routing change instead of an estate-wide code change. The seam is where your optionality lives. It is also where the balance tips, because an abstraction is not free.
The honest position on the closed-versus-open question, explored in open vs closed, is that the seam matters more than the choice. If your applications can move between a hosted frontier model and an open-weight model you serve yourself with only a configuration change, you have kept the option open, and the decision stays reversible as the market and your maturity change.
Total cost and the talent it needs
Every path has a headline cost that goes in the slide and a real cost that shows up eighteen months later. Build looks cheapest on paper because open-source components carry no license fee, which is exactly the trap. The license was never the cost; the run cost was. Buy looks expensive because the invoice is visible, but that visible number often includes the operational burden you would otherwise have carried yourself. Orchestrate sits between them, and its hidden cost is the integration effort that naive estimates treat as a rounding error and that turns out to be the actual work.
Just as decisive, and even more often ignored, is that each path needs a different kind of person. You cannot switch strategies without switching the team, and a plan that assumes otherwise fails quietly.
| Path | Talent it depends on | The hidden cost that sinks naive estimates |
|---|---|---|
| Build | Platform and infrastructure engineers, on staff and retained | Operating it: on-call, upgrades, security patching, reliability, and the salaries that never end |
| Buy | Strong vendor and product management, plus commercial skill | Premium pricing at scale, egress and re-tuning at exit, and features you cannot get on the roadmap |
| Orchestrate | Integration engineers who compose services and own the seams | The connective tissue: data pipelines, evaluation, glue code, and the ongoing cost of keeping seams current |
The pattern to internalize is that build converts a capital-looking project into a permanent operating liability. The team that stood up the platform is the team that must keep standing it up, forever, and the day they leave is the day the estimate breaks. Buy converts an engineering problem into a commercial one, which is cheaper only if you have the vendor-management muscle to negotiate, monitor and hold a supplier accountable, and expensive if you do not. Orchestrate needs the rarest profile of the three: engineers fluent enough in several managed services to compose them well and disciplined enough to keep the built layer thin. Staff for the path you actually chose, and be honest that changing paths means changing people, not just architecture.
A decision framework
The framework is deliberately not a single verdict. Run it once per capability in your stack, because the right answer for foundation models is almost never the right answer for domain logic. For each layer, score five factors and let them point to build, buy or orchestrate. The checklist below is the whole method compressed into something you can apply in a review.
FOR EACH CAPABILITY IN THE STACK, ASK:
1. Differentiation Does owning it create a moat?
high -> lean BUILD low -> lean BUY
2. Speed to value How fast must it reach prod?
urgent -> BUY / ORCHESTRATE patient -> BUILD ok
3. Control & compliance Regulated data or strict SLA?
strict -> BUILD / ORCHESTRATE relaxed -> BUY ok
4. Talent Do you have the people to run it?
yes -> BUILD viable no -> BUY / ORCHESTRATE
5. Scale Does cost explode at volume?
yes -> revisit; BUILD/self-host may pay back
DEFAULT when signals conflict: ORCHESTRATE
(buy the commodity layer, build the thin seam)
Two disciplines keep the framework honest. The first is that the decision is per-capability, not one global choice. A mature enterprise buys its models, orchestrates its retrieval and gateway, and builds its domain and evaluation layer, all at once and without contradiction, because it scored each independently. Anyone who tells you the company should "build" or "buy" its AI platform is answering the wrong question. The second is that the decision is revisited as you mature. What you buy today because you lack the talent, you may bring in-house once the capability is core and the team exists; what you built early because nothing existed, you may retire to a vendor once the market catches up. This is the same rigor classic enterprise architecture has always demanded, applied to a stack that now includes models and agents as first-class elements.
Treat the output as a portfolio decision that you re-score annually, not a monument. If you want to pressure-test a specific layer against these factors, the Strategic Option Weigher in the Lab turns the checklist into a scored comparison, and the reference architecture shows where each decision lands in the full stack.