When to build or buy an AI feature

For most teams evaluating an AI feature, the first build decision is about the application around the model. Start with a managed model if it meets your requirements. Own the workflow, customer experience, data access, and tests that make the feature useful.

Consider self-hosting when a specific constraint or measured cost justifies the operating work. Training a foundation model is a much larger decision and should not be bundled into a conversation about whether to use an API.

TL;DR Buy a finished product when it fits. Build on a managed model API when your workflow needs custom software. Host a model yourself only when a requirement or measured saving justifies the extra work.

Separate the choices hidden inside "build"

Choice	What you own	What remains outside your control
Buy a finished product	Configuration and integration	Product roadmap and supported workflow
Build on a model API	Application, policy, data flow, evaluations	Model service and provider terms
Self-host an available model	Model hosting and application	Base-model capabilities and license terms
Fine-tune a model	Training examples and adapted behavior	Limits of the base model and hosting arrangement
Train a foundation model	Training program and model development	Hardware supply and other external dependencies

You can combine these routes. An application might buy transcription, use a managed language model, and own a custom approval workflow. None of those decisions requires handing over ownership of the product.

Buy a finished product when the workflow fits

Evaluate the actual job before commissioning a custom replacement. Can the product support your permissions, required integrations, and exception handling? Can you export the data? Does it fit the way customers work?

Check what happens when the normal process fails. Try a missing record, a canceled request, and an integration outage. Confirm who can diagnose the failure and what the vendor will support.

If the standard product passes those checks, custom software needs a concrete reason to exist. A distinctive interface alone may not justify maintaining a parallel integration stack.

Build the application when the workflow matters

A model API can sit inside a substantial product. The value may be reliable access to customer data, a carefully designed review step, or an action the user can verify and reverse.

Those parts need ownership regardless of the model vendor. Anthropic's guide recommends simple, composable patterns rather than adding complexity prematurely. Apply that to procurement too: buy a capable model service while building only the application behavior your requirements demand.

Do not assume that a provider-operated model transfers responsibility for your results. You still own authentication, authorization, appropriate logging, and quality monitoring.

Self-host only after measuring the constraint

Hosting a model yourself may make sense if a managed service cannot meet your data or customization requirements, or if measured usage makes it cheaper. There is no universal token volume where this becomes cheaper.

Compare hardware utilization, redundancy, staffing, deployment time, monitoring, and upgrade work. Include the cost of idle capacity and the capacity needed at peak demand. A low hourly GPU price does not tell you what a completed task will cost.

Test the candidate on your real workload with the intended latency and concurrency. Check commercial-use terms and any restrictions on redistribution or fine-tuned derivatives. Owning a deployment does not remove license obligations.

Use fine-tuning for a demonstrated behavior gap

Before fine-tuning, establish a baseline with clear instructions and suitable context. Identify the recurring behavior you need to change and assemble representative examples.

Fine-tuning can affect behavior and knowledge, but it is not a dependable substitute for fetching a current account balance or an updated policy. Those facts need a current, authorized source. The retrieval-versus-context decision remains separate.

Evaluate the adapted model on held-out cases, including tasks that already worked. OpenAI's evaluation guidance provides a useful framework for comparing changes against a baseline.

Leave yourself a practical exit

Keep prompts, evaluations, business rules, and data definitions under your control. Record provider-specific behavior instead of pretending all APIs are interchangeable.

Test an alternative only where continuity requires it. A common interface can simplify a switch, but different models still need evaluation. Include that work in the cost forecast.

Write down which part you plan to build or run yourself and the requirement that makes it necessary. If the requirement is still vague, prototype the smallest application first and use the result to decide.

Sources

• Anthropic: Building effective agents
• OpenAI: Evaluation best practices
• OpenAI: API pricing