Build versus buy: the honest math

We are asked to arbitrate this decision regularly, usually after an internal debate has hardened into two positions. The engineering team wants to build; the finance team wants to buy; both have assembled numbers that support their preference.

Almost always, both sets of numbers are incomplete in predictable ways.

What the buy case usually omits

• Implementation and configuration, which for enterprise platforms routinely exceeds the first year of license fees.
• Integration work, since the platform will need to exchange data with systems you already run.
• Per-seat cost growth as you hire — a line item that scales with headcount rather than with value.
• Process change, because the platform's assumptions will not match yours and something has to give.
• The workarounds for the 20% it does not cover, which usually become someone's permanent manual job.
• Switching cost, which is real and rises every year you stay.

What the build case usually omits

• Maintenance, realistically 15–25% of the original build cost annually, forever.
• The features you did not scope but will need — reporting, permissions, audit trails, admin tooling, integrations.
• Opportunity cost of engineering time not spent on your actual product.
• Key-person risk, since a custom system depends on people who understand it and people leave.
• The time to first value, which is months rather than weeks and has a business cost.
• Ongoing security and dependency management, which is not optional and not free.

The question that actually decides it

Cost modeling narrows the choice but rarely settles it, because the numbers are frequently close enough that either could be defended. The question that settles it is different: is this process a source of competitive advantage, or is it table stakes?

Buy table stakes. Payroll, accounting, email, helpdesk, standard CRM — these are solved problems where a vendor spreads development cost across thousands of customers and will always outspend your internal effort. Building them is a way of paying more for less.

Build the advantage. If your pricing model, routing logic, quality process or customer experience is genuinely how you win, a platform that forces you toward the industry-standard version of it is eroding the thing you compete on. That is the case where custom is not a cost decision at all.

The answer is usually both

The most common right answer is a hybrid that neither camp proposed: buy the platform for the commodity layer, build the specific capability that differentiates you, and connect them properly. You get vendor investment where it helps and control where it matters.

This is now considerably more viable than it was, because most serious platforms expose reasonable APIs. Ten years ago the integration cost made hybrids painful. Today it is often the cheapest path.

The question is not whether to build or buy. It is which parts of the problem are worth owning.

Three warning signs the analysis is going wrong

1. Nobody has spoken to a reference customer of similar size in a similar industry. Vendor demos and reference calls tell you different things.
2. The build estimate came from the people who want to build it. Get an outside estimate, even informally.
3. The decision is being made on a three-year horizon for a system that will run for ten. Extend the model and see whether the answer holds.

We run this analysis as a fixed-scope engagement precisely because we can end up recommending either outcome — including recommending you configure something you already own and spend nothing further.