Build, buy, or neither: where your AI advantage actually lives
Bottom line: "Build versus buy" is the wrong frame for an AI stack, because it assumes you must own a layer to benefit from it. The right question, asked layer by layer, is whether you have a genuine edge there. Build only where you do; buy where you don't; and recognize that "neither" — defer it, wrap it, or do without — is often the correct answer most teams never consider. The common failure is exactly inverted: teams build the commodity layers out of pride and buy the differentiating ones out of haste.
Build versus buy is the wrong question
The build-versus-buy debate has a hidden assumption that quietly distorts every AI architecture decision: that the way to benefit from a capability is to own it. So the conversation collapses into a binary — write it ourselves, or pay a vendor — and the team argues about cost and control as if those were the only variables. They are not, and the binary itself is the problem.
Owning a layer and benefiting from a layer are different things. You benefit from your cloud provider's hardware without building chips. You benefit from a foundation model without training one. The question that actually predicts advantage is not "build or buy" but "is this layer somewhere we can win, and does it matter if we do." A layer can be essential to your product and still be one you should buy, because you have no edge in it and never will. Another can be unglamorous and worth building, because it is where your specific advantage is hiding. Until you separate "do we own it" from "do we have an edge in it," you will keep making confident decisions on the wrong axis.
Owning a layer is not the same as benefiting from one. The whole skill is knowing the difference.
Three answers, not two
Once you drop the binary, a third answer appears, and it is the most underused option in enterprise AI: neither.
Build is right when a layer is core to your advantage and you have a genuine edge to win it — when owning it produces something a competitor cannot easily replicate. Buy is right when a layer is necessary but you have no edge there; the market will do it better and cheaper than you, and your effort is better spent elsewhere. And neither is right far more often than teams admit: when a layer is neither a source of advantage nor something you can win, the correct move is to defer it, wrap a thin abstraction around a commodity and move on, or simply do without it until it matters. "Neither" is not indecision. It is the discipline of refusing to spend scarce engineering attention on something that will never pay it back. Every hour spent building a layer that confers no advantage is an hour not spent on the layer that does — and that opportunity cost is the most expensive line item that never appears in a budget.
The Advantage Map
Two questions, asked of every layer, place it on a map that gives you the answer.
Exhibit 1. Per layer, two questions decide build, buy, or neither — not the layer's glamour.
The first axis is whether the layer is core to your advantage — whether winning it changes your competitive position or merely keeps the lights on. The second is whether you have the edge to win it — the data, the talent, the proximity to the problem that would let you do it better than the market. The four quadrants follow. Core and you have the edge: build — this is your moat, own it. Core but you lack the edge: partner or build-to-learn — you cannot cede it, but you cannot win it yet, so you partner while you develop the capability. Not core but you could win it: neither — skip it; winning a race that does not matter is just an expensive way to lose focus. Neither core nor winnable: buy — rent the best option and stop thinking about it.
The value of the map is that it forces the two questions to be asked separately. Most architecture debates conflate them — treating "important" as if it meant "ours to build" — and that conflation is what produces the universal error the map is designed to expose.
Important is not the same as winnable. Build only where both are true.
Run your stack through the map
Take a typical AI stack, layer by layer, and place each one honestly.
Exhibit 2. Buy the commodity base; build the differentiating top, where your data and workflow live.
The commodity base is almost always a buy. Infrastructure — GPUs and serving — is a solved market; building your own is rarely a source of advantage and usually a tax. The foundation model is a buy and, increasingly, a swappable one: it is converging toward commodity status, and treating it as your differentiator means competing on the one layer everyone can rent on the same terms (Stanford HAI, AI Index Report 2025). Orchestration and agent frameworks are mostly a buy, or a thin build at most. Then the map tips. Your retrieval and context pipeline, your evaluation harness, your proprietary data and feedback loop, and your workflow and domain UX are where your edge actually lives — because they are built out of your specific data, your specific users, and your specific problem, which is exactly what a competitor lacks.
The pattern is consistent, and it is the opposite of what most teams do. The differentiating layers — retrieval, evaluation, the data loop, the workflow — are the ones worth building, and they are precisely the ones teams reach for an off-the-shelf template to handle so they can pour their engineering pride into a custom serving stack or a fine-tuned model that a competitor will match in a quarter. Build the top of the stack, where your advantage is. Buy the bottom, where it is not.
What this looks like on Monday
Put two teams side by side with the same seven layers, the same budget, and the same model. (This is an illustration, not an account of any specific engagement.)
Exhibit 3. Same stack, opposite calls — only one team owns something worth owning. Illustrative, not a client account.
The first team builds the wrong layers. It builds its own serving infrastructure to feel in control, fine-tunes a model and calls it the differentiator, and uses a lightly-tuned off-the-shelf template for retrieval and its data loop. Every one of those choices is defensible in a planning meeting and wrong on the map: it has poured effort into commodity layers and rented the layer where its advantage could have lived. The result is a bespoke, expensive stack with no defensible layer in it.
The second team inverts every call. It buys serving and spends the saved time on its data loop. It treats the model as a swappable commodity rather than a moat. It builds retrieval and the feedback loop, because that is where its edge actually is. Its stack looks less impressive on an architecture diagram — most of it is bought — but the one thing it built is the one thing a competitor cannot.
Same seven layers. Same budget. The difference is entirely which layers each team chose to own — and only one of them owns something worth owning.
Where this argument fails, and what it costs
The map has limits, and they are worth naming.
The map is a snapshot, and edges move. A layer where you have no edge today may become winnable as your data accumulates or your team grows, and a layer that is differentiating now may commoditize out from under you — the foundation model is the clearest example of a layer that has slid from "build" toward "buy" in a few short years. So the map must be re-run periodically, not treated as a permanent verdict. There is also a category of "buy" that carries strategic risk: depending on a single vendor for a layer that is core to your product is a buy decision that quietly becomes a switching-cost and lock-in exposure, which is its own cost to weigh. And there is genuine value in building-to-learn — constructing a commodity layer once, at small scale, specifically to understand it before you buy at large scale — which looks like wasted effort on the map but is really an investment in judgment. The discipline is to know when you are doing that on purpose, rather than discovering after the fact that you built something you should have bought.
That bounds the claim. Re-run the map as edges shift, weigh lock-in on your strategic buys, and build-to-learn deliberately when it is worth it. The point is not a fixed answer; it is asking the two right questions instead of the one wrong one.
The decision
On your next initiative, the move is concrete.
Before you architect anything, list your layers and run each through the two questions — is this core to our advantage, and do we have the edge to win it — and write the answer in one of four words: build, buy, partner, or neither. Be ruthless about the "neither" column, because it is where focus is won or lost. Then check your instinct against the map's most common failure: if you are planning to build a commodity layer or buy a differentiating one, stop and justify it explicitly. Concentrate your building on the layers where your data, your users, and your workflow give you an edge no competitor can rent — and buy, partner, or skip the rest without guilt.
The model and the infrastructure will keep getting cheaper and better, and building your own version of them will keep feeling like control while delivering none. Build where you have an edge, buy where you do not, and choose "neither" far more often than feels comfortable. The companies that win are not the ones that built the most — they are the ones that built the few layers that were actually theirs to win. Where those layers live, and why the data loop is usually among them, is the durable-advantage question taken up in the companion piece on data exhaust; which layers deserve the scarce attention in the first place is the judgment question behind all of it.
Sources
- Stanford HAI — Artificial Intelligence Index Report 2025. Falling price-to-performance and convergence of frontier models, supporting the treatment of the model layer as a commodity to buy. https://aiindex.stanford.edu/report/
- McKinsey — The State of AI (annual survey). Talent scarcity and build capacity among the constraints shaping where enterprises can realistically build. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Deloitte — State of Generative AI in the Enterprise (2024–2025). Integration, talent, and data readiness as practical determinants of build-versus-buy outcomes. https://www2.deloitte.com/
Bottom-line summary (one line)
Stop asking "build or buy" and start asking, per layer, "is this core, and can we win it" — build only where both are true, buy where neither is, choose "neither" more often than feels comfortable, and concentrate your building on the data and workflow layers that are actually yours to own.
Suggested LinkedIn hooks (link back to the blog)
- The build-vs-buy debate about your AI stack has a hidden flaw: it assumes you must own a layer to benefit from it. You don't. Here's the map that gives the real answer. [link]
- Most teams build the commodity layers of their AI stack out of pride and buy the differentiating ones out of haste. It's exactly backwards — and it's costing them their moat. [link]
- "Build or buy" has a missing third answer: neither. Defer it, wrap it, or do without. It's the most underused — and often most correct — option in enterprise AI architecture. [link]