Build vs buy (and blend)

0:00 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.

0:37 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.

1:06 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.

1:39 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.

2:19 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.

2:52 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.

3:39 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.

4:06 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.

4:44 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.

5:15 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.

5:45 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.

6:13 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.

6:43 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.

7:40 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.

8:12 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.