Build vs Buy vs Wrap: the AI Decision Matrix Every PM Needs

Every AI project, at about week three, runs into the same question: "Should we train our own model, pay a specialised vendor, or wrap an off-the-shelf API with our brand on it?" The team has three factions. Engineering wants to build. Procurement wants to buy. The founder wants to wrap. A week of meetings goes by. Nobody has a framework. The decision gets made by whoever has the loudest voice in the room.

This post is the framework. Three options, five criteria, one decision in an afternoon. I'll walk through each of the three paths, explain when each one wins honestly, and give you the matrix you can print out and hand to your next steering committee. No code. No vendor pitches. Just the real trade-offs.

---

The three paths, in plain English

First, the definitions. These words get used loosely, and teams argue about "build vs buy" without agreeing on what each one means.

Build. Your team trains or fine-tunes a model from scratch, or from a large open-weight base. You own the weights. You run the inference. You are responsible for the data, the training pipeline, the evaluation, the deployment, the monitoring. Your output is a model that belongs to you and doesn't exist anywhere else.

Buy. You pay a specialised vendor whose entire product is the AI capability you want. They have trained the model, they run it, they tune it, they handle the operational complexity. You integrate their API or their SaaS into your product. You are a customer of their AI, not a provider of one.

Wrap. You take a frontier API — Anthropic, OpenAI, Google — and build your product on top of it. You write prompts. You wire in retrieval. You design the user experience. You do not train anything; you orchestrate an existing general-purpose model to do the specific thing you need.

Three distinct shapes. Each has its own sweet spot. The single biggest mistake in this space is treating them as a linear scale — "wrap is beginner, buy is intermediate, build is advanced." They are not. They are different strategic postures, and the right one depends on what you're trying to do, not how sophisticated your team is.

---

The decision matrix

Five criteria, three options. For each row, I'll tell you which path the criterion favours and why.

Run your project through the five rows. Count which column wins most often. The column with three or more wins is almost always your answer. If it's split 2/2/1, you have a nuanced decision and you'll need to do the work in the rest of this post. If it's 5/0/0 in any column, you have a clear answer and you're wasting time debating it.

Three questions, three answers. Most projects land on "wrap" and that is not a failure mode — it is the correct answer more often than it gets credit for.

---

Why wrap is more often right than teams admit

Let me spend a minute on wrap, because it's the path teams most often feel embarrassed to pick, even when it's clearly the best choice.

When wrap wins:

• You have a product idea and you want to ship in a quarter, not a year.
• The capability you need is "a capable general model plus your specific instructions."
• Your moat is the product experience — the workflow, the data, the design, the brand, the distribution — not the model weights.
• Frontier APIs are priced in a range you can absorb at your expected volume.
• Model quality is improving fast enough that you'd rather "get the next model for free" than train your own.

Almost every successful consumer AI product in 2024-2026 is a wrap, and most of the successful B2B ones are too. Cursor wraps frontier APIs. Perplexity wraps them. Notion's AI features wrap them. The teams that treat "wrap" as the default posture ship faster, adapt to new models faster, and spend less on infrastructure than teams that try to build something custom out of pride.

The reason teams resist wrap is almost entirely political. "We're just an API wrapper" sounds embarrassing in a board meeting. "We trained our own model" sounds impressive. But the board isn't your customer. Your customer wants a product that works, and wraps often work better because they stand on the shoulders of the best models in the world without needing to reproduce any of that investment.

If you're instinctively avoiding wrap because it sounds too simple, stop. Check the matrix. If wrap wins, ship wrap and put the saved engineering time into the thing that actually makes your product different.

---

When build is actually the right call

Building your own model is the rarest of the three in 2026, and it's a huge commitment. It makes sense when:

• You have proprietary data nobody else can get. Medical images from your hospital network. Transcripts from your support centre. Sensor data from your fleet. The data is the asset; the model is how you monetise the asset.
• You're in a regulated environment where data can't leave your infrastructure. You may be forced to build even if a frontier API would be better on pure quality.
• Your use case needs a capability frontier models don't offer. This is rarer every year as frontier models catch up, but genuinely specialised problems still exist — domain-specific language, unique output formats, constraints the general models handle clumsily.
• You operate at massive scale and the economics of API calls stop working. Hundreds of billions of tokens per month. This is a small number of companies.
• You have a dedicated ML team you already fund for other reasons. Not "we'll hire some ML engineers" — a real, staffed, budgeted team.

Notice that "we want to say we built our own" is not on the list. Neither is "we don't want to be dependent on a vendor" — that's valid for real risk scenarios, but if you're worried about vendor lock-in, you have other, cheaper tools (abstraction layers, multi-vendor routing) before you commit to building.

When build is right, it is very right. When it isn't, it's a year of engineering spent recreating something you could have bought or wrapped in a week.

---

When buy is the middle path

Buy sits between build and wrap: you get specialised expertise without building it yourself, and you trade some of wrap's flexibility for a vendor's domain knowledge. The clean cases:

