---
title: "Build vs buy (and blend) — Building AI Products & Workflows"
description: "The options For most AI features, there are four broad paths: 1. Use AI features inside tools you already have. Many office suites, CRMs, help desks and…"
url: https://optimizeall.com/learn/building-ai-products-and-workflows/build-vs-buy
updated: 2026-10-05
---

Building AI Products & Workflows · Prototyping and build vs buy · lesson 5 of 18 · 12 min

# Build vs buy (and blend)

## The options

For most AI features, there are four broad paths:

1. **Use AI features inside tools you already have.** Many office suites, CRMs, help desks and analytics platforms now include AI features.
2. **Buy a specialised AI product.** Vertical tools for specific jobs (contract review, support automation, meeting notes, sales intelligence).
3. **Build on model APIs or platforms.** Your team combines model APIs, retrieval, tools and your own interface or workflow.
4. **Blend.** Buy the commodity parts, build the differentiating parts, connect them with integrations (including open standards such as MCP).

## Decision criteria

| Question | Leans buy | Leans build |
|---|---|---|
| Is this capability a differentiator for us? | No, it's table stakes | Yes, it's core to our value |
| Does a good product exist for our exact need? | Yes | No, or poorly fitting |
| How specific are our data and workflows? | Standard | Highly specific |
| Do we have engineering and ML/AI ops capacity? | Limited | Strong |
| Time to value needed | Weeks | Can invest months |
| Control over data, models and roadmap | Vendor terms acceptable | Need full control |
| Scale and unit economics | Low-medium volume | High volume where per-seat pricing is costly |

No single row decides; weigh them together.

## Hidden costs of building

- Evaluation, monitoring and maintenance, which continue after launch.
- Keeping up with model changes and deprecations.
- Security reviews, access control and compliance work.
- UX work to make AI outputs usable and trustworthy.
- On-call ownership when things break.

A useful rule of thumb: the initial prototype is a small fraction of the total cost of ownership.

## Hidden costs of buying

- Integration and data plumbing.
- Per-seat or per-usage pricing that grows with adoption.
- Limited customisation; workflows bend to the tool.
- Vendor risk: roadmap changes, acquisition, shutdown, price increases.
- Data terms: where data is processed and stored, retention, whether it is used for training.
- Lock-in: exporting your data, prompts and configurations may be hard.

## Evaluating vendors

Treat vendor selection like a benchmark (see evaluation lessons):

- **Test on your data:** run your evaluation set through a trial, rather than relying on demos.
- **Security and privacy:** certifications, data residency options, retention and training policies, sub-processors, incident history.
- **Controls:** admin settings, permissions, audit logs, SSO.
- **Transparency:** which underlying models are used, how changes are communicated, evaluation evidence.
- **Commercials:** pricing model, caps, exit terms, data export.
- **Fit:** integrations with your systems; support in your regions and languages.

## Worked example: support automation

A regional e-commerce company compares:

- **Buy:** a help desk's built-in AI agent. Fast to launch, good for common intents, limited control over tone and integrations with their custom order system.
- **Build:** an assistant on model APIs with retrieval over their help centre and tools for their order system. Full control, requires two engineers plus ongoing ownership.

Evaluation on 200 real tickets shows the built-in agent handles common intents well but struggles with Arabic tone and custom order data. Decision: **blend**. Use the help desk AI for triage and English FAQs, and build a small service that exposes order data as tools, which the help desk's AI can call (the vendor supports external tool integrations). Differentiating logic stays in-house; commodity parts are bought.

## Revisit regularly

The market changes fast. What required building a year ago may now be a feature in your existing tools, and vice versa. Revisit build/buy decisions at contract renewals and major model shifts.

## Hands-on: a weighted decision matrix and a vendor bake-off

**1. Score the options.** Agree weights with stakeholders before scoring, so the matrix is not reverse-engineered to a favourite.

```python
# 1-5 scores per option; weights sum to 1.0
WEIGHTS = {"differentiation_fit": 0.20, "quality_on_our_eval": 0.25, "time_to_value": 0.10,
           "data_control_and_terms": 0.15, "integration_effort": 0.10, "3yr_total_cost": 0.10,
           "vendor_or_team_risk": 0.10}
OPTIONS = {
    "Built-in help-desk AI": {"differentiation_fit": 2, "quality_on_our_eval": 3, "time_to_value": 5,
                               "data_control_and_terms": 3, "integration_effort": 4, "3yr_total_cost": 4, "vendor_or_team_risk": 3},
    "Build on model API":    {"differentiation_fit": 5, "quality_on_our_eval": 4, "time_to_value": 2,
                               "data_control_and_terms": 5, "integration_effort": 2, "3yr_total_cost": 3, "vendor_or_team_risk": 3},
    "Blend (buy + own tools)": {"differentiation_fit": 4, "quality_on_our_eval": 4, "time_to_value": 4,
                               "data_control_and_terms": 4, "integration_effort": 3, "3yr_total_cost": 4, "vendor_or_team_risk": 4},
}
for name, s in sorted(OPTIONS.items(), key=lambda kv: -sum(WEIGHTS[k] * v for k, v in kv[1].items())):
    print(f"{sum(WEIGHTS[k] * v for k, v in s.items()):.2f}  {name}")
```

