Build versus Buy

Definition

The choice between building a capability, buying a product, or assembling from services. The most common error is deciding it on capability ("we could build that") rather than on strategy ("should we?").

The primary criterion: differentiation

Build what differentiates. Buy what does not.

If a capability is how you compete — the pricing engine, the matching algorithm, the recommendation model — building it is how you control it and improve it faster than competitors.

If it is necessary and undifferentiated — authentication, billing, email delivery, error tracking, customer support ticketing — buying it releases engineering capacity for the things that differentiate. Engineering time spent building a commodity capability badly is the largest waste visible on most capability maps.

The secondary criteria

• Total cost over three to five years, including the run effort that never appears on an invoice.
• Time to value. Buying is usually months faster, and the value of those months is real.
• Fit. Every product requires either configuration or process change. A poor fit means expensive customisation, which erodes the reason for buying.
• Exit cost. How hard is it to leave? This determines how much the renewal conversation will cost you.
• Integration effort, which is consistently underestimated and is sometimes larger than the build would have been.
• Data. Where does it live, can you get it out, and does the vendor's location satisfy your residency obligations?

The compromises worth knowing

Buy and extend. Use the product for the common case and build the differentiating part around it. Works when the product exposes good interfaces; fails when customisation fights the product.

Build on a platform. Use a service for the undifferentiated substrate — payments, identity, messaging — and build the domain logic yourself. This is the correct answer far more often than either extreme.

Buy now, build later. Buy to reach the market, replace when scale or differentiation justifies it. Legitimate, provided the abstraction that makes replacement possible is built at the start.

Failure scenarios

• Building a commodity capability because engineers find it interesting.
• Buying a differentiator and then being unable to compete on it.
• Buying and customising heavily, incurring build cost plus licence cost plus upgrade pain.
• Integration effort ignored in the comparison.
• Exit cost never assessed, so a renewal becomes a crisis.

Interview question

"How do you decide whether to build or buy a capability, and what makes the decision reversible?"