Build vs. Buy vs. Partner

Every AI use case in your portfolio forces the same fork in the road: do you build it yourself, buy it off the shelf, or partner with a vendor to co-develop it? This is not a technical decision — it is a capital-allocation and competitive-strategy decision, and it belongs to you.

The stakes are higher than they look. Build the wrong things and you burn scarce talent and years of effort on capabilities your competitors simply licensed for a fraction of the cost. Buy the wrong things and you commoditize the very capability that could have been your moat. The discipline is knowing — use case by use case — which is which.

Start from the strategic truth that frames everything: as foundation models converge and the cost of raw intelligence collapses, the technology itself is no longer the differentiator. Gartner now calls foundation models a strategic commodity; the cost to run a model at a given quality level fell roughly 280x in about 18 months (Stanford HAI AI Index, 2025). When the engine is a commodity, the question stops being can we get the capability and becomes should we own it, or rent it?

BCG frames the sourcing decision on two axes — and only two. Plot each use case once and the quadrant tells you the default play.

• Vertical axis — value potential vs. competitors (Low to High): How much competitive advantage does winning this use case actually create? Is it a true differentiator, or table stakes everyone will have?
• Horizontal axis — differentiated data access vs. AI vendors (Low to High): Do you hold proprietary data, workflow, or relationships that a vendor cannot replicate — something that would make your version meaningfully better than what they could sell to anyone?

The two axes produce four quadrants and three plays:

The logic is simple to govern: build only when value is high AND your data edge is high. Lose either axis and the economics tip toward buy or partner. The top-right quadrant — high value, highly differentiated data — is the only place a build is the obvious answer, and for most enterprises only a handful of use cases ever land there.

The two-by-two gives you the quadrant; here is how to read each play as a leader, with the default decision logic a non-technical executive can apply.

The governing principle: the bulk of your portfolio should be buy; partner is the workhorse for the valuable middle; build is reserved for the few moat-creating cases. If your roadmap is mostly builds, that is a red flag, not a sign of ambition.

This is not just a framework preference — the data is stark, and it should reset your default.

MIT Project NANDA, "The GenAI Divide: State of AI in Business 2025" (released ~Aug 2025): purchasing AI tools from specialized vendors or through partnerships succeeded roughly 67% of the time, while internal builds succeeded at about one-third of that rate. Based on 300+ deployments, 52 case studies, and 153 leadership surveys.

Read that again: a bought or partnered solution was roughly three times more likely to succeed than one your team built. (These are time-stamped 2025 findings — confirm the current figures at the live source before you cite them to a board.)

The same study delivered the headline that frames the whole AI-value debate: about 95% of enterprise generative-AI pilots delivered no measurable P&L return, against an estimated $30–40B of enterprise spend. The cause was not weak models — it was adoption and integration mismanagement. Internal builds fail disproportionately precisely because they load the hardest, least-glamorous work — integration, change management, maintenance — onto teams already stretched thin.

The practical implication: make buy-or-partner your default and require a use case to earn the right to be built by clearing the top-right quadrant of the two-by-two. Build should be the exception you can defend, not the reflex you reach for.

Two structural forces — both baked into the BCG framework — explain why internal builds underperform. Neither is about your team's competence; both are about market reality.

1. AI talent scarcity. Seasoned AI professionals are rare and expensive, and they cluster at the vendors and model labs that can pay for and excite them. For most enterprises, assembling and retaining a team capable of building, securing, and maintaining production AI is a multi-year talent fight you are structurally positioned to lose. Buying or partnering lets you rent that scarce talent by the seat or the engagement instead of competing for it.

2. Data-model interdependence. The dependency runs both ways. Vendors hold the talent and the models; you hold the data. A vendor's model is only as useful to you as the proprietary data and workflow you feed it — and your data is only valuable when paired with capable models and tooling. That two-way dependency is precisely what makes partner the natural play for the valuable middle: it pairs the vendor's scarce talent with your irreplaceable data, with neither side able to capture the full value alone.

This also reframes data as the real asset. As models commoditize, the one thing competitors cannot buy, borrow, or replicate is your data. A build only makes sense when it compounds that asset — for example, a data flywheel where every interaction generates feedback data that improves the product, an advantage that grows over time. Absent a proprietary data edge, an internal build is just an expensive, slow way to reproduce something a vendor already sells.

You do not need to evaluate the architecture; you need to ask the questions that force the right quadrant. Use these to govern any sourcing proposal that crosses your desk.

To place the use case on the two-by-two:

• Is this capability available off the shelf to all our competitors (commodity — buy), or does it compound a unique asset we own (differentiator — consider build)?
• What is the proprietary data, workflow, or relationship that would make our version meaningfully better than what a vendor sells to everyone?
• If we win this perfectly, how much competitive advantage does it actually create — is it a moat or table stakes?

To pressure-test a proposed build:

• Why can't we buy or partner for this? What specifically breaks if we don't own it?
• Do we have — and can we retain — the talent to build, secure, and maintain this for years, not just ship a demo?
• What is the fully-loaded cost after go-live — maintenance, integration, monitoring, compliance — not just the build?

To govern a buy or partner:

• Who owns the data and the model outputs in this contract — us or the vendor? (For partner deals, this is the whole game.)
• What is our exit and portability plan if this vendor fails, is breached, or is acquired? How locked in are we?
• Are we buying seats for the whole workforce on day one — and how will we avoid the 30–40% that typically goes unused within 90 days?