Build, buy, or wait: a decision framework for enterprise AI
The most expensive words in enterprise AI are “we should build that ourselves”, and perhaps only “let's wait and see” rival them. 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.