By Editorial — IT Researches
The build-vs-buy conversation has been the staple of enterprise AI strategy since at least 2015. The arrival of capable foundation models has not made it less important; it has changed the questions that have to be asked. We work through the new rules with our clients on most engagements, and the framing has settled enough to be worth writing down.
Rule one: the question is no longer build vs buy, it is build, buy or compose. The third option — assembling a solution from a small number of foundation-model APIs, a thin orchestration layer and your own data — did not really exist in 2018. In 2025 it is the right answer for a non-trivial fraction of the use cases that, five years ago, would have justified a custom model. The first analytical move is to ask whether composition is plausible before the build/buy debate begins.
Rule two: data gravity beats model novelty. Wherever the proprietary data is, the system tends to want to live nearby. A vendor whose product cannot run inside your data perimeter, or that cannot operate on your data without exfiltrating it, has a structurally weaker offer in 2025 than it did in 2020. This applies in both directions: it weakens vendors whose deployment model is rigid, and it strengthens platforms that have invested in flexible, in-tenant deployment.
Rule three: the marginal cost of a custom model has fallen, and the marginal cost of operating one has not. The thing that used to argue for buying — that building a competent model was expensive — is much less true than it was. The thing that always argued for buying — that running a model in production at enterprise scale, with the on-call, the monitoring, the retraining cadence and the regulatory documentation, is expensive — is exactly as true as it ever was. Decisions that focus on training cost and ignore operating cost will keep being wrong.
Rule four: regulatory scope decides more questions than it used to. The EU AI Act, the equivalent regimes elsewhere, and the slow tightening of sectoral regulators have made the documentation, traceability and explainability obligations of an AI system a first-order architectural constraint. A vendor whose product cannot produce the documentation a regulator now expects has, in some sectors, removed itself from the conversation. A custom build whose team has not budgeted for that documentation has signed up for a multiplier on its cost that will only become visible at audit time.
Rule five: integration is still the work. The single largest predictor of an AI system's eventual success or failure remains the quality of its integration with the workflows it is meant to support. Build vs buy is, at the limit, a debate about who does that integration. The instinct to choose the option that requires less integration work is usually the wrong instinct; the integration work is where the value lives, and outsourcing it tends to outsource the value with it.
Rule six: the team is the asset. A buy decision that does not also build internal capability is a buy decision that locks the organisation into the vendor for the life of the system. A build decision that does not retain the people who built it produces a system the organisation cannot maintain. The honest framing of the question is: which of these options leaves us, two years from now, with a team that can extend, replace or argue with the system we have just deployed? That framing changes the answer in more cases than the cost spreadsheet does.
The conclusion, after all this, is unsatisfying but accurate: there is no general answer. The new rules do not produce a stronger preference for build or for buy; they produce a stronger preference for honest analysis. The teams that do that analysis well in 2025 are the teams that will be quietly outperforming their peers in 2027.