The **quality** row must come from running your own evaluation set, not from demos.

**2. Run a vendor bake-off.** Ask each shortlisted vendor for a trial or sandbox and run the same 100 to 200 real (appropriately anonymised) cases through each. Record: pass rate on your rubric, failure categories, latency, cost per case at your expected volume, and how easy it was to get outputs into your systems.

**3. Send a focused due-diligence questionnaire** (copy and adapt):

```text
1. Which underlying models do you use, and how do you notify customers of model changes? Can we pin versions?
2. Is our data used to train or improve any model? Default and contractual position?
3. Retention of inputs, outputs and logs; can we set shorter retention or zero retention?
4. Data residency options (e.g. UK, EU, UAE, KSA) and full sub-processor list.
5. Security certifications and latest independent audit reports; incident history and notification SLA.
6. Admin controls: SSO, roles, audit logs, data export, API access.
7. Integration: APIs, webhooks, MCP support or other open standards for tools and data.
8. Commercials: pricing model, usage caps, overage handling, price-change notice, exit and data export terms.
9. Evidence: evaluation results on tasks like ours; customer references in our sector and region.
```

Keep the answers with the decision record; you will need them at renewal.

## Going further

Design for replaceability: keep prompts, evaluation sets, retrieval indexes and business logic in assets you own, and connect vendors through standard interfaces. This preserves negotiating power and lets you switch components as better options emerge.

## Video lecture: Build vs buy (and blend)

Lecture coming soon · 15 chapters · about 9 minutes. Read the full transcript below.

1. Build, buy or blend
2. Analogy: cook, order in, or both
3. Four paths
4. Decision criteria
5. Hidden costs
6. Evaluate vendors on your data
7. Simple example: meeting notes
8. Worked example: blend
9. Business example (illustrative)
10. Hands-on in the lesson
11. Common mistakes
12. How you'll know you decided well
13. Watch me do it: matrix + due diligence
14. Recap
15. Try this now (1 hour + vendor reply)

## Lecture transcript

### Build, buy or blend

Every AI feature eventually hits the same fork in the road. Do we use the AI already inside our tools, buy a specialised product, build our own on model APIs, or mix them? Choose wrong, and you either spend a year building a commodity, or lock your most differentiating process inside someone else's roadmap. In this lesson you'll learn the four paths, the criteria that decide between them, the hidden costs on both sides, and how to run a vendor bake-off on your own data.

### Analogy: cook, order in, or both

Here's an analogy. Build versus buy is like deciding whether to cook, order in, or do both. For your signature dish, the one guests come for, you cook it yourself. For bread, you buy from a good bakery. Nobody bakes their own bread just to prove they can. Your differentiating workflows are the signature dish. Commodity features, like meeting notes or basic FAQs, are the bread.

### Four paths

Path one: use AI features in tools you already have. Office suites, CRMs, help desks and analytics platforms now ship them. Path two: buy a specialised AI product for a specific job, like contract review, support automation or meeting notes. Path three: build on model APIs, combining models, retrieval, tools and your own interface. Path four: blend. Buy the commodity parts, build the differentiating parts, and connect them through integrations, increasingly through open standards like MCP.

### Decision criteria

How do you decide? Ask whether the capability is a differentiator for you or table stakes. Whether a good product exists for your exact need. How specific your data and workflows are. Whether you have engineering and AI operations capacity. How fast you need value. How much control you need over data, models and roadmap. And what the unit economics look like at your volume, because per-seat pricing can become expensive at scale. No single question decides it. Weigh them together, and agree the weights before you score, so nobody reverse-engineers the answer.

### Hidden costs

Both sides hide costs. Building means evaluation, monitoring and maintenance that never stop, keeping up with model changes, security and compliance work, UX work to make outputs trustworthy, and on-call ownership. The first prototype is a small fraction of total cost. Buying means integration and data plumbing, pricing that grows with adoption, workflows bending to the tool, vendor roadmap and pricing changes, data terms to scrutinise, and lock-in that makes exporting prompts, data and configurations hard.

### Evaluate vendors on your data

