Build, buy, or wait: a decision framework for enterprise AI
The most expensive words in enterprise AI are “we should build that ourselves” — except for “let’s wait and see.” A framework for making the call per use case, with reversibility as the tiebreaker.
Every AI roadmap eventually reduces to a sequence of build-buy-wait decisions, and most organizations make them by temperament rather than framework. Engineering-proud cultures build too much; procurement-driven cultures buy too much; risk-averse cultures wait too long and then panic-buy. Each temperament has a failure mode, and each failure mode is expensive.
The four questions that decide it
- Is the capability differentiating or hygienic? If your competitors doing it equally well would not hurt you, it is hygiene — buy it and move on.
- Does quality depend on your proprietary data or context? Deep dependence argues for building the layer that touches your data, even atop bought components.
- Can you operate what you build? A built system without an operating team is a future outage with your name on it — capability to run is a precondition, not a detail.
- How reversible is the choice? Prefer the option you can exit: gateway abstractions make model vendors swappable; data pipelines you own make platform vendors negotiable.
The wait option is a position, not an absence
Waiting is legitimate when the capability curve is moving fast enough that six months buys a better entry point — but only if the waiting is active: baselines instrumented, data readied, evals built, so the eventual move is a sprint and not a study. Passive waiting, the kind that produces a committee and no artifacts, is just slow losing.
Buy the commodity, build the differentiator, and keep every choice reversible enough to survive being wrong.
In practice, mature portfolios converge on a pattern: bought foundations (models, infrastructure), built context layers (retrieval over your data, evals on your tasks, workflows on your systems), and a waiting list with entry criteria attached. The framework matters less than the discipline of applying it per use case — and writing the reasoning down where next year’s team can find it.