Build, buy, or borrow? A decision framework for large language models

The question arises in nearly every AI conversation: should the organization build the capability itself, buy a product, or call an API? In our experience the answer depends on three factors, none of which is the model’s benchmark score.

1. Where the differentiation lies

If the value lies in the organization’s own data and workflows, a generic product will deliver a generic result. If the value lies in a capability every organization needs—transcription, translation, summarizing a meeting—buying is almost always the right choice, and building is difficult to justify.

2. What must stay where

Data residency, contractual restrictions, and privacy law determine more architectures than performance does. A model hosted within the organization’s own cloud tenancy costs more to run and less to explain. For some workloads in Canada—health, the public sector, anything involving Quebec residents under Law 25—that trade-off is the entire decision.

3. How quickly the ground moves

Model quality and pricing change quarterly. Anything an organization builds should assume the underlying model will be replaced at least twice. That argues for a thin layer the organization owns—retrieval, evaluation, prompts, and guardrails—rather than a deep investment in any single vendor’s approach.

The pattern that tends to prevail

Borrow the model, build the framework, buy the commodities. Use an API, or a hosted open model where residency requires it; own the evaluation and retrieval layer that makes the system specific to the organization; and buy the tools that are not core to the business. Revisit the decision every six months. The answer will change, and the evaluation framework is what makes changing inexpensive.