Evaluate vendors like a benchmark, not a demo. Run your own evaluation set through a trial. Check security and privacy: certifications, data residency, retention, whether data trains models, and sub-processors. Check controls like single sign-on, roles and audit logs. Ask which underlying models they use and how they announce changes. Examine pricing, caps and exit terms. And check integrations and support in your regions and languages. Here's a real-world shaped case. A regional e-commerce company tested its help desk's built-in AI agent against a custom build on two hundred real tickets. The built-in agent handled common English intents well, but struggled with Arabic tone and their custom order data.

### Simple example: meeting notes

A simple example. A ten-person accounting firm wants AI meeting notes. Their video-call platform already includes AI summaries, their clients accept it, and the data terms are fine. Building their own would take weeks and deliver nothing better. Decision: use the built-in feature, and spend the saved time on something that actually differentiates them, like drafting client tax-planning memos from their own templates.

### Worked example: blend

Their decision? Blend. The help desk's AI handles triage and English FAQs. The company builds a small service that exposes order data as tools, which the help desk's AI can call, because the vendor supports external tool integrations. Differentiating logic stays in-house, commodity parts are bought. And they design for replaceability: prompts, evaluation sets, retrieval indexes and business logic live in assets they own, connected through standard interfaces, so they can switch components when something better appears. Revisit the decision at every renewal and major model shift.

### Business example (illustrative)

Illustrative numbers for the e-commerce blend. On two hundred real tickets, the built-in agent resolved about seventy percent of English FAQs well, but only about forty percent of Arabic and order-specific tickets. The blend, with order tools the help desk's AI can call, lifted the order-specific group to about seventy-five percent. Building only the order tools took two engineers about three weeks, versus the months a full custom assistant would have needed.

### Hands-on in the lesson

In the hands-on section you'll find a weighted decision matrix in a few lines of Python, where the quality row must come from your own evaluation, a step-by-step vendor bake-off on one to two hundred real cases, and a nine-question due-diligence questionnaire covering model changes, training on your data, retention, residency in places like the UK, EU, UAE and KSA, certifications, admin controls, integrations including MCP, commercials and evidence.

### Common mistakes

Common mistakes. Deciding from a sales demo instead of your own evaluation set. Comparing a vendor's price with only your developers' time, ignoring maintenance. Ignoring exit terms until you want to leave. Building because it's more interesting. And forgetting the blend option, which is often the right answer: buy the commodity, build the parts that make you different, and connect them through open standards.

### How you'll know you decided well

How will you know you decided well? Twelve months later, the bought parts are quietly doing their job without surprise costs, the built parts are where you've invested your improvements, and you could swap a vendor in weeks if you had to, because your prompts, evaluation sets and business logic live in assets you own. If any of that isn't true, revisit the decision at the next renewal.

### Watch me do it: matrix + due diligence

Watch me do it. I open the decision matrix. First, the weights: quality on our evaluation gets a quarter, differentiation fit a fifth, data control fifteen percent, and the rest shared. I agree these with the operations director before scoring anything. Next, the scores for three options. The quality scores come from our two-hundred-ticket bake-off, not demos. I run it, and the blend scores highest, then build, then the built-in agent. Then I open the due diligence questionnaire and send it to the help desk vendor. Two answers come back vague: whether we can pin model versions, and the exact sub-processor list. I ask again in writing and note both in the decision record. Finally, I write the recommendation: blend, with three reasons, and a renewal date when we'll revisit it.

### Recap

To recap: there are four paths: existing tools, specialised products, building on APIs, or blending. Weigh differentiation, fit, data specificity, capacity, time, control and economics. Count the hidden costs on both sides. Evaluate vendors on your own data, and design for replaceability. Your next step is to fill in the decision matrix for one use case and recommend build, buy or blend with three reasons. Next module: choosing models and designing the architecture.

### Try this now (1 hour + vendor reply)

Try this now. Pick one AI feature you're considering. Fill in the weighted decision matrix for three options: existing tool, specialised product, and build or blend. Leave the quality row empty until you've run at least twenty real cases through each option you can access. Then send the nine due-diligence questions to your top vendor and note which answers are vague.

## Key takeaways

- Four paths: AI in existing tools, specialised products, building on APIs, or blending.
- Weigh differentiation, fit, data specificity, team capacity, time to value, control and unit economics.
- Account for hidden costs on both sides: maintenance and ownership for builds; pricing, lock-in and data terms for buys.
- Evaluate vendors on your own data and design for replaceability.

## Try it

For one use case, fill in the build-vs-buy table with your organisation's answers and recommend build, buy or blend with three reasons.

- [Previous: Prototyping with AI coding tools and app builders](https://optimizeall.com/learn/building-ai-products-and-workflows/prototyping-with-ai-coding-tools)
- [Next: Choosing models and an architecture that can change](https://optimizeall.com/learn/building-ai-products-and-workflows/choosing-models-and-architecture)
- [All lessons of Building AI Products & Workflows](https://optimizeall.com/learn/building-ai-products-and-workflows)