Cost comparisons dominate this decision and should not. Buying is almost always cheaper in year one. The question is whether the capability is something you can afford not to control.
The differentiation test
Ask: if a competitor had this exact capability, would it matter?
No — buy it. Transcription, translation, OCR, generic summarization, standard chat widgets. These are commodities with mature vendors and no strategic content. Building them is a waste of engineering capacity.
Yes — build, or at minimum own the layer that makes it yours. If your advantage comes from twenty years of proprietary claims data, a vendor product trained on generic data will not deliver it, and feeding your data into their product may hand them your advantage.
Buy when
- A mature product exists and the problem is well-defined.
- Your requirements are close to the vendor's mainstream use case.
- Time to value matters more than unit economics.
- You lack the engineering capacity to maintain it — and maintenance, not building, is the real commitment.
- The capability is a cost centre, not a differentiator.
Build when
- The capability depends on proprietary data or a process unique to you.
- It is what customers actually pay you for.
- Integration depth with internal systems is the hard part, which is usually where vendor products fall down.
- Regulatory or residency constraints rule out available products.
- Volume is high enough that per-seat or per-call vendor pricing becomes punitive.
The middle path, which is usually right
Most sensible architectures buy the commodity layers and build the differentiated one.
Buy the model API — almost nobody should be training foundation models. Buy the vector database, the observability tooling, the transcription. Build the pipeline logic, the retrieval strategy over your own corpus, the evaluation set, and the integration.
That eval set deserves emphasis: it is the most durable asset in any AI project. It outlives model choices, vendor changes, and architecture rewrites. Own it regardless of everything else.
A useful reframe: do not ask "build or buy the system." Ask "which layers do we buy, and which layer is ours." The answer is nearly always that you buy infrastructure and build the part encoding your specific knowledge.
Hidden costs on both sides
Buying: per-seat pricing that scales badly, integration work the demo did not show, data leaving your boundary, vendor roadmap diverging from your needs, switching cost once workflows are embedded, and price increases after you are dependent.
Building: maintenance at 15–25% of build cost annually, the requirement to retain capable engineers, model deprecations forcing requalification, and opportunity cost of the team not doing something else.
The switching-cost question
Before buying, ask what leaving looks like. Can you export your data, your prompts, your evaluation results, your configurations? A vendor that makes exit easy is a much safer purchase than one whose pricing is slightly better.
The same applies to model providers: keep the abstraction thin enough that changing model is configuration, not a rewrite.
Frequently asked questions
Is it cheaper to build or buy AI?
Buying is nearly always cheaper in year one; building often wins by year three at meaningful volume, because vendor pricing scales with usage while build cost is mostly upfront. But cost should not decide this — differentiation should. Buying something strategic to save money is a bad trade even when the arithmetic looks good.
Should we build our own models?
Almost certainly not foundation models. Fine-tuning an existing open-weight or hosted model for a narrow high-volume task can be justified. Training from scratch requires capital and talent that make sense for very few organizations, and the capability gap versus frontier models is large.
What if no vendor product fits?
That is a strong build signal, but check whether the gap is genuinely in the capability or just in integration. If several vendors do the core job and all fail on integration with your systems, buying the capability and building the integration is usually cheaper than building both.
How do we avoid vendor lock-in?
Own your data, your prompts, and your eval set. Keep provider-specific code behind a thin interface. Prefer vendors with real export capability. Test your exit path before you need it, not after.
Can we start by buying and build later?
Yes, and it is often the smart sequence — buy to validate that the use case works, build once you know it matters and understand the requirements. The risk is that workflows calcify around the vendor and the rebuild never gets funded. Decide the trigger for revisiting at the time you buy.