A firm is a strange thing if you think about it. Inside its walls, work gets allocated by managers giving instructions; outside, the same work gets allocated by prices and contracts. So where, exactly, should the wall be? Should you employ the developer or hire the agency? Run your own warehouse or pay a 3PL? The question feels operational. It is actually one of the deepest questions in economics, and there is a real theory that tells you how to answer it.

The quick version

  • Using the open market isn't free. Finding suppliers, negotiating, writing contracts and policing them all cost time and money, these are transaction costs.
  • Firms exist because, for some activities, it's cheaper to command work internally than to keep buying it on the market. That's Coase's 1937 insight.
  • The deciding factor isn't usually price. It's asset specificity, how custom and relationship-locked the thing is. The more specific and the harder to write an airtight contract, the more you should lean toward owning it.
  • So "make vs buy" becomes: which side governs this transaction at lower total cost, your org chart, or a contract?

The idea in depth

Coase: markets aren't free, so firms exist

In 1937 a young British economist named Ronald Coase asked a question his discipline had quietly ignored: if markets are such efficient ways to coordinate, why is so much economic activity organised inside firms, where a manager simply tells people what to do? His answer, in "The Nature of the Firm" (Economica, 1937), reshaped the field and earned him the Nobel Memorial Prize in Economic Sciences in 1991.

Using the market, Coase pointed out, carries its own costs that have nothing to do with the price of the good itself. You have to discover who to buy from, negotiate a price, draft a contract, and then check the other side actually delivers. Those are transaction costs. When they get high enough, it becomes cheaper to pull the activity inside the firm and coordinate it by authority rather than by repeated bargaining. A firm, in Coase's framing, grows exactly to the point where the cost of organising one more transaction internally equals the cost of buying that transaction on the open market.

So the move is: stop comparing only the quoted prices. When you weigh insourcing against outsourcing, add the full cost of the relationship, sourcing, negotiating, contracting, monitoring, and the cost of getting it wrong. The cheaper invoice can hide the more expensive transaction.

flowchart TD
    A(["A transaction you need done"]) --> B{"Cost to coordinate it
via the market?"}
    B -->|"Low: clear spec,
many suppliers"| C("Buy it
(use a contract)")
    B -->|"High: hard to spec,
few suppliers, much haggling"| D("Make it
(bring it in-house)")
    C --> E(["Lowest total cost
of getting the work done"])
    D --> E
Coase's logic: pick the side, market or firm, that governs the transaction at lower total cost. Leaders Loop

Williamson: it's about how custom and locked-in the thing is

Coase named the force but left the practical question open: which transactions belong inside, and which belong on the market? Oliver Williamson spent his career answering that, and won the 2009 Nobel Prize "for his analysis of economic governance, especially the boundaries of the firm" (shared with Elinor Ostrom). In "The Economics of Organization: The Transaction Cost Approach" (American Journal of Sociology, 1981), and earlier in Markets and Hierarchies (1975), he made the transaction the basic unit of analysis and asked which "governance structure", market or hierarchy, handles each one most cheaply.

Williamson started from two facts about real people. We have bounded rationality (we can't foresee or write down every future contingency), and some parties act with opportunism (they'll exploit a gap in the contract if it pays). Those two facts make contracts leaky. How dangerous the leak is depends mostly on one variable: asset specificity, how much the value of an investment is tied to this particular relationship and would be lost outside it.

When an asset is generic (an off-the-shelf laptop, a commodity part), you stay on the market: if a supplier misbehaves, you switch, and the discipline of competition protects you. But when one side has to make a heavily customised, relationship-specific investment, both parties get locked together. Now the other side can threaten to walk and squeeze you for the value of that sunk investment, the "hold-up problem." Markets handle hold-up badly. Ownership handles it well, because you can't hold up yourself. Williamson's rule of thumb: the more specific the asset, the more frequent the transaction, and the more uncertain the future, the more it should sit inside the firm.

Generic and easy to spec? Buy it. Custom, locked-in and hard to contract? Own it.

So the move is: before you outsource, ask how relationship-specific the work is. If a vendor would have to build something only useful to you, bespoke tooling, deep knowledge of your systems, a custom integration, you're creating a future hold-up. Either keep it in-house, or invest up front in the contract and the relationship that will govern it.

flowchart LR
    A(["Asset specificity:
how custom & locked-in?"]) --> B(["Low specificity"])
    A --> C(["High specificity"])
    B --> D("Market governs it well
BUY / outsource")
    C --> E("Hold-up risk is real
MAKE / own it")
    F(["Uncertainty + frequency"]) -.->|"raise the stakes"| E
Williamson's discriminating-alignment idea: match each transaction to the governance structure that fits its specificity, uncertainty and frequency. Leaders Loop

Where this breaks down, name the limitation

The canonical illustration of hold-up is the 1926 merger of car-body maker Fisher Body into General Motors, told by Benjamin Klein, Robert Crawford and Armen Alchian in "Vertical Integration, Appropriable Rents, and the Competitive Contracting Process" (Journal of Law and Economics, 1978). The story is tidy: Fisher made specific investments, allegedly held GM up, and GM responded by buying it. But the tidiness is contested, around 2000 several economists, Coase among them, reexamined the historical record and argued the hold-up never really happened that way. The lesson for a leader is the honest one: transaction-cost economics is a powerful lens, not a law. It tells you where to look (specificity, contractibility, hold-up) and which way the pressure points. It does not hand you a number. Pair it with first-principles thinking about your specific situation rather than reaching for the textbook case, see first principles vs heuristics vs analogical reasoning for why the analogy alone can mislead.

A worked example

Imagine you run product at a mid-sized SaaS company and you need a new billing system. Two real options: license a mature billing platform (buy), or build and run your own (make). The vendor quotes a tidy annual fee that looks far cheaper than the engineers it would take to build it. On price alone, buy wins.

Now run it through the lens. How specific is this? Standard subscription billing is fairly generic, plenty of vendors do it, the spec is well understood, and switching is annoying but possible. That points to buy. But suppose your pricing is genuinely unusual: usage-metered, with bespoke enterprise contracts and revenue-sharing logic no off-the-shelf tool supports. Now the vendor has to build deep, customised logic that's worthless to anyone else. That's high asset specificity, and a hold-up waiting to happen. The day you depend on their custom work, the next renewal "negotiation" tilts their way.

The figures below are illustrative. Say the vendor's licence is £120k a year and building it costs £400k up front plus £90k a year to run. Naively, buy wins for the first three years. But add the transaction costs of the custom path: integration work that only ever serves this vendor, a renewal where the price jumps because they know you can't easily leave, and roadmap lost to working around their limits. Suddenly the "expensive" build, which you control and can't be held up on, is the cheaper transaction over the life of the system.

The decision flips not because the engineers got cheaper, but because the work got specific. That is the whole theory, doing its job on a Tuesday. (And notice this is also a reversible-vs-irreversible call: outsourcing a generic function is easy to undo; building a specific one is not, which is exactly why specificity deserves the up-front thought.)

Frequently asked questions

Isn't this just "outsource the non-core stuff"?

Close, but sharper. "Keep your core competence" (Prahalad & Hamel's framing) is a useful heuristic, but it doesn't tell you why, and it misfires on edge cases. Transaction-cost economics gives the underlying reason: own what is specific and hard to contract for; buy what is generic and easy to police. Often that lines up with "core," but not always, some core-adjacent work is perfectly buyable, and some boring back-office work is so entangled with your systems that owning it is cheaper.

Does this mean low transaction costs are always good?

For the buyer of a given transaction, lower costs are good. But falling transaction costs across the economy reshape what firms are. As contracting, search and monitoring get cheaper, think APIs, marketplaces, cloud infrastructure, better legal templates, the efficient boundary of the firm moves outward, and more activity that used to be done in-house gets bought instead. That's a large part of why modern companies are smaller and more "unbundled" than the vertically integrated giants of the last century.

How do I actually estimate a transaction cost I can't see on an invoice?

You won't get a precise number, and you shouldn't pretend to. Instead, score the drivers. For each option ask: how custom is what they'd build for us (specificity)? How predictable is the work (uncertainty)? How often do we transact (frequency)? How easy is it to write a contract that covers the bad cases (contractibility)? High specificity, high uncertainty, high frequency and low contractibility all push toward "make." It's a structured judgement, not a spreadsheet, but a far better judgement than comparing quotes.

Where does this connect to incentives and pricing?

Directly. Transaction-cost thinking is microeconomics applied to organisation design, it's about how people respond to the incentives a contract or a hierarchy creates. If you want the foundation underneath it, see microeconomics: marginal analysis & incentives, and the related idea of market failure, which is the broader family of problems that hold-up belongs to.

Is "buy" the same as "outsource"?

For this lens, yes, "make vs buy," "in-house vs outsource," and "hierarchy vs market" are three names for the same decision. The unit of analysis is the transaction, and the only question is which governance structure handles it at lower total cost. Whether that shows up as an employee, a vendor, a joint venture or a contractor is downstream of the answer.

Related in the Toolkit

Where to go next