Buy an AI feature when the job is common across companies, a vendor's product handles your real data well in a trial, and its data terms are acceptable. Build when the feature is part of what customers pay you for, needs deep access to your own systems, or needs quality control a vendor won't give you. Either way, the build vs. buy decision for AI features is rarely about the model: building usually means buying model access and owning everything around it.
Build vs. buy for AI features is a range of options
| Option | You own | The vendor owns | Usually fits when |
|---|---|---|---|
| AI features in tools you already use | Configuration and access settings | Model, prompts, evaluation, updates | The job lives inside that tool, such as ticket summaries in a helpdesk |
| A dedicated AI product | Integration, rollout, data choices | The product and its quality | The job is common and the product works on your data |
| Build on a model API | Prompts, retrieval, tools, evaluation, monitoring | The model and its hosting | The feature is specific to your product or data |
| Build on a self-hosted open-weight model | All of the above, plus serving and model updates | Nothing beyond the published weights | Data can't leave your infrastructure, or volume justifies running it |
| Train or fine-tune your own model | Training data and the training pipeline | Possibly the base model | A narrow task where the options above fall short |
For features that answer from your own documents, retrieval and careful prompts come before training, as explained in choosing between RAG and fine-tuning.
When buying an AI feature is the better choice
Buy when the job looks the same at every company. Meeting transcription, call summaries, code completion and first-pass ticket triage are examples. A vendor selling that feature widely sees more variations of the problem than your team will.
Buying also fits when nobody on your side can run a large language model (LLM) system after launch. Someone has to review its output, handle model changes and answer for its failures. A vendor doing that work is safer than a system nobody maintains.
When building on a model API makes sense
Build when one or more of these is true:
- The feature is your product. If competitors can buy the same tool, it can't set you apart.
- It needs your permission model. A tool that indexes a shared drive through one service account can show any file to any user.
- It needs to act inside your systems, such as creating orders or updating records, with checks only your code can enforce.
- You need to define what correct output means, test against your own cases and decide when a model upgrade ships.
- Data rules limit where prompts and documents can go, for example residency or retention requirements a vendor can't meet.
Usage shape matters too. Vendor products are often licensed per seat, while model APIs bill by tokens. Heavy use by a few people and light use by everyone come out very differently under those two models, so estimate both at your expected volume.
The costs of building that a prototype hides
A working prototype on a model API can take days. It also skips the work that comes after launch:
- An evaluation set built from real examples, and someone who reviews production output against it. Our post on evaluating LLM output quality in production covers what that involves.
- Logging, monitoring and alerts for truncation, refusals and format failures.
- Maintenance of prompts, retrieval settings and document indexes as your data changes.
- Model retirements. Anthropic's model deprecation policy promises at least 60 days' notice for publicly released models, and requests to a retired model fail. Every migration means rerunning your tests and fixing what changed.
- Security testing for prompt injection and data exposure, repeated after significant changes.
- An owner who answers when the feature misbehaves on a weekend.
Count these as a yearly cost before you compare. If you can't staff them, the build option isn't really available yet.
The risks of buying that a demo hides
Vendor demos run on clean examples. The risks show up in contracts and in month six.
- Data use. OWASP's entry on LLM supply chain risks lists unclear terms and privacy policies as a route for sensitive data into model training, and recommends vetting them.
- Model changes you didn't approve. If the product doesn't let you pin a model version, output can shift without a release note.
- No way to test. If you can't export outputs or run your own cases, you can't measure quality yourself.
- Lock-in. Prompts, configurations and indexed content may not leave with you.
AI features that appear inside tools you already pay for, sometimes switched on by default, are purchases too. Our guide to finding shadow AI shows how to spot them.
Questions to ask an AI vendor before you buy
- Is our data used to train or improve any model, and where does the contract say so?
- How long are prompts, outputs and uploaded files kept, and can we shorten that?
- Which subprocessors and model providers handle our data, and in which regions?
- Do you notify customers before changing the underlying model?
- Can we run our own test cases and export the results?
- Does the product respect permissions from the source systems it connects to?
- What can we export if we leave, and in what format?
Vague answers to the first three are a reason to stop. Vague answers to the rest are a reason to negotiate.
How to decide build vs. buy for an AI feature in two weeks
- Write down the job. Inputs, outputs, users, and what a wrong answer costs the business.
- Collect a shared test set. Real examples with the result a domain expert expects, including the awkward cases.
- Trial one or two vendors on it. Use your data, not their demo data, under an agreement that covers it.
- Timebox a thin build. One engineer, a model API and the same test set. The goal is a comparison, not a product.
- Score both options on one sheet. Quality on the test set, data terms, integration effort, the yearly running work listed above and how hard it is to leave.
- Record the decision and what would reverse it. For example: "We buy, and revisit if the vendor can't pin model versions by next renewal."
A hypothetical example: a software company's helpdesk vendor offers AI-drafted replies. They work well for billing questions but can't read order status from the company's own system. The company buys for billing and builds a narrow feature for order questions on a model API.
Common build vs. buy mistakes
- Comparing a vendor's polished demo with your own rough prototype, both on easy examples.
- Building a commodity feature because the engineering team finds it interesting.
- Buying a product and assuming the vendor handles evaluation and security for your use case.
- Spreading one provider's SDK across the codebase, so switching later means a rewrite.
- Deciding once and never revisiting. Vendor products, model pricing and your volume all change.
Keep an exit option either way
If you build, route model calls through one internal interface so a provider switch touches one module. Keep your test set and logs in your own storage, so any migration can be tested.
If you buy, get export rights and change notifications into the contract. The National Institute of Standards and Technology (NIST) AI Risk Management Framework Playbook covers this under GOVERN 6.1 and 6.2: policies for third-party AI risk, and contingency processes for failures in third-party AI systems.
If you want senior help making the call, our fractional AI CTO work includes architecture and vendor recommendations, with model, platform and build-vs-buy choices made on evidence.
Frequently asked questions
Which costs less over time, building or buying an AI feature?
It depends on volume, the number of users and what the feature takes to run. Buying usually costs less to start. Building can come out ahead at high volume, but compare honestly only after counting evaluation, monitoring and maintenance work.
Can we start with a vendor and build later?
Yes. Use the vendor period to collect real examples and learn what good output looks like. Make sure you can export them, because they become the test set for your own build.
Should we self-host an open-weight model instead of using an API?
Self-hosting gives you control over data location and model versions. It also makes you responsible for serving, scaling, security patches and model updates. Choose it when data rules or volume require it.
Who should own the build vs. buy decision?
A technical leader who will still be accountable after launch, working with the business owner of the feature. Security and legal should review data terms before any trial with real data.