Build vs. Buy vs. Partner

Why does the mode choice matter to founders?#

Founder and engineering time is the binding resource, and the spreadsheet omits it. An internal build looks cheap because the model counts salaries but not recruiting, management attention, security review, documentation, on-call, or — largest of all — the roadmap items displaced while the team builds infrastructure. Make the displaced roadmap explicit and name it.

Time to market is a cash number. Six months of delay when demand is ready, or when a fundraising milestone depends on shipped revenue, can exceed several years of licence fees. The reverse also holds: when the requirement is genuinely unclear, delaying an irreversible build preserves option value that a fast decision destroys.

Control is not binary, and ownership is a weak proxy for it. Service levels, audit rights, data residency, export formats, source escrow, subprocessor notice, price protection, termination assistance, and modular interfaces all create control without ownership. Meanwhile a "fully internal" system may depend on one cloud region, three open-source maintainers, and one engineer who understands it — ownership on paper, dependency in fact.

The choice can create or destroy a moat. Build where operating the capability produces learning that compounds into better customer outcomes or lower unit cost. Buy where the market supplies it competitively and the customer does not care who made it. Partner where someone else controls a bottleneck. The test is the same one used in Competitive Advantage and Moats, applied at component scale: what accumulates because we do this ourselves? If nothing accumulates, building is a cost decision, and usually a bad one.

How do you actually run the comparison?#

1. Write one specification before comparing anything#

Without a shared spec, teams compare an enterprise vendor to a prototype. Write down: the customer outcome and scope; required quality and availability; data sensitivity and compliance obligations; scale and peak load; integration surfaces; the launch deadline; acceptable supplier concentration; and continuity and exit requirements.

2. Classify the capability on two axes#

1. Does superior performance here materially move willingness to pay, retention, distribution, unit cost, or learning?
2. Is the requirement stable enough to commit to one solution?

High asset specificity — investment useful mainly inside this one relationship — demands stronger governance in whichever mode you pick. That is Williamson's point and it is the one most often skipped.

3. Calculate risk-adjusted lifecycle cost#

For each option j:

NPV cost_j = upfront_j
           + Σ (run cost_j,t / (1 + r)^t)
           + delay cost_j
           + expected risk cost_j
           + exit cost_j
           − option value_j

delay cost = months delayed
           × monthly contribution available at launch
           × probability demand is actually ready

Expected risk cost covers outages, migration, vendor price increases, partner underperformance, security incidents, overrun, and key-person loss. Two disciplines keep this honest: use named scenarios rather than a single probability-weighted number, and remember the overrun evidence — a symmetric ±20% band around your build estimate is not what the distribution looks like.

4. Score control and reversibility explicitly#

Record who controls each of: roadmap and prioritisation; customer and usage data; model or algorithm behaviour; intellectual property; pricing and packaging; uptime and incident response; distribution and account ownership; migration and termination.

Then ask the reversibility question directly: how many months, and how much cash, to change modes? A purchased component with clean data export is frequently more reversible than a bespoke internal system that one person understands. Quantify migration the way you would quantify a customer's — see Switching Costs.

5. Design the governance for the mode you chose#

• Buy: service levels with remedies, security evidence, audit rights, data location, subprocessor change notice, price protection, renewal notice period, documented export format, termination assistance, and a tested contingency.
• Partner: decision rights, investment obligations, exclusivity scope and duration, account ownership, economics, quality standards, data rights, IP, milestones, dispute resolution, and an unwind mechanism agreed while everyone is still friendly.
• Build: a named product owner, staffing plan, reliability budget, documentation standard, security review, an explicit maintenance commitment, and sunset criteria — the conditions under which you would stop.

Worked example: analytics for a Series A SaaS company#

A startup needs an analytics capability expected to support $70,000 per month of contribution once live. It compares three options over three years at a 10% discount rate. The three-year annuity factor is (1 − 1.10⁻³) / 0.10 = 2.4869.

Delay cost is months delayed × $70,000, assuming demand is ready at launch.

Build#

