Build-versus-buy is usually presented as a feature comparison: a spreadsheet of what the vendor supports against what the team could write. That framing reliably produces the wrong answer, because the columns that decide the outcome are not features. They are who owns the data, who can change the behaviour when it is wrong, and what the exit costs in eighteen months.
The AI version of this decision has a further complication. Most "buy" options are themselves thin layers over the same foundation models you would use to build, so the question is rarely about capability. It is about how much of the surrounding system - integration, evaluation, permissions, monitoring, escalation - you are outsourcing, and whether that part is where your advantage lives.
This article covers what each option actually costs, the conditions under which each is correct, why the middle path is common, and how to structure the decision so it can be revisited without starting over.
The Comparison Is Not Model Against Model
Vendors and in-house teams generally reach for the same models. What differs is everything around them.
A bought solution supplies the workflow, the interface, the integrations to common systems, and the operating discipline - someone else's answer to monitoring, versioning, and support. You are buying a system that already survived contact with other customers.
A built solution supplies exactly your workflow, on your data, with your permission model, and gives you the ability to change any part of it. You are also buying the obligation to keep all of that running.
Framed that way, the honest question is not "can we build this." Almost any competent team can build a first version. It is "do we want to own this for the next three years, and is owning it worth more to us than the time it takes."
When Buying Is Correct
Buy when the capability is standard and the differentiation is elsewhere.
Transcription, translation, generic document OCR, meeting summaries, code assistance, and support-ticket deflection are commodity capabilities. A vendor amortizes development across hundreds of customers and will out-invest an internal team on the same problem. Building these is usually an expensive way to arrive at a worse version of something already available.
Buy when time matters more than fit. A capability needed this quarter to answer a competitive move is not a build project. Buy, learn what users actually do with it, and revisit later with evidence rather than assumptions.
Buy when the problem is well-bounded and unlikely to change shape. A tool that converts invoices to structured data solves a problem whose definition is stable across companies. Your version would converge on the vendor's.
Buy when you lack the operating capability. Running a model in production requires monitoring, retraining decisions, incident response, and an owner. A team without that discipline will not acquire it by building - it will simply have an unmaintained system instead of a maintained subscription.
When Building Is Correct
Build when the process is the differentiation. If how you underwrite, inspect, triage, or price is what makes you better than competitors, encoding that into a vendor's generic workflow flattens the advantage. Vendors optimize for the average customer; the average is what you are trying to beat.
Build when your data is the asset. Proprietary historical data - years of labelled outcomes, inspection results, resolved cases - is worth more inside a system you control. Ask precisely what a vendor does with data you send, whether it trains shared models, and whether you can extract your accumulated labels on exit. If the answer to the last question is unclear, you are renting the value you generate.
Build when the workflow is genuinely specific. A vendor covering eighty percent of your process often costs more than building, because the missing twenty percent lands in manual work, spreadsheets, and exception handling that never appears in the licence price.
Build when regulation or data residency forecloses the alternative. Some sectors cannot send certain content outside a controlled environment. That constraint decides the question before economics enter.
Build when unit economics turn against you at scale. Per-seat or per-document pricing that is comfortable in a pilot can become the largest line item at volume. Model the cost at your projected volume, not your current one.
The Middle Path Is the Common Answer
Most sound decisions are not one or the other. They separate the layers and choose independently.
Buy the foundation model. Almost nobody should train one. Buy infrastructure components - vector databases, observability, orchestration - where standard tools exist. Build the layer that encodes your process: retrieval over your corpus with your permission rules, your evaluation criteria, your escalation policy, your integrations.
This composition tends to be both cheaper and more defensible than either extreme. It also localizes lock-in: if a vector database or a model provider needs replacing, the part that carries your advantage is unaffected.
The design rule that makes this work is an abstraction boundary at every bought component. Calls to a model provider should pass through your own interface rather than being scattered across the codebase. The cost is small and it converts "we are stuck with this vendor" into a scheduled piece of work.
What the Comparison Usually Misses
Four costs are routinely absent from the spreadsheet, and all of them favour whichever option the author already preferred.
Integration. Both options require connecting to your systems, and this is frequently the largest line in either. A bought tool with poor fit for your identity model or data layout can cost more to integrate than a built system designed around them.
Evaluation. You need to know whether the system is right, and that requires a labelled set from your own domain. This work exists in both cases and is rarely included in a vendor comparison. Ask what happens when the vendor's system is wrong on your data - what your recourse is and how quickly it can change.
Ongoing operation. Buying moves this to a subscription. Building keeps it as headcount: monitoring, retraining, incident response, and a named owner. The comparison must be subscription cost against the actual staff time, not against zero.
Exit. What happens if you stop? With a bought system: can you export the data, the labels, the configuration, the history? With a built one: who maintains it if the person who wrote it leaves? Both have an exit cost and neither appears in a feature matrix.
Structuring the Decision
A sequence that produces a defensible answer in weeks rather than quarters.
Write down what specifically must be true for this to be worth doing, in operational terms - the decision it improves, the volume, the acceptable error rate, the systems it must reach. Many build-versus-buy debates end here, because the requirement turns out to be unclear enough that neither option can be evaluated.
Determine whether the capability is commodity or differentiating. If a competitor could buy the identical thing tomorrow and be at parity, it is commodity. Buy it.
If it is differentiating, decompose it. Which layers are commodity - model, storage, orchestration - and which carry your advantage? Buy the first, build the second.
Model the total cost at projected volume over three years for both paths, including integration, evaluation, and operation. Include the exit cost explicitly.
Then run a bounded pilot on the leading option with predefined exit criteria, and agree in advance what result would mean it should not proceed. A pilot that cannot fail is a procurement formality, not an evaluation.
Making the Decision Reversible
The decision will be wrong sometimes, so build in the ability to change it cheaply.
Keep your data in a form you can extract, in your own storage where possible, with the labels you generate belonging to you. Keep the evaluation set independent of any vendor's tooling, so you can measure a replacement against the same benchmark.
Prefer contracts that let you leave. A one-year commitment with export rights is worth more than a discount on three years without them.
And avoid the sunk-cost trap in both directions. A built system that has consumed six months is not thereby correct, and a vendor with two years remaining on a contract is not thereby the right answer. Set a review point at the start - a date and a measured condition - so that revisiting is a scheduled decision rather than an admission of failure.