Build vs buy: a decision framework that survives contact with reality

Most build-versus-buy comparisons put an annual licence fee next to a development quote and pick the smaller number. Both figures are incomplete, and they are incomplete in opposite directions.

What the buy number leaves out

Configuration and implementation. Enterprise products routinely cost as much again to implement as they do to licence in year one.

Process adaptation. If the product does not match how you work, either you change your process or you pay for customisation. Both are real costs that never appear in the comparison.

Integration. Products connect well to popular systems and poorly to everything else. If your operation depends on a specific combination of tools, connecting them can approach the cost of building.

Per-seat growth. Pricing that is reasonable at twenty people can dominate an operating budget at two hundred — especially when most seats use a fraction of the product.

Exit cost. Getting your data out in a usable form is sometimes difficult, occasionally deliberately so.

What the build number leaves out

Maintenance. Software is not finished at launch. Dependencies need updating, browsers change, requirements shift. Budget meaningfully for ongoing work rather than treating launch as the end.

The cost of your own time. Custom software requires decisions from people who know the business. That attention is a real cost, and it is the resource most often underestimated.

Feature gap on day one. A mature product has years of accumulated edge cases handled. Your first version will not.

Key-person risk. If one person understands the system and leaves, you have a problem a vendor would have absorbed.

The actual decision

Neither number alone answers it. Three questions do.

1. Is this process a differentiator?

If how you do this thing is part of why customers choose you, encoding it in software you control is defensible. If it is payroll, buy something.

Most businesses have one or two genuine differentiators and a long list of ordinary processes. Building the ordinary ones is where budgets go to die.

2. What is the cost of the workarounds you already have?

Count the hours spent on manual reconciliation, re-entry and checking. This number is usually invisible because it is spread across many people, and it is frequently larger than either the licence or the build.

If the workarounds cost more annually than building would, the decision is straightforward.

3. What happens in three years?

Project both paths forward. Licence cost at expected headcount, versus build cost plus maintenance. Three years is far enough to expose per-seat growth and near enough to be predictable.

A rough guide

The hybrid answer

The best outcome is often neither. Buy the commodity components — authentication, payments, accounting, email — and build only the part that is genuinely yours.

A custom system that hands payment to Stripe and identity to a managed provider is far cheaper than one building everything, and far more flexible than a monolithic product you configure around.

What we would say

We build custom software, so treat this with appropriate scepticism — but we turn down work regularly because a product already does the job. A client who buys the right thing and comes back for the integration work is a better outcome than one who spends a year building something they could have licensed.

If you want a second opinion on which side of this you are on, describe the situation. We will tell you honestly, including when the answer is not to build.