TL;DR: Most enterprise AI strategies get the build-vs-buy-vs-partner call backwards because they treat it as a procurement exercise instead of a strategic posture. The default heuristic — “build if strategic, buy if commodity” — collapses under AI’s actual economics, where capabilities drift toward commodity in 18 months and the real cost of in-house talent eats the build case alive. The correct frame applies four lenses in order: durability of advantage, depth of data moat, realistic cost of in-house talent, and commodity drift timeline. Apply them together and a capability that looked like a build becomes a partner — often the most defensible posture of the three.
Why the standard heuristic fails for AI
Most leaders inherit a build-vs-buy framework that was designed for ERP systems and CRM platforms. It asks a single question: is this capability strategic or commoditized? Strategic capabilities get built. Commodity capabilities get bought. The logic is clean, the slides write themselves, and the answer is almost always wrong for AI.
What I have seen in my work is that AI capabilities do not sit still on the strategic-to-commodity axis. A foundation model that was a defensible moat eighteen months ago is now a line item on a vendor’s pricing page. An AI feature that looked commodity at pilot becomes a strategic differentiator at scale — but only if you own the data flywheel underneath it. The procurement frame cannot hold these dynamics, because it treats the decision as a snapshot. AI requires a posture.
The reframe is this: build, buy, and partner are not procurement options. They are strategic postures that determine where your organization absorbs cost, where it concentrates risk, and where it accumulates advantage over time. Get the posture wrong and the procurement details will not save you.
The three postures, and what each one is actually betting
Before applying the lenses, the three options need crisper definitions than the procurement frame allows. Each is a different bet about cost, control, and time.
Posture | What it commits you to | What you are betting | Where it fails |
|---|---|---|---|
Build | Owning the capability end-to-end — model, data pipeline, application layer, and the team that maintains it | The capability creates durable advantage, you can retain the talent, and ownership pays back over a multi-year horizon | Talent reality at month fourteen, or commoditization at the model layer |
Buy | Licensing a capability from a vendor and integrating it into your workflows | The capability is mature, the vendor will not commoditize you out of your own advantage, and switching costs remain manageable | The capability turns strategic and you have no moat underneath it |
Partner | Co-developing with a vendor, research lab, or systems integrator under terms that give you preferential access, joint IP, or roadmap influence | You can borrow capability you cannot yet build while developing the muscle to eventually own it | The "partnership" degrades into a vendor MSA with a discount |
The mistake I see most often is treating partner as a synonym for buy with a longer contract. It is not. A real partnership reshapes both sides. If your partnership is a master services agreement with a discount and a quarterly business review, you have bought, not partnered.
With the three postures defined, the four lenses determine which one compounds for a given capability.
Lens one: durability of advantage
The first question is whether the capability creates an advantage that will still be defensible in 36 months. Most AI capabilities will not.
Durability is not the same as importance. A capability can be critical to your business and entirely undurable as a source of advantage. Customer-service summarization is critical and undurable — every competitor will have equivalent capability inside two years, because the underlying models are converging fast and the workflows are standardizing across vendors. Conversely, a capability can look mundane and be deeply durable if it is wrapped around proprietary data, regulated workflows, or relationships that cannot be replicated.
The test I use is the Porter five-forces lens applied to AI specifically: can a well-funded competitor replicate this capability within 24 months using publicly available models and a competent team? If the answer is yes, the capability is not durable and should not be built. Buy or partner instead, and concentrate your build investment where the answer is no.
The pattern I have seen at scale: organizations build the wrong things because “strategic” gets conflated with “important to us.” Important is not the bar. Defensible is the bar.
Lens two: depth of data moat
If lens one says the advantage might be durable, lens two asks what it is anchored to. The answer is almost always data — and almost always weaker data than executives believe.
Every executive I talk to believes they have a data moat. Most do not. A data moat is not a large volume of data. It is data that is (1) proprietary to your operations, (2) generated as a byproduct of activities competitors cannot easily replicate, and (3) directly improves the capability’s performance in a way that compounds over time. Foundational scaling-laws research and the broader work coming out of the foundation-model labs make clear that generic data is rapidly becoming a commodity input. Specific, operationally-generated, hard-to-replicate data is what creates lasting advantage.
If the capability runs on data your vendor also has access to from your competitors, you do not have a moat — you have a shared input. Buy the capability and stop pretending. If the capability runs on data only you can produce, and that data makes the capability measurably better over time, you have a build case worth defending.
The second-order effect to watch: a moat that exists today can be eroded by your own vendor relationships. If you feed proprietary data into a vendor’s training pipeline without contractual carve-outs, you are subsidizing your competitors’ future capability. I have watched organizations build a real moat operationally and then surrender it through procurement language no one read carefully.
Lens three: the realistic cost of in-house talent
A durable advantage and a deep moat still do not produce a build option. They produce a build option — one that requires the talent to execute. This is the lens executives consistently underestimate, and where most build cases fall apart.
The market for senior AI engineering and ML research talent is not a normal labor market. Total compensation for senior practitioners at competitive firms has moved well past what most enterprises can match without restructuring their entire compensation philosophy. And the talent you need is not just expensive — it is concentrated, mobile, and increasingly selective about the problems it will work on.
The honest math:
-
Team shape: 8–15 people across engineering, applied ML, MLOps, and product
-
Fully-loaded cost: $4M–$8M per year in major North American markets, before infrastructure
-
Duration of intactness required: 24–36 months for the build to compound
-
Attrition assumption: the senior anchor leaves around month fourteen unless leadership invests directly in retention
If you cannot honestly commit to that staffing profile — and to the leadership bandwidth required to retain it — you do not have a build option. You have a partner option you have not admitted to yet.
What I have seen in practice: organizations announce a build, hire two-thirds of the team, lose the senior anchor at month fourteen, and quietly migrate to a vendor solution at month twenty while still calling the program “in-house.” This is the most expensive outcome of all three postures.
Lens four: commodity drift timeline
The final lens asks how long the underlying capability will remain non-trivial to acquire — and what posture you should hold on the other side of that drift.
AI capabilities do not commoditize on a predictable schedule, but the direction is consistent. The pattern across the last three years: capabilities that required custom model work in year one are available as API features in year two and embedded in horizontal SaaS by year three. Document understanding, conversational summarization, structured extraction, code generation, and basic agent workflows have all followed this curve, with OECD analysis on AI diffusion documenting accelerating commoditization across enterprise software categories.
The strategic implication is sharper than most leaders accept: if a capability is on a 24-month drift timeline, building it for proprietary advantage is a losing bet unless your data moat is deep enough to keep the proprietary version measurably better than the commodity version after drift completes. In most cases, it is not.
The right posture for capabilities on a fast drift timeline is partner now, buy at maturity, and reserve build investment for the layer above the commoditizing capability — the workflow, the data flywheel, or the integration that the commodity inputs cannot replicate.
Applying the four lenses: a worked example
The four lenses are not a scoring rubric. They are a posture-determination tool, applied in order. The answer typically emerges before you reach the fourth.
Capability under evaluation: AI-driven dynamic pricing for a specialty B2B distribution business.
Lens 1 — Durability of advantage. Can a well-funded competitor replicate this within 24 months using publicly available models and a competent team? No. The pricing logic depends on 15 years of customer-specific contract terms, regional logistics constraints, and supplier rebate structures no competitor has access to. Durability: HIGH.
Lens 2 — Depth of data moat. Is the data proprietary, operationally generated, and compounding? Pricing data is generated by 40,000 transactions per day across 12,000 SKUs and 8,000 customer accounts. It cannot be replicated by a vendor or a competitor and improves model performance monotonically as transaction volume accumulates. Moat: DEEP.
Lens 3 — Realistic cost of in-house talent. Can we credibly commit to 8–15 senior practitioners at $4M–$8M per year for 24–36 months, with the leadership bandwidth to retain them? We have one senior ML lead and three mid-level practitioners. Compensation is benchmarked to general engineering, not specialized AI. To build credibly we would need to restructure comp and recruit a senior anchor. Honest answer: not without a 9-month talent buildout. Talent reality: PARTIAL.
Lens 4 — Commodity drift timeline. How fast does the underlying capability commoditize, and what remains proprietary after drift? Foundation models for pricing optimization are commoditizing at the standard 24-month pace to API parity. What remains proprietary is the data flywheel and the integration with our ERP and contract-management systems. Drift: 24 months at the model layer; durable at the workflow layer.
Resulting posture. Partner for the model and inference layer — preferential access, contractual data carve-outs, joint roadmap influence. Build the workflow, data pipeline, and integration layer in-house, where the moat is deep and the talent requirement is achievable. Do not classify this as a pure build; that classification will not survive the talent reality at month fourteen.
The worksheet works because it forces the conversation past “is this strategic” and into the four questions that actually determine which posture compounds.
Framing the classification for the board
Once the posture is determined, it has to survive contact with the board. The board does not need to see the worksheet — they need to see the posture, the reasoning, and the second-order effects you have planned for.
A defensible board framing has four parts:
-
Posture statement. “We are partnering on the model layer and building the workflow layer for [capability].”
-
Durability and moat rationale. Two sentences on why this capability creates durable advantage and what the data moat consists of.
-
Talent and cost commitment. The honest staffing profile and the multi-year commitment, not a one-year budget request.
-
Drift posture. What changes when the underlying capability commoditizes, and how the partnership and build structure protect the advantage on the other side of that drift.
Boards do not punish executives for partnering. They punish executives for surprises. A clear posture with named second-order effects is more defensible than a build case dressed up as strategy.
Four failure modes that break the framework in practice
Even a correctly applied framework can fail in execution. Four patterns recur across the engagements I have seen, and each one looks reasonable in the moment.
The “strategic ambiguity” build. Leadership cannot quite articulate why the capability is durable, but it feels strategic, so it gets classified as build. Twelve months in, the team is understaffed, the moat is undefined, and the build becomes a sunk-cost defense rather than a strategic asset. Fix: if you cannot answer lens one in a single declarative sentence, the capability is not a build.
The “partner as buy with a discount” trap. The organization wants the optics of partnership without the structural commitment — no joint IP, no roadmap influence, no contractual data protection. The relationship degrades into a standard vendor engagement and the strategic posture evaporates. Fix: a real partnership has structural terms that reshape both parties. If yours does not, call it what it is.
The “drift denial” build. The executive sponsor refuses to accept that the underlying capability will commoditize on a 24-month horizon, and the build is sized for a world where the moat lives at the model layer. When drift completes, the organization is left with an expensive in-house version of a commodity capability. Fix: assume drift, and concentrate build investment in the layer that survives it.
The “diffused governance” failure. Decision authority for build-vs-buy-vs-partner is split across procurement, IT, data science, and the business unit, with no single owner accountable for the posture or its second-order effects. Each function optimizes for its local incentive — procurement for vendor cost, IT for integration risk, data science for technical scope, the business unit for time-to-value — and the resulting posture is the unweighted average of four conflicting objectives. Twelve months in, when the build understaffs, the moat leaks through unreviewed procurement language, or the partner relationship degrades into a vendor SLA, the accountability is nowhere because it was shared everywhere. Fix: name a single executive owner for the posture before any RFP, contract, or hiring requisition opens — with explicit authority across the four lenses, a standing review cadence tied to drift and talent milestones, and accountability for the second-order effects when they arrive.
These failure modes share a root cause: the decision was made on momentum rather than on the four lenses applied honestly, and no single owner was on the hook when the second-order effects arrived.
The framework, in one line
The build-vs-buy-vs-partner decision is not a procurement question — it is a posture question, and the posture that compounds is almost never the one that feels strategic at the demo. Apply the four lenses, accept the talent reality, and concentrate build investment where the moat is deep and the drift is slow. Everything else is a partner case waiting to be named correctly.
FAQ
Q: How is this framework different from the standard build-vs-buy heuristic? A: The standard heuristic asks one question — is the capability strategic or commodity. This framework applies four lenses simultaneously, because AI capabilities do not sit still on the strategic-to-commodity axis. The four lenses (durability, data moat, talent reality, drift timeline) produce a posture rather than a procurement classification.
Q: When should an enterprise partner on AI rather than build or buy? A: Partner when the capability is on a fast commodity drift timeline (under 24 months) but the workflow, integration, or data layer above it is durable. Partner also when you have a deep data moat but cannot credibly staff the build at senior levels. Partnership lets you borrow capability while building the institutional muscle to own the durable parts.
Q: How quickly do AI capabilities drift toward commodity? A: The observed pattern across the last three years is roughly 24 months from custom model work to API feature to embedded SaaS capability. The drift is faster for capabilities that depend primarily on foundation models and slower for capabilities that depend on proprietary data or regulated workflows.
Q: What is the realistic cost of an in-house AI build team? A: A credible team for a non-trivial AI capability is 8–15 senior practitioners across engineering, applied ML, MLOps, and product. Fully-loaded cost in major North American markets typically runs $4M–$8M per year before infrastructure, and the team needs to stay intact for 24–36 months for the build to compound.
Q: How do I know if I actually have a data moat? A: A real data moat is proprietary, operationally generated, and compounding. If a vendor can acquire equivalent data from your competitors, or if the capability runs on data that is generally available, you do not have a moat — you have a shared input. The test is whether your data measurably improves the capability over time in a way competitors cannot replicate.
Q: How do I frame a partner classification for a board that wants to hear “we are building this”? A: Lead with the posture and the second-order effects, not the procurement decision. Boards punish surprises, not partnerships. A clear partnership with named structural terms (joint IP, contractual data protection, roadmap influence), a defensible drift posture, and a single named executive owner is more credible than a build case the talent reality will not support.
This kind of thinking lands in your inbox every week. Operator’s Log is my weekly field report from inside AI — what’s shipping, what’s stalling, and what I’d bet on next. Free. 5-minute read. Subscribe →