Every organisation adopting AI faces the same fork: license a finished product, or assemble something internally on top of a general model. The decision is usually framed as a cost comparison, and cost is rarely what determines the outcome.
The comparison is not model against model
Buyers often compare a vendor's product with a general model they could call directly, and conclude that the direct call is far cheaper.
That arithmetic ignores what the vendor has built around the model: the interface, the permissions, the connectors, the evaluation harness and the support desk that answers when it misbehaves.
Reproducing those takes a team, and the team is a permanent cost rather than a project cost.
A fair comparison prices the vendor's annual fee against a fully loaded internal team plus infrastructure, and the gap narrows considerably.
Proprietary knowledge pushes toward building
The strongest argument for building is that the task depends on something the company knows and nobody else does.
A manufacturer with thirty years of maintenance records, an insurer with its own claims history, a retailer with its own returns data — each holds material a vendor cannot replicate.
Systems built on that material inherit an advantage that persists, because the data keeps accumulating and the competitor cannot buy it.
Where the task depends only on general capability, such as drafting a polite reply or summarising a meeting, there is nothing to defend and the vendor will do it better.
Regulation can remove the choice
Some sectors cannot send certain data outside their own infrastructure, and that settles the question before any comparison begins.
Healthcare records, legal files under privilege, and defence-adjacent work all carry constraints that many vendors cannot satisfy at any price.
The practical response has been self-hosted open-weight models, which trade some capability for the ability to keep everything inside the boundary.
Firms in this position often build not because they want to, but because the buy option does not legally exist for their data.
Buying is faster and speed compounds
A licensed product can be running in weeks. An internal equivalent takes quarters.
During those quarters the organisation learns nothing, because learning comes from users encountering the system and complaining about it.
Teams that buy first often build later with far better specifications, because they know which parts of the workflow actually mattered.
The reverse sequence — building to a specification written before anyone used anything — produces systems that satisfy the document and not the users.
Speed also matters because the underlying models improve on a cycle measured in months, and a long build risks shipping against assumptions that have expired.
The maintenance burden is the hidden term
Building is not a project with an end. Models are deprecated, interfaces change, prompts that worked stop working, and the evaluation suite needs updating.
Someone must be on call for this indefinitely, and that person is difficult to hire and easy to lose.
When they leave, an internal system frequently becomes unmaintainable, because the reasoning behind its prompts and thresholds lived in their head.
Vendors absorb this cost across their whole customer base, which is the main thing a buyer is actually paying for.
Most organisations end up doing both
The stable pattern is buying for commodity capability and building for the differentiated slice.
A company might license a transcription and meeting tool, license a coding assistant, and build only the system that routes its own claims using its own history.
This keeps the internal team small and pointed at work that would not exist without them.
It also means the internal system can be judged honestly, since it is not competing with a vendor on features that were never the point.
Switching cost decides more than it should
The question buyers underweight is how expensive it will be to leave.
A product that holds the accumulated corrections, labels and feedback of two years is difficult to abandon, because that material is what made it useful.
Contracts that keep the derived data exportable, in a form another system can consume, preserve the option to move.
Where export is not possible, the effective price is the quoted price plus whatever the vendor can charge at renewal, and that figure is unbounded.
The same logic applies to internal builds tied tightly to one provider's interface, which is a lock-in with fewer contractual protections rather than more.
The decision should be revisited on a schedule
A build-or-buy answer is correct for a set of conditions, and the conditions change quickly.
Capability that required a custom system two years ago may now be a standard feature of a product costing a fraction of the maintenance.
Organisations that treat the decision as permanent end up defending internal systems whose only remaining advantage is that they were expensive to create.
Reviewing each system annually against what is now purchasable is unglamorous, and it is the practice that separates a sensible portfolio from an accumulation of abandoned projects.