What evidence should drive a build-versus-buy decision, and which arguments on each side are usually made badly?

The organising question

Is this capability a source of competitive differentiation, or is it table stakes?

Build what differentiates. Buy what does not. A payments company builds its ledger and buys its CRM; a retailer builds its recommendation engine and buys its payroll. The mistake in both directions is treating this as a technical question when it is a strategic one.

The evidence that should drive it

• Differentiation: would a customer choose us because of this capability? If not, building it spends engineering capacity on parity.
• Fit: how much of the requirement does the product actually cover, measured against real requirements rather than a feature list? The gap is where the cost hides, and it is systematically underestimated.
• Total cost over a realistic horizon — five years, including licence growth as usage scales, integration, ongoing configuration, upgrades, and the internal team required regardless.
• The build estimate multiplied honestly, including the maintenance, the operational burden, the on-call, and the years of feature requests after the first version — which is where build estimates are wrong by the largest margin.
• Time to value, which for a competitive opportunity may dominate everything else.
• Exit cost, and whether the data can be extracted in a usable form. This should be assessed before signing, and it almost never is.
• Team capability and appetite, since building something the team cannot sustain is worse than either option.

The arguments usually made badly

For building:

• "Our requirements are unique." Usually they are not, and the belief comes from familiarity with current processes rather than from genuine distinctiveness. The honest test is whether the uniqueness is valuable to customers or merely historical.
• "It's just a CRUD app." The first version is; the ten years of edge cases, integrations and compliance changes are not.
• "We'll avoid vendor lock-in." In-house systems produce their own lock-in, frequently worse: no external support, no documentation, and the knowledge concentrated in people who may leave.

For buying:

• "It's cheaper." Often true initially and frequently false at scale, particularly with per-seat or per-transaction pricing that grows with success. Model the price at 5× current usage.
• "It's proven." Proven at other companies with other requirements; the relevant question is whether it is proven at your shape and scale.
• "We can configure it to do anything." Extensive configuration is building, with worse tooling and no tests, and it is the most common way a bought solution becomes more expensive than a built one.

The option usually missing

Buy the commodity, build the differentiating layer on top. Use a payment provider and build the ledger and reconciliation; use a search engine and build the ranking; use a cloud database and build the domain model.

Most real decisions are not build-or-buy but where to draw the line, and framing it as a binary produces a worse answer than asking which part is genuinely yours.