You need a thing your company doesn't have yet, a payments engine, a sales team in a new country, a recommendation model, a warehouse. Three doors open. You can build it in-house, buy it (a vendor, a licence, or an outright acquisition), or partner to share the load. The instinct is to reach for a spreadsheet and pick the cheapest door. That instinct is usually wrong, because the cheapest door this quarter is often the one that quietly hands away the thing you most needed to keep.

The quick version

  • It's a boundary decision, not a price comparison. You're choosing where your company ends and the market begins, so the real question is who should bear the risk and control of this capability, not which option is cheapest now.
  • Build what's core; buy what's a commodity; partner where neither owns the whole answer. Build defends a capability that wins you customers. Buy or rent the things many firms can supply equally well.
  • The deciding factor is "asset specificity." The more tailored, hard-to-redeploy and easy-to-hold-hostage the thing is, the more it belongs inside your walls. Generic, swappable things belong in the market.
  • Match the mechanism to the goal. Acquire for scale and control; ally for speed, learning and entering the unknown. Most messes come from using one when you needed the other.

The idea in depth: where your company ends

Start with the oldest question in the field. In 1937 a young British economist, Ronald Coase, asked something that sounds almost naive: if markets are so efficient, why do firms exist at all? Why doesn't every person just contract for each task on the open market? His answer, in "The Nature of the Firm", the paper the Nobel committee cited when it awarded him the economics prize in 1991, was that using the market is not free. Finding a supplier, negotiating terms, writing and policing the contract: each carries a cost. A firm exists because, past a certain point, it is cheaper to organise an activity inside a hierarchy than to keep buying it through the market.

That reframes your decision entirely. Build / buy / partner is not a procurement choice. It is a choice about where to draw your company's boundary, which activities sit inside the firm under your direction, and which you leave to the market. So stop leading with "what does this cost?" Lead with "should this live inside our walls or outside them?" Cost answers the second question; it can't replace it.