• Narrow specialised tasks where a dedicated vendor has trained specifically on your domain. Medical imaging, legal contract review, call centre analytics. The vendor has the data and the tuning; you benefit from years of their work.
• Compliance-heavy applications where the vendor handles certification. They've done the HIPAA work. They've done the SOC2. You piggyback on their compliance story instead of building your own.
• Capabilities you need now and expect to commoditise later. OCR is a classic example. You buy a vendor's OCR today and swap it out in two years when frontier models do it just as well.
• Use cases where quality matters more than integration flexibility. If "the best legal NER on the market" is non-negotiable and only one vendor has it, you buy it. Your integration pain is worth the quality.

Buy has two failure modes: vendor lock-in (the vendor raises prices, changes the API, or deprecates features you depend on) and capability drift (the vendor's specialised model stays at its original quality while frontier wraps get better around it). Both are real and both are why "buy everything" is not a strategy, only a per-capability decision.

---

The hybrid pattern that actually wins

Here is the pattern I see in the successful AI product companies I've worked with: wrap for the main capability, buy for one or two narrow specialised bits, build only when you have proprietary data and real moat.

A concrete example: a legal research product.

• Wrap frontier APIs for the general Q&A over case law.
• Buy a specialised legal NER vendor for extracting parties, dates, and case citations with high precision.
• Build a small custom classifier on top of the client's private case history, because the client's internal taxonomy is proprietary and nobody else has the data.

Three paths, one product. Each path picked because of specific criteria, not out of ideology. The hybrid is almost always better than any pure strategy.

The hybrid also gives you optionality. When frontier models get good enough to replace your NER vendor, you swap. When your proprietary classifier becomes a liability (new data, maintenance burden), you retrain or retire it. You don't lock yourself into a single strategic posture.

---

What NOT to use as a criterion

A short list of things people sometimes use to make this decision that are traps:

• "Building sounds more impressive." It is, to the wrong audience. Your customers don't care.
• "Wrap isn't a real product." Tell that to Cursor, Perplexity, and Notion.
• "We need an AI moat." Your moat is probably not the model. It's the product, the data, the distribution, or the brand. Build because the model is actually the moat, not because you want one.
• "We need to be vendor-independent." Vendor risk is real, but the first-line defences are abstraction layers and multi-vendor routing, not building your own model.
• "Our investors want us to build." Investors who insist on this don't understand the economics of modern AI. Politely educate them or find ones who do.
• "The engineering team wants to build." Respect the engineering excitement but don't let it set strategy. Engineering can build anything; picking the right thing to build is your job.

---

A specific worked example

Walk through the matrix for a typical case to see how it flows.

The project: a customer support assistant that reads your help docs and answers customer questions.

5/5 for wrap. Decision: wrap. Build a RAG-based assistant using a frontier API and your help docs. Use the engineering time saved to build a really good UX for verifying and editing AI outputs. Ship in a quarter.

The team that picks "wrap" here is six months ahead of the team that spent six months training a custom model for the same task.

---

The failure mode: "strategic confusion"

The most common way teams get this wrong isn't picking the wrong path — it's picking all three at once. A team decides to wrap now, build later, and buy a specialised component in the middle. Each decision is defensible. Together, they create strategic confusion: three integration patterns, three cost models, three vendor relationships, three eng teams with different contexts.

The fix: pick one primary posture and explicitly justify any exceptions. "We are a wrap-first product. Here are the two specific places we've bought specialised vendors and here is the specific reason for each." Write it down. Revisit quarterly. If you find yourself quietly accumulating exceptions, you have drifted and you should re-debate the primary posture.

Strategic clarity isn't about never deviating from a plan. It's about knowing which plan you're deviating from and why. Teams with this clarity ship; teams without it have design reviews that go in circles.

---

What just changed in your roadmap

• Run the five-row matrix on your next AI project this week. Write down which column wins each row. The column with three or more wins is almost always your answer.
• Default to wrap unless the matrix says otherwise. It's the right answer more often than it gets credit for, and it's often politically embarrassing for all the wrong reasons.
• Reserve "build" for cases where you have proprietary data, a real ML ops team, and a clear moat story. If any of those three is missing, you're not ready to build.
• Use buy selectively for narrow specialised components. Don't buy your whole stack from a vendor; do buy the specific piece where a specialised vendor is 10x better than frontier models.
• Write down your primary posture ("we are a wrap-first product") and any explicit exceptions. Revisit quarterly.
• Don't let political pressure ("investors want us to build") decide strategic posture. The matrix is the decision. The politics come after.
• Accept that the matrix may change over time as your data, team, and needs shift. Re-run annually.

Next post, P1.4, we close Module P1 with the most-ignored variable in AI product planning: the capability frontier. How to scope against what models will be able to do in six months, not just what they do today — without becoming dependent on vapour capabilities that never ship.

---

Course navigation

📚 AI for Product · Course Home — 20 posts, five modules.

---

Cover photo via Unsplash. This post is part of the AI for Product series.