“Do we buy a tool or build it ourselves?” is the question we get most often and the one framed worst, because there are no longer two options. There are four layers, and each has its own answer.
The four layers
1. The model. You don’t build it. Neither do most people: over 90% of notable frontier models in 2025 came from industry, and US private AI investment alone was $285.9 billion. Training your own is a decision almost no company should be entertaining.
2. The infrastructure. Orchestration, logging, cost control, evaluation. The market has decent options here and building from scratch rarely pays.
3. Your domain logic. How a case gets classified in your business, which fields matter in your documents, when to escalate to a person. Nobody sells this, because it is specific to you.
4. The integration. How data enters and leaves your systems, who approves what, where the record ends up.
The sensible answer is almost always: buy 1 and 2, build 3, and accept that 4 is your work whether you buy or not.
When to buy
- The problem is genuinely generic. Transcription, translation, format conversion, language detection. If your need is identical to ten thousand other companies’, buy it.
- The vendor takes on compliance. Sometimes what you are buying is someone signing the data processing terms, and it is worth the price.
- You need something working next month. Buying is faster nearly always. You can replace it later.
When to build
- The process is your differentiator. If what you want to automate is precisely what you do better than your competition, an off-the-shelf tool will level you down.
- Integration is 80% of the work. When the bought tool needs so much glue that the saving evaporates.
- Volume makes the licence hurt. Per-seat or per-query pricing becomes absurd at a certain scale.
- The data cannot leave. Then most of the decision is already made.
The “we’ll build it for control” trap
Building does not give you control: it gives you responsibility. When it breaks at seven on a Tuesday evening, it is yours. When the model changes and the system degrades, it is yours. When the person who wrote it leaves, also yours.
That responsibility is worth it when the system is differentiating. For a standard support process, it is a recurring cost for nothing.
The symmetric trap: buying the black box
Before signing, three questions that separate serious vendors:
- Can I export my data and my configurations? If the answer is vague, the price will rise at renewal and you know it.
- Which model is underneath, and can I change it? With six frontier providers nearly tied, locking to one unknowingly is free risk.
- How do I, not you, measure whether it works? If they won’t let you plug in your own evaluation set, you will never be able to compare.
The right framing
The question is not build or buy. It is: which part of this is still true in three years?
Not the model. Probably not the tool either. What survives is your codified domain knowledge — the rules, the edge cases, the evaluation set. That is what you need to own, whatever infrastructure sits underneath.