flowchart TD
    A(["A capability you need"]) --> B{"Is it a source of
competitive advantage?"}
    B -->|"Yes, customers choose us for it"| C(["Lean toward BUILD"])
    B -->|"No, many firms supply it equally"| D{"Is it highly specific &
hard to switch away from?"}
    D -->|"Generic, swappable"| E(["Lean toward BUY"])
    D -->|"Specific, but we lack it now"| F(["Lean toward PARTNER"])
A first-pass sort: advantage points to build, commodities to buy, and shared or unproven ground to partnership. Leaders Loop

Why "specificity" decides more than cost

Coase opened the door; Oliver Williamson built the room behind it. Across Markets and Hierarchies (1975) and The Economic Institutions of Capitalism (1985), work that earned him a share of the 2009 Nobel Prize in economics, alongside Elinor Ostrom, Williamson gave managers the variable that actually predicts which door to take: asset specificity. An asset is "specific" when it's been tailored to one particular relationship and can't easily be redeployed elsewhere. A generic laptop is not specific; a tooling line built to one customer's exact dimensions is highly specific.

Specificity matters because of what happens after you sign. The moment you depend on a supplier for something only they have tailored to you, you are exposed: they can renegotiate, raise prices, or under-invest, and switching is painful or impossible. Williamson's prescription, distilled, is to try the market first, try a hybrid (a contract or alliance) next, and bring an activity inside the firm only when the hazards of doing it any other way are too high. The practical test, then: before you outsource or partner, ask how badly you'd be held hostage if the other side turned predatory. Low specificity, low hazard → buy it. High specificity, high hazard → build or tightly govern it. This is the spine of capital allocation philosophy & discipline applied to capability: you're allocating not just money but control.

The cheapest door this quarter is often the one that quietly hands away the thing you most needed to keep.

An honest limitation: transaction-cost reasoning is a lens, not a formula. Specificity and "hold-up risk" are real but hard to measure, and critics note the theory can over-explain integration after the fact, it's easier to justify a decision with it than to predict one. Treat it as a structured way to surface the right risks, then add what it underweights: speed to market, how fast the field is changing, and whether you have the talent to build well. A model that says build is no help if you can't recruit the engineers.

Build for advantage, buy for commodity, partner for the unknown

The second lens is strategic, not economic. In their 1990 Harvard Business Review article "The Core Competence of the Corporation," C. K. Prahalad and Gary Hamel argued that a company should think of itself as a portfolio of competencies, the deep, collective skills that let it deliver value customers can't easily get elsewhere, rather than a portfolio of products. The discipline that follows is sharp: protect and build the few things that are genuinely your edge, and don't sink scarce attention into things any competent vendor supplies just as well.

Run each capability through one question, then: does doing this ourselves win or keep customers? If yes, it's a candidate to build, because outsourcing your edge slowly hollows you out. If it's table-stakes plumbing, the kind of thing where "as good as everyone else's" is fine, buy it and spend the saved energy on what differentiates you. The trap Prahalad and Hamel warned about is outsourcing something cheap today that turns out to have been a competence you needed tomorrow. Use portfolio management & investment prioritisation to keep that map honest as the business changes.

Partnering is the third door, and it's the one leaders most often misuse, typically by acquiring something they should have allied with, or vice versa. In their 2004 HBR article "When to Ally and When to Acquire," Jeffrey Dyer, Prashant Kale and Harbir Singh found that firms which match the mechanism to the goal, Cisco being their headline example, grow faster than rivals who don't. Their rule of thumb: acquisitions suit synergies you get from owning and combining hard assets at scale, where you need full control; alliances suit softer synergies, new markets and uncertain bets, where flexibility and a graceful exit matter more than control. Buying a company outright to capture its people often backfires, acquisitions can trigger a talent exodus, so if the value walks out on two legs, an alliance frequently protects it better.

flowchart LR
    A(["You want this capability"]) --> B{"Need full control
& scale economics?"}
    B -->|"Yes"| C(["ACQUIRE / BUILD
own it outright"])
    B -->|"No"| D{"High uncertainty,
or value is in people?"}
    D -->|"Yes"| E(["ALLY
flexibility, learning, exit"])
    D -->|"No, it's generic"| F(["CONTRACT / BUY
a vendor relationship"])
Control and certainty sort the mechanism: own it when you need control and scale; ally when the ground is uncertain or the value is human. Leaders Loop

A worked example

Illustrative figures, the numbers below are made up to show the reasoning, not real benchmarks.

A mid-size logistics firm wants a route-optimisation engine. Three doors:

  • Build. A small team, say 18 months and ~$2.4m to a first version, then ongoing cost to keep it improving. Full control; the algorithm could become a genuine edge.
  • Buy. Licence a mature SaaS engine at ~$300k a year. Live in weeks. But it's the same engine your competitors can licence, and your routing data flows through it.
  • Partner. A revenue-share pilot with an optimisation start-up that wants your real-world data to train on, and you want their models.

The spreadsheet screams "buy", $300k beats $2.4m and you're live in a month. But run the two lenses. Specificity: routing tuned to your depots, fleet and contracts is highly specific, and pushing your data through a shared vendor is a hold-up risk if they later raise prices or get bought by a rival. Competence: if delivery speed is how you beat bigger carriers, the engine is your edge, exactly the thing Prahalad and Hamel say not to rent. That reframes it: buy a generic engine for the generic part (mapping, traffic data, commodities, low hazard), but treat the optimisation layer that touches your edge as build-or-partner. The start-up alliance looks attractive precisely because the future is uncertain, you learn whether the capability is real and keep an exit, instead of betting $2.4m up front. Pressure-test the build path with a proper NPV / payback comparison and a business case, but the boundary question, not the cost, told you which capability deserved the build.

Frequently asked questions

Isn't building almost always more expensive and slower?

Up front, usually yes, that's exactly why buying tempts you. The cost that doesn't show up on the quote is dependence: the price increases, the strategic constraint, the inability to differentiate once you're locked to a shared vendor. Build is worth the premium only when the capability is core or highly specific. For everything else, the vendor's economies of scale genuinely beat your in-house effort, and you should let them.

How do I tell "core" from "commodity" in practice?

Ask three questions. Do customers choose us partly because of this? Would a rival find it hard to copy? Is it tightly woven into other things we do well? Three yeses points to build; three noes points to buy. The honest answer is often "the platform is commodity, but one thin layer of it is our edge", split the decision along that seam rather than building or buying the whole stack.

When should I prefer a partnership over an acquisition?

When the value is uncertain, fast-moving, or carried by people rather than assets. Dyer, Kale and Singh's guidance is to ally when you want flexibility, learning and a clean exit, and to acquire when you need control and scale you can only get by owning. If buying a company means its best people quit, you've paid a premium to destroy the very thing you wanted, an alliance can keep that value alive while you both decide whether to go further.

Doesn't AI make "build" cheap enough to build everything now?

It lowers the cost of building, which genuinely shifts some commodity decisions back toward build, but it doesn't change the logic. Cheaper construction makes the boundary question more important, not less, because you can now build things you'll later regret owning and maintaining. Still ask: is this core, is it specific, and do we want to carry it forever? A thing that's cheap to build can still be expensive to keep.

What's the single most common mistake?

Optimising the quarter and forgetting the boundary. Teams outsource something cheap that turns out to be a competence, or build something generic out of pride that a vendor would have run better for a tenth of the effort. Both come from comparing prices instead of asking where the capability belongs. Decide the boundary first; let cost decide between options within that boundary.

Related in the Toolkit

Where to go next