Up-front development                     $420,000
PV of run cost  $160,000 × 2.4869      = $397,904
Delay cost      8 months × $70,000     = $560,000
Expected overrun  20% × $250,000       =  $50,000
                                       -----------
Risk-adjusted lifecycle cost           $1,427,904

Buy#

Implementation                           $140,000
PV of run cost  $320,000 × 2.4869      = $795,808
Delay cost      2 months × $70,000     = $140,000
Price, continuity, and migration risk    $120,000
                                       -----------
Risk-adjusted lifecycle cost           $1,195,808

Partner#

Integration                              $220,000
PV of run cost  $320,000 × 2.4869      = $795,808
Delay cost      3 months × $70,000     = $210,000
Expected dependency cost                  $80,000
                                       -----------
Risk-adjusted lifecycle cost           $1,305,808

Buy wins the base case by $232,096 over build. If analytics is a standard expectation and the vendor clears security, portability, and service requirements, that is the answer.

Now add the strategic term#

Suppose proprietary analytics would lift annual contribution by $120,000 because customers pay more and churn less.

PV of the advantage = $120,000 × 2.4869 = $298,428
Cost gap to overcome                    = $232,096
Net in favour of building               =  $66,332

Build becomes economically plausible — by a margin of about 28% of the gap, which is thin. Three caveats belong immediately next to that number:

• The $120,000 lift is a forecast, not an observation. If it is a founder's estimate rather than an evidenced win/loss or retention difference, the entire case for building rests on an unmeasured quantity. Test it before spending $420,000 — a manual or bought version that produces the same customer outcome will tell you whether buyers pay for it.
• The advantage is credited from launch, but launch is eight months away. A stricter model would discount the advantage stream from month 8, which shrinks it further; the delay cost above only charges for lost base contribution, not for lost differentiated contribution.
• The overrun term is almost certainly too small. A 20% chance of a $250,000 overrun is a mild assumption against a distribution where one project in six overruns by 200%. Realise that tail — development costs $1,260,000 instead of $420,000 — and the build option's lifecycle cost becomes $1,427,904 + $840,000 − $50,000 = $2,217,904. That is $1,022,096 worse than buying, and still about $723,668 worse after crediting the full strategic lift.

The example's real lesson is not which column wins. It is that the decision turned on two soft numbers — the delay cost and the strategic lift — and both should be tested empirically before the money is committed.

What are the common mistakes?#

• Comparing salary to licence price. Include recruiting, management, infrastructure, security review, documentation, on-call, and the displaced roadmap. If those are not in the model, the model favours building by construction.
• Calling a capability core because it is technically hard. Difficulty is not differentiation. The test is whether customers pay more, stay longer, or cost less to serve because you operate it.
• Ignoring delay cost. The cheapest eventual system is worthless if it arrives after the window. Convert months into contribution and put the number in the table.
• Ignoring exit cost — in either direction. Migration, data extraction, dual-running, retraining, and customer disruption are real for a bought system. For a built one, the exit cost is that there is no exit: someone must maintain it forever, or you migrate off your own code.
• Treating a partnership as a sales channel with no governance. Split economics without split decision rights produces conflict at exactly the moment the partnership starts working. Agree the unwind before the first joint customer.

When does this framework break down?#

When option value and tail risk dominate expected cost. A small probability of losing critical data, or of being unable to operate, can outweigh a favourable expected value. Apply hard continuity and security gates before ranking on economics — an option that fails the gate does not get a lifecycle cost.

When the requirement is genuinely unknowable. Do not force a permanent architecture decision to close an analysis. Buy a reversible tool, run a partner pilot, or build the narrow internal layer that keeps the other choices open. The correct output of the framework is sometimes "we are not deciding this quarter, and here is what we will learn first."

When the dependency cannot be contracted away. Vendor financial distress, geopolitical export controls, open-source licence changes, model-provider policy shifts, and platform re-pricing are not reliably priced by a contract. For each critical supplier, maintain observable leading indicators and a contingency you have actually tested.

When "buy" means buying the company. Acquisition changes the analysis from procurement to integration, with different failure modes and, at scale, competition-law exposure that arm's-length purchasing does not carry.