Should your company build or buy its AI capability?
Buy when the capability is standard and the vendor meets your evidence, integration, security, and exit requirements. Build when the workflow creates differentiation or requires control that the market cannot provide.
That answer is intentionally not “always buy” or “always build.” An AI product is a stack of decisions. A company can buy the foundation model, retrieval service, and observability tools while building the workflow, approval logic, proprietary evaluation set, and customer experience.
Strategic Brief
The most resilient strategy is selective ownership: own what makes the workflow valuable and governable; rent replaceable infrastructure and commodity features.
Why is the usual cost comparison misleading?
Teams often compare a vendor subscription with model API charges. That excludes most of the cost on both sides.
A buy decision can include:
- licenses, usage overages, premium connectors, implementation, and support;
- security and legal review;
- data migration and knowledge preparation;
- workflow changes, training, and adoption;
- integration work around product limitations;
- the cost of a future export or replacement.
A build decision can include:
- product discovery, engineering, design, and domain review;
- model, retrieval, storage, orchestration, and observability;
- evaluations, security controls, incident response, and on-call;
- continuous adaptation as models and business rules change;
- support, documentation, training, and governance.
The correct denominator is an accepted business outcome: a resolved case, qualified lead, reviewed contract, completed report, or approved action. Model cost per token and vendor price per seat are inputs, not the answer.
Compare value before choosing the delivery model
This model tests whether the workflow has enough value to justify either path. Use separate scenarios for a vendor and a custom build with their own implementation and run costs.
Planning model, not a financial forecast. Replace time saved with measured throughput, margin, loss avoidance, or revenue when those outcomes are more defensible.
What should the business build itself?
Ownership is valuable when it protects a strategic capability, not because custom software feels sophisticated.
Usually retain control of:
- the definition of the workflow and its decision rights;
- the proprietary data and knowledge relationships that improve the task;
- evaluation cases derived from real operating conditions;
- the rules that govern access, approvals, escalation, and audit;
- outcome telemetry that connects system behavior to business results;
- portability of data, instructions, and integrations.
These assets compound. A vendor can change its model or user interface, but your company should not lose the ability to define what “good” means.
Build more of the application when experience design is part of the product, the workflow crosses several internal systems, the task changes frequently, the unit economics reward optimization, or customer trust requires stronger control.
What should the business buy?
Buy capabilities that are expensive to reproduce and do not create unique advantage:
- foundation model inference;
- standard document parsing and speech services;
- established identity, logging, and infrastructure;
- common productivity features;
- connectors that a vendor can maintain more efficiently;
- commodity model routing or safety layers, provided they remain observable.
Buying can accelerate learning. It can also let a small company operate a capable system without creating an internal platform team. The condition is evidence: the product must work on your cases, with your permissions, at your expected volume.
Select the economic and strategic situation
The same feature can deserve a different sourcing decision depending on differentiation, integration depth, and switching cost.
Buy a governed product
Summarization, drafting, and meeting assistance rarely justify a custom application when standard products meet data and administration requirements.
Run a cohort trial with adoption, accepted-output, and support metrics before signing a broad license.
Unused seats and weak change management can make a low unit price expensive.
How should vendors be evaluated?
Evaluate the working system, not a slide deck.
Task performance
Run representative cases, including ambiguity, missing information, policy conflicts, and adversarial inputs. Measure task success, unsupported claims, abstention, consistency, and reviewer effort. Keep the test set under your control.
Data control
Document what the product collects, where it is processed, how long it is retained, who can access it, whether it trains any model, and how deletion works across backups and derived indexes. Confirm the answers in the contract and architecture.
Integration and identity
Verify single sign-on, role mapping, document permissions, audit export, API limits, webhook behavior, and failure recovery. A product that ignores source-system permissions can create a new data exposure even if the model itself is secure.
Economics
Model cost at expected adoption, peak volume, longer context, premium models, connectors, storage, and support. Require usable consumption exports. Track cost per accepted outcome after launch.
Exit
Specify export formats, deletion certificates, transition support, and the treatment of prompts, evaluations, feedback, configurations, and logs. An exit plan that covers only uploaded documents is incomplete.
Inspect the risks hidden inside a sourcing decision
Choose a risk to see the minimum evidence an owner should require before making the capability operationally critical.
A provider update changes output behavior, increasing rework or customer harm without a visible outage.
Accepted-output rate drops by case type after a model, prompt, or product release.
Maintain external regression evaluations, version visibility, release notices, and a rollback or provider-switch mechanism.
How do you run a credible proof of value?
Use a fixed evaluation window and pre-agreed decision criteria.
- Select one workflow and a limited user cohort.
- Capture the current baseline before enabling the product.
- Create a representative test set the vendor has not optimized against.
- Configure the minimum required data and integrations.
- Measure quality, adoption, review effort, latency, incidents, and full cost.
- Interview users about changed behavior, not general satisfaction.
- Decide to buy, build, combine, narrow, or stop.
Do not let a successful demonstration automatically become a multi-year purchase. A proof of value validates assumptions. Procurement should follow only if the operating evidence and contract preserve the required control.
What is a durable hybrid architecture?
A durable approach separates replaceable providers from business-owned logic:
- A user or system submits a business task.
- An orchestration layer applies identity, policy, and the task contract.
- Approved data services retrieve authorized context.
- One or more purchased models perform bounded inference.
- Deterministic services validate structure and policy.
- High-consequence actions require approval or strict authorization.
- Logs, evaluations, costs, and outcomes flow into company-controlled telemetry.
This is not abstraction for its own sake. It creates the option to change a model, retrieval service, or vendor product without redefining the business process.
The executive decision rule
Build-versus-buy is a portfolio decision:
- Buy speed for commodity capability.
- Build control around differentiated workflows.
- Own the evidence that proves quality and value.
- Preserve the ability to leave.
- Revisit the boundary as the market and your operating maturity change.
The best decision is not the one with the fewest vendors or the most custom code. It is the one that gives the business the required outcome, control, and option value at a defensible unit cost.