Build or buy AI: the question is which part
Almost nobody builds all of it and almost nobody buys all of it, so posing the decision as a single choice produces a bad answer to the wrong question. A working system has four layers, and the sensible position differs at each. The model is bought: training a general one is not a defensible use of budget outside a handful of organisations. The serving infrastructure is bought for the same reason. The application layer in between is where the real decision sits, and it moves every year as things that required building become purchasable. And two layers should be owned whatever else you decide: the data pipeline, because it determines what any system can see, and the evaluation set, because it encodes what correct means here and is what lets you judge every vendor including the one you already have.
The two layers to own
The data pipeline. What is extracted, from where, transformed how, and made available to what. Any system you ever run, built or bought, sees your organisation through this. Outsourcing it means every future decision routes through whoever holds it, and the cost of changing vendor becomes the cost of rebuilding the foundation.
The evaluation set. Cases from your own work, labelled by your own experts. This is the instrument that tells you whether a vendor's system is good on your problem rather than on their demo, whether an upgrade helped, and whether quality has drifted. It is cheap to build during a project and impossible to buy, because it is a statement about what your organisation considers correct.
Owning both keeps every other decision reversible. That is their real value: not that they are strategically important in the abstract, but that they are what makes a bad vendor choice survivable.
The middle layer, where the decision actually is
Retrieval, orchestration, evaluation tooling, the interface. This is where teams agonise, and the useful framing is not capability but half-life.
Components here have a habit of becoming commodities. Something that took a team a quarter to build two years ago is now a configuration option in three products. That is not a reason never to build; it is a reason to prefer designs where the component can be swapped, and to be suspicious of any decision that makes swapping expensive.
The practical test before building anything in this layer is to ask what makes your case unusual. If the answer is nothing, you are rebuilding something purchasable and the only thing you gain is the maintenance. If the answer is specific and durable, building is defensible.
How to compare vendors honestly
Run each one against your own evaluation set. This single practice resolves most vendor comparisons faster and more reliably than any structured scoring exercise, and it is available to anyone who has done the work of building the set.
A demo on the vendor's data tells you they can demo. Twenty of your real cases, scored by your own experts, tells you what will happen when your people use it. Vendors who resist this are telling you something useful; vendors who welcome it usually know their system handles the awkward cases.
The second question worth asking is what happens to your data and your configuration if you leave. An answer involving a reasonable export is fine. An answer that amounts to starting again means the decision is not really reversible, whatever the contract says.
The cost comparison that gets done wrong
Build is compared against a licence fee, and the build side is counted as the engineering to first release. That is not what building costs. It costs first release plus maintenance, plus the migration when the model provider deprecates something, plus the person who owns it in two years when the people who wrote it have moved on.
A fair comparison prices three years of both options with those included. Doing so does not automatically favour buying: a vendor's fee also rises, and a system you own does not get repriced at renewal. It does change which options look close, and it removes the illusion that building is a one-off cost.
The internal-team case
An organisation with real engineering capability faces a different version of this, and the honest answer is more often build than vendors like to admit. If the problem is well understood and the team is strong, they will do it cheaper and will own the knowledge, which compounds.
What usually justifies outside help in that situation is not capability but sequencing: someone who has done this fifteen times knows which of the fifteen things to skip. That is a real saving and it is a smaller engagement than a build.
This is worth saying plainly on a page that sits inside a consulting site. A company that should build it themselves and is told to buy has been badly advised, and the advice is recognisable afterwards. Our engagement page says the same thing in the other direction.
Bring the four layers
If you are deciding this, a useful conversation goes layer by layer rather than vendor by vendor. We will tell you where we think you should build, including when that means not hiring us.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
