Build vs Buy

Build versus buy is the decision of whether an organization should develop an AI capability itself (training or adapting models and operating the stack) or acquire it from a vendor as a product, platform, or model API. For modern AI the choice is no longer binary: foundation models from providers and open-weight communities mean almost nobody trains a general language model from scratch, so the practical question is how much to customize and how much of the stack to control. The classic make-or-buy logic from economics and operations still applies, but the pace of model improvement changes the arithmetic.

Differentiation is the first factor: build where the capability is a source of competitive advantage, buy where it is a commodity. Summarizing meetings, drafting routine emails, or transcribing audio are capabilities competitors can rent identically, so building them gives no edge and diverts scarce talent. A proprietary ranking system trained on years of an organization's unique behavioral data, or a model embedded in a core product, may be differentiating enough to justify ownership. A caution comes from history: BloombergGPT (Wu et al., 2023), a 50-billion-parameter model trained largely on financial text, was an ambitious domain build, and general-purpose models released soon after were widely observed to match or exceed it on many tasks, a frequently cited illustration that building a model can be overtaken by the vendor frontier.

Data sensitivity and regulation shape how much can be sent to an outside service. Sending customer records, health data, or trade secrets to a third-party API raises contractual, privacy, and sometimes legal questions, such as data processing terms, retention, training-use policies, and cross-border transfer. Options short of building include enterprise agreements with no-training and zero-retention terms, dedicated or private cloud deployments, and running open-weight models such as Meta's Llama family or Mistral's releases inside the organization's own environment. Control over data is a legitimate reason to self-host, but self-hosting moves security and operation responsibilities in-house rather than removing them.

Cost, talent, and speed interact in ways that surprise teams. Buying is faster and cheaper at the start, with costs that scale with usage; building has large fixed costs in engineering, GPUs, and operations but may be cheaper per request at high, steady volume. Talent is frequently the binding constraint: running models reliably needs people for evaluation, serving, security, and monitoring, who are costly and scarce, and a team that can build a demo may be unable to maintain a production service. Speed favors buying for a first version, and a sensible pattern is to start with an API to validate the use case, then reconsider ownership once volume, requirements, and the value of the task are known. The full accounting belongs to total cost of ownership.

Fine-tuning versus using an API with better prompting and retrieval is the most common technical form of the question. Prompting and retrieval-augmented generation supply knowledge and instructions at request time, are easy to update, and often reach the needed quality; fine-tuning changes model weights to teach a style, format, or specialized task, and tends to help when behavior must be consistent, prompts become very long, or a smaller cheaper model must match a larger one's performance on a narrow task. Parameter-efficient methods such as LoRA (Hu et al., 2021) make adaptation of open-weight models inexpensive, and several providers offer hosted fine-tuning of their own models. A common misconception is that fine-tuning is the way to teach a model new facts; it is generally weak at that, and retrieval is usually the better fit for changing knowledge.

Hybrid arrangements are the norm: buy commodity components, build the differentiating layer, and keep the ability to swap. A typical mature design uses a vendor model API for most requests, a small self-hosted or fine-tuned model for high-volume or sensitive ones, and an in-house evaluation suite and data layer that outlast any single model. That structure also limits vendor lock-in, which is the main risk of buying. The decision is not permanent: it should be reviewed as prices fall, open models improve, and the organization's own volume and competence change.

Read build versus buy as a choice about where to hold control, set by differentiation, data, cost, talent, and speed, and reopened whenever the model market moves.