Build vs Buy AI: A Decision Most Companies Get Backwards
The build-versus-buy question is not about capability or cost. It is about whether the thing is a differentiator, and most companies answer it backwards.
Erin Moore
Fractional Chief AI Officer
Buy anything that is not a differentiator; build only what your customers would notice if it were generic. That rule settles most build-versus-buy arguments in a sentence, and most companies get it backwards — building the commodity because engineers find it interesting, and buying the differentiator because it looked faster.
The differentiator test
Ask what a customer would notice if this capability were identical to your competitor's. If the honest answer is nothing, buy it. Document classification, transcription, routine summarisation, standard chat interfaces — these are commodities, they are improving faster than you can maintain a fork, and building them consumes the engineering attention your actual product needs.
If the answer is that a customer would notice immediately — because the capability encodes something specific about how your business works, or sits on proprietary data nobody else has — that is a candidate for building. Even then, "build" usually means assembling on top of purchased models rather than training from scratch.
The costs each side hides
Buying hides switching costs. The subscription price is visible; the migration cost when the vendor is acquired, raises prices, or discontinues the product is not. This is why exit terms and data portability belong in the evaluation, not the renewal. Lock-in is a purchase-time decision that feels like a renewal-time problem, which is why exit terms belong in the vendor evaluation framework.
Building hides maintenance. The initial build is the cheap part. Models drift, dependencies update, the person who built it leaves, and the thing needs an owner for as long as it runs. Budget maintenance at a meaningful fraction of build cost annually, or plan to abandon it.
The middle option people forget
Most real answers are neither. You buy the model, buy the platform, and build the thin layer that encodes your business logic — the prompt design, the routing rules, the evaluation set, the integration with your data. That layer is small, genuinely yours, and portable if the underlying vendor disappoints.
Building this layer deliberately also solves the differentiator problem: the commodity underneath is replaceable, and the part that reflects how your company works stays with you.
Where the decision usually goes wrong
Two patterns, both common:
Building because the team wants to. A capable engineering team will always prefer building. That preference is not evidence, and the person deciding should not be the person who will enjoy the work.
Buying because the demo was good. AI demos are unusually persuasive because they are run on data chosen to make them persuasive. Evaluating a demo properly means running it on your worst data, not your cleanest — the protocol is in the vendor evaluation framework.
The vendor evaluation framework covers the test protocol; the point here is only that the buy decision should survive contact with your own inputs before money moves.
The compliance dimension
Build-versus-buy also shifts where documentation duties land. The EU AI Act sorts systems into risk tiers, including high-risk categories that carry documentation obligations, and building in-house means those obligations are yours rather than a vendor's. If you sell into the EU, read the tiers before deciding the build looks cheaper.
Frequently asked questions
Should we build or buy AI? Buy anything that is not a differentiator, and build only the layer that encodes something specific about your business. In practice most companies should buy the model and the platform and build a thin proprietary layer on top.
Is building cheaper in the long run? Rarely, once maintenance is counted. Models drift, dependencies change, and the system needs an owner for its whole life. Building is justified by differentiation, not by cost.
What is the biggest hidden cost of buying? Switching. The subscription is visible; the cost of migrating off when a vendor is acquired, raises prices or sunsets the product is not. Negotiate data portability and exit terms at purchase, when you still have leverage.
How do we avoid vendor lock-in? Keep your business logic, evaluation set and data in your own control, and treat the model as replaceable. If swapping the underlying vendor would require rebuilding everything you know about your own process, you have bought more than a tool.
Further reading
Tagged with:
Ready to Automate Your Business?
Let's discuss how AI automation can deliver measurable ROI for your organization in 90 days or sooner.