Almost every build-vs-buy conversation we join has already been reduced to a single number: the annual licence fee of the off-the-shelf product, set against a rough estimate for a custom build. Whichever number is smaller wins.

That comparison is almost always wrong, because it prices only the part of the decision that is easy to price. The costs that actually determine whether the decision was correct show up in years two and three, and they rarely appear in the spreadsheet that made the call.

This is the framework we use when clients ask us to help make the decision honestly — including the cases where our advice is to buy, and not to hire us to build anything.

Start with the only question that matters

Before comparing costs, answer this: is the process you are automating a source of competitive advantage, or is it table stakes?

Payroll is table stakes. Every company in your industry runs payroll, they run it roughly the same way, and no customer has ever chosen a supplier because of its payroll system. Buy it. Any effort you spend building a bespoke payroll engine is effort spent achieving parity with a solved problem.

But the thing your business does that competitors find hard to copy — the pricing logic, the scheduling algorithm, the underwriting rules, the way you route field engineers — that is different. If you buy a generic tool for it, one of two things happens. Either you contort your differentiating process to fit the tool’s assumptions, and quietly become more like your competitors. Or you keep the process and paper over the gap with spreadsheets, manual steps and integrations, which is the most expensive outcome of all.

A useful test: if a competitor bought the exact same software tomorrow, would you have lost anything? If the answer is no, buy. If the answer is yes, that is a candidate for a custom build.

The four costs nobody counts

Once you have a genuine candidate, price it properly. Four categories consistently get left out.

1. Configuration and integration of the bought option

Off-the-shelf enterprise software is rarely used off the shelf. There is an implementation partner, a configuration phase, data migration, SSO wiring, and a set of integrations to the systems you already run. On substantial platforms this frequently costs a multiple of the first-year licence. It is real spend on a custom-ish outcome — you are paying for bespoke work, just without owning the result.

Ask any vendor for the median implementation cost and duration across their last ten customers of your size. A vendor who cannot or will not answer is telling you something.

2. The workaround tax

When a bought tool covers 80% of your process, the remaining 20% does not vanish. It becomes a shadow system: exports into spreadsheets, a manual reconciliation step, someone re-keying data between two screens, a Friday-afternoon report that one person knows how to produce.

This tax is paid in salaried hours, forever, and it compounds because each workaround becomes a dependency the next process is built on. It is invisible in the software budget and very visible in headcount. Before deciding, walk the actual process end to end and write down every step the bought tool would not cover. Cost those steps at loaded salary. That number belongs in the comparison.

3. Change latency

How fast can you change the system when the business changes?

With custom software the answer is a function of your team’s capacity — days or weeks. With a bought platform, it is a function of the vendor’s roadmap. If a regulatory change or a new product line requires behaviour the vendor does not support, you wait, you pay for professional services, or you build around it.

For a stable process this barely matters. For a process that changes every quarter, change latency is often the single largest hidden cost, and it is the one most likely to force a painful migration in year three.

4. The true cost of ownership on the build side

To be fair to the other column: teams systematically underestimate what custom software costs after launch. A build is not done when it ships. It needs security patching, dependency upgrades, monitoring, on-call coverage, and continued development as the business evolves.

As a planning heuristic, budget meaningful ongoing engineering capacity every year after launch purely to keep a custom system healthy — before any new features. A build that is funded for delivery but not for ownership becomes a liability, and we have been called in to rescue enough of them to say that with confidence.

The middle ground most teams miss

Build-vs-buy is presented as binary and almost never is. The strongest architectures we see are deliberately mixed:

• Buy the commodity core, build the differentiating edge. Use a standard ERP, CRM or e-commerce platform for the parts everyone does the same way, and build custom services for the logic that makes you distinct — connected through a well-defined API layer rather than bolted into the platform’s internals.
• Build a thin layer over a bought engine. Licence the hard, generic machinery — payments, search, mapping, identity — and build the experience and business rules on top. You get differentiation without rebuilding solved infrastructure.
• Buy now, build later, deliberately. Buy to get moving, but treat it as a time-boxed decision with an explicit trigger for revisiting. Keep your data model portable and your integrations at arm’s length so the migration is possible when the trigger fires.

That last point deserves emphasis. The most damaging outcome is not choosing wrong — it is choosing in a way that cannot be undone. Whichever side you pick, keep your data exportable in a documented format and keep vendor-specific logic behind an interface you control. This costs a little upfront and preserves the option to change your mind.

A decision checklist

Run through these before committing. If you cannot answer one, that gap is the next thing to investigate — not something to assume away.

1. Is this process a genuine differentiator, or table stakes?
2. What percentage of our actual process does the bought option cover — verified by walking the real workflow, not by reading the feature matrix?
3. What does implementation cost, on top of licensing, based on comparable customers?
4. What manual work remains, and what does it cost annually in salaried hours?
5. How often does this process change, and what is the vendor’s turnaround for changes we need?
6. If we build, who owns it in year three, and is that capacity actually budgeted?
7. If this decision proves wrong in two years, what does reversing it cost?

Where we land

Our honest position, as a company that builds custom software for a living: most organisations should buy more than they build. Commodity problems have commodity solutions, and rebuilding them is a poor use of scarce engineering capacity.

But the corollary matters just as much. The processes that genuinely set you apart deserve software shaped around them rather than the other way round, and squeezing those into a generic tool is how companies slowly become indistinguishable from their competitors.

The framework above is designed to tell those two categories apart before money is committed, rather than after.

Talk it through with us

If you are weighing a build-vs-buy decision, our custom software development team can help you cost it properly — including telling you when buying is the better answer. We also run short discovery engagements that produce the evidence needed to make the call with confidence.

Get in touch to arrange an initial conversation.