Build vs buy in 2026: a decision framework that actually decides
The build-vs-buy debate has gotten harder, not easier, as the AI tooling layer has exploded. A four-question framework that cuts through the noise.
Three years ago, 'build vs buy' had a relatively clean answer for most data and AI capabilities: buy the platform, build the application. Today, the tooling layer has exploded, every vendor has bolted on an LLM, and the line between 'platform' and 'application' has blurred. The question is harder, not easier.
The new shape of the question
The right framing is no longer 'build or buy'. It's 'where on the stack are we differentiated, and what is everything else?' Differentiated layers — the ones tied directly to your competitive position — deserve real engineering investment. Everything else should be the boring, supported, well-trodden path.
Four questions
- Does this capability touch a metric we win on? If yes, lean build. If no, lean buy.
- Is the surrounding ecosystem mature? Mature ecosystems make buying cheaper to operate. Immature ones lock you in.
- What is the total cost over three years — including the engineers who maintain it? Build is rarely cheap in year two.
- What is the option value? A built solution can pivot. A bought one can be replaced — but only at switching cost.
The middle path
Increasingly, the right answer is neither. It's 'buy the engine, build the experience'. Buy the foundation model. Build the evaluation, the workflow, the integration, the safety layer. Buy the warehouse. Build the semantic layer that makes it yours. The arbitrage is in the integration, not the components.
Most build-vs-buy debates end where they started because nobody named the decision. Name it. Time-box it. Run the four questions. Move on.
Working on something this touches?
We help teams turn essays like this into systems that run in production. One conversation, no pitch deck.
Start a conversation