Transaction Costs

Why do transaction costs matter to founders?#

They explain why customers do not buy the cheapest option. A buyer pays more for trust, standardised terms, financing, fast onboarding, and reliable support because those lower the total cost of completing and sustaining the exchange. If you are losing on price and winning on nothing else, you have not lowered anyone's transaction costs.

They are the actual product of most marketplaces and platforms. Search, reputation, identity, escrow, standard contracts, logistics, and dispute resolution are transaction-cost products. That is what a marketplace sells. It is also why a take rate is not automatically extractive: 10% can be cheaper for the customer than 2% if it raises fill rate, collection, and dispute outcomes enough.

They set the make-vs-buy boundary — for you and for your customer. Every build, buy, or partner decision is a governance choice. So is every customer's decision to keep doing it in spreadsheets. Your wedge is usually the layer of their stack you can remove most credibly.

They determine whether vertical integration pays. Bringing a function inside reduces repeated bargaining and hold-up risk when assets are specialised. It also adds fixed cost, weaker incentives, and managerial load. The comparison is between two imperfect governance forms, never between a market and a frictionless ideal.

They are where pricing power quietly comes from — and where regulation arrives. When you become the cheapest way to complete an exchange, you can charge for it. When you become the only way, someone eventually caps the fee.

How do you choose a governance form?#

Williamson's contribution was to make this a match between transaction attributes and governance structure rather than a matter of taste.

Asset specificity is the variable founders skip. It is the degree to which an investment loses value outside this particular relationship. A generic S3 bucket has near-zero specificity. A proprietary schema you built to a single vendor's API, staffed by two engineers who only know that vendor's model, has very high specificity. Williamson's "fundamental transformation" is the moment a competitive bidding situation becomes a bilateral one: once you have made the specific investment, the vendor's incentives change, because your alternatives got worse. That is hold-up, and it is why a vendor's renewal quote can rise well above the market rate you originally won.

The practical sequence:

1. Define the unit of exchange. What changes hands, how often, and what does success look like? A one-time commodity purchase is a different problem from a multi-year data-processing relationship.
2. Score the three attributes — frequency, uncertainty, specificity — with evidence, not vibes.
3. Map the stack using the table above, with an owner and a proxy metric for each layer.
4. Enumerate governance options: spot market, long-term contract, managed marketplace, partnership, managed service, full integration.
5. Price the exit before you price the entry. Ask what a forced migration costs and how likely it is; that number decides more make-vs-buy calls than the licence fee does.
6. Write down the decision criteria before choosing, then review actuals — integration hours, incidents, disputes, renewal quotes — against them.

Worked example: make versus buy for a data pipeline#

A 25-person startup needs a specialised data pipeline. Two options:

Expected first-year vendor cost:

$90,000 + $20,000 + $35,000 + $15,000 + (0.15 × $100,000) = $175,000

Now the part that most build-vs-buy models get wrong. The answer depends entirely on whether the engineer is an incremental hire or a reallocation, and the two cases give opposite conclusions.

Case A — the engineer is a new hire. The $150,000 is genuinely incremental, and there is no displaced project because the person did not exist before:

$150,000 + $25,000 + $30,000 = $205,000

Buying wins by $30,000.

Case B — an existing engineer is reallocated off a product project expected to produce $80,000 of first-year contribution. The salary is paid in both branches, so it is common to the comparison and cancels. The real cost of building is the forgone contribution:

$25,000 + $30,000 + $80,000 = $135,000

Building wins by $40,000.

The common error is to add the $150,000 salary and the $80,000 forgone contribution, producing $285,000 and a confident recommendation to buy. That double-counts the engineer: you cannot charge the same person's time to the model twice, once as payroll and once as opportunity cost. It overstates the internal option by $150,000 relative to Case B and reverses the decision.

Now add asset specificity. Suppose Vendor A requires a proprietary integration, so a forced migration would cost $600,000 rather than $100,000:

$90,000 + $20,000 + $35,000 + $15,000 + (0.15 × $600,000) = $250,000

Building is now cheaper in both framings — by $45,000 in Case A and $115,000 in Case B. Working backwards, in Case A the break-even migration cost is $300,000: below that, buy; above it, build or insist on a modular architecture and a contractual exit path.

Two caveats before anyone puts this in a board deck. First, the 0.15 × $600,000 term is an expected value, which implicitly assumes risk neutrality. If an unplanned $600,000 migration would consume a quarter of your runway, the certainty-equivalent cost is higher than $90,000 and the model understates the case for modularity. Second, every input except the licence fee is an estimate. Carry them as ranges, and treat the break-even migration cost as the output that actually matters — it is far more stable than any single point estimate.

What are the common mistakes?#

• Equating transaction cost with the payment fee. The fee is the layer with an invoice. Search, evaluation, integration, monitoring, enforcement, and exit rarely have one.
• Assuming internal coordination is free. Hierarchy has its own costs: management attention, weak internal incentives, fixed capacity, and slower adaptation. Coase's point cuts both ways.
• Double-counting labour in the make-vs-buy model. Decide whether the engineer is incremental or reallocated, then count either the salary or the forgone project — never both.
• Counting friction without a counterfactual. A cost is only meaningful relative to the next-best way of completing the same exchange. "This is annoying" is not a business case.
• Ignoring asset specificity until renewal. Specific investments are cheap to make and expensive to have made. Price the exit at signature, when you still have leverage.

When does transaction-cost reasoning break?#

It becomes unfalsifiable. Because transaction costs are unpriced, the framework can rationalise any organisational choice after the fact. The fix is procedural: record expected costs and decision criteria before selecting the governance form, then review actuals.

It implies false precision. Much of the stack is time, risk, and probability. A model with seven estimated inputs and one known input is not more accurate than a range; it is just more confident. Report the break-even, not the point estimate.

Technology moves the boundary underneath you. APIs, standardised contracts, identity services, and interoperability requirements lower external coordination costs; new security, privacy, and platform-conduct obligations raise them. A make-vs-buy answer has a shelf life.

The cheapest governance form can be strategically wrong. A vendor can lower this year's cost while keeping critical customer or process knowledge outside the firm. Treat learning and future optionality as explicit benefits with a stated mechanism, not as a vague override.

Bilateral dependence is not always bad. Williamson's framework is about safeguards, not avoidance. A specific investment protected by credible commitments — mutual hostages, staged milestones, escrow, portability guarantees — can beat both the spot market and full integration.