Custom Platform or Off-the-Shelf ERP? An Honest Decision Framework

We build custom enterprise platforms, so treat what follows accordingly. We are also going to spend a good part of it arguing that many organisations should buy rather than build, because the alternative — telling you what you want to hear and delivering a platform you did not need — is a worse outcome for both of us.

Build-versus-buy is not a question with a general answer. It is a question with a decision framework.

Buy when the process is not your advantage

General ledger. Payroll. Statutory tax filing. Standard procurement. These are solved problems, governed by external rules you do not control, and executing them differently than your competitors gains you exactly nothing. Established ERP vendors have absorbed decades of regulatory edge cases you have never heard of and will not anticipate.

Building here is a category error. You will spend two years reproducing functionality you could have licensed, and then spend every subsequent year maintaining your reproduction against regulatory changes that the vendor would have handled.

The honest heuristic: if a process is a cost of doing business rather than a reason customers choose you, buy it.

Build when the process is the product

The opposite case is equally clear. Where your workflow is your differentiation — a lender's underwriting logic, a manufacturer's yield-optimising production scheduling, a logistics operator's routing — forcing it into a package means either abandoning the advantage or paying to customise the package until it is a bespoke system with someone else's licence attached and someone else's upgrade cycle imposed.

The tell is heavy customisation of a single module. If eighty percent of the package fits and one module needs to be rebuilt, you are not buying software; you are buying a constraint and paying consultants to work around it.

The total cost model people skip

Most build-versus-buy comparisons compare licence cost to development cost and stop. That comparison is wrong in both directions and reliably produces bad decisions. Over a realistic seven-year horizon, both sides carry costs that are invisible at signature.

Buy-side costs that are routinely omitted: per-seat licences that scale with headcount rather than value; implementation consulting, which frequently exceeds year-one licence cost; the customisation work needed to make the package fit; forced upgrade cycles that re-break those customisations; integration middleware; and the cost of workflow compromise, which is real, ongoing, and never appears in a spreadsheet because nobody bills you for it.

Build-side costs that are routinely omitted: maintenance, which typically runs 15–20% of the original build annually and never stops; the key-person risk of a small team owning critical logic; security patching across your whole dependency tree; the true cost of the internal capability required to keep the thing alive; and the opportunity cost of engineers building an internal system rather than the product your customers pay for.

Compare those two lists and the answer is frequently different from what the licence-versus-build-cost comparison suggested — sometimes in favour of building, often not.

The composite pattern, which is what most mature organisations actually do

The framing as a binary is itself the most common mistake. In practice, the durable architecture for most mid-to-large organisations is neither pure build nor pure buy:

• License a proven package for commodity back-office functions — finance, HR, statutory reporting — and take it close to vanilla, resisting customisation.
• Build custom services for the two or three workflows that constitute your competitive advantage.
• Integrate through a deliberate API layer rather than through direct database access, so either side can be replaced without the other having to be.

This gets you vendor-maintained compliance where compliance is generic, full control where control matters, and — critically — the option to change your mind later. The integration layer is what buys that option, and it is the piece most often skipped under delivery pressure. Skipping it is how organisations end up unable to replace either system.

Questions worth answering before you commit

Would a competitor gain anything by running this exact process? If not, buy it. Can you describe your differentiating workflow precisely enough to specify it? If not, you are not ready to build it. Do you have — or will you fund — the engineering capability to maintain a custom platform for the next seven years? If not, the build will be delivered and then decay. And if you built this and it worked, what would change for the business? A vague answer to that last one is the strongest available signal that the honest recommendation is to buy.

We take on custom builds where the answers point that way, and we say so when they do not. The conversation is more useful than the pitch.