Buy vs Build an ERP: How to Decide
When to configure an off-the-shelf ERP and when to build custom — the fit-gap test, why heavy customisation is the worst of both options, and the five-year cost curves that decide it.
This decision is usually made on price, which is why it is usually made badly. Price tells you what the first year costs. It does not tell you whether the system will still fit your business in year four, and that is the question the decision actually turns on.
There is a clean test, and it has nothing to do with software.
| Buy (off-the-shelf) | Build (custom) | |
|---|---|---|
| Upfront cost | Lower | Higher |
| Recurring licence | Per user, forever | None |
| Time to first value | Faster | Slower |
| Fit to unusual processes | Poor without customisation | Exact |
| Who maintains it | The vendor | You, or your partner |
| Upgrade path | Vendor-driven; customisation blocks it | You decide |
| Cost of adding 50 users | Rises | Zero |
| Vendor lock-in | High | None — you own the code |
| Best when | Your processes are standard | Your process is your advantage |
The test: is this process your competitive advantage?
Take each core process and ask one question. If a competitor copied exactly how we do this, would we lose anything?
For accounts payable, the answer is no. Nobody has ever won a customer through a superior invoice-approval workflow, and a platform that has refined that workflow across ten thousand businesses will do it better than you would. Buy it.
For how a microfinance institution assesses creditworthiness among borrowers with no formal credit history, the answer is emphatically yes. That logic is the business. Forcing it into a lending module designed for European retail banking does not merely inconvenience your staff; it discards the institutional knowledge that makes the institution viable. Build it.
Most organisations are a mixture, which is why the answer is usually neither pole: buy the commodity, build the differentiator, integrate them properly.
The trap in the middle
The worst outcome available to you is buying an off-the-shelf platform and then customising it heavily, and it is also the most common. Each customisation is a modification the vendor did not anticipate and does not support. When the vendor ships a new version, your modifications must be reapplied and retested, so upgrading becomes a project rather than a routine. Eventually you stop upgrading. Now you run an unsupported fork of a commercial product, still paying the licence, unable to move.
You have arrived at the cost of a custom build with none of its benefits: you do not own the code, you cannot change it freely, and you still pay per user, forever.
The signal to watch for is the customisation estimate exceeding the licence during procurement. When it does, the platform does not fit, and the correct response is to change the platform or to change the process — not to pay someone to bend the software until it breaks.
The honest case for buying
It is stronger than custom-software firms generally admit, and we recommend it regularly. You get working software in weeks rather than months. Somebody else fixes the bugs, ships the features and maintains the security patches. The product has been hardened against ten thousand businesses' edge cases, including the ones you have not encountered yet. There is a hiring market of people who already know it.
For retail, distribution, professional services and most standard finance-and-inventory operations, configuring an established platform is faster, cheaper and lower-risk than building. If that describes you, build nothing. We will say so.
The honest case for building
Build when the fit-gap analysis shows the gap sits in a process that constitutes your advantage. Build when per-user licensing over five years exceeds the build cost at your projected headcount — run the model, because the crossover arrives sooner than people expect. Build when you need integrations no platform supports, or when the data cannot leave your control.
And build when you intend to still be running this system in ten years. Owning the source code means no vendor can end-of-life your operations, raise your licence by forty percent, or be acquired by a competitor. That is not a hypothetical risk in enterprise software; it is the business model.
Whatever you build with us, you own outright — source code and intellectual property, transferred in the contract, portable to another developer without asking us.
Key takeaways
- Ask of each process: if a competitor copied this exactly, would we lose anything? No means buy. Yes means build.
- Buying then heavily customising is the worst outcome — custom cost, no ownership, blocked upgrades.
- If the customisation estimate exceeds the licence during procurement, the platform does not fit.
- Buy the commodity, build the differentiator, integrate them properly. Most organisations are a mixture.
- Model five-year cost at projected headcount; per-user licences cross over sooner than expected.
Frequently asked questions
Isn't building a custom ERP much riskier than buying?
Differently risky, not uniformly more so. Building carries delivery risk — it may run over, and it depends on the competence of whoever builds it. Buying carries fit risk and lock-in risk, which surface later and are considerably harder to escape. A failed build is painful and visible in year one. A bad platform choice is a slow tax you pay for a decade, and by the time it is obvious you have a decade of data inside it. Both risks are manageable: buying is de-risked by an honest fit-gap analysis before purchase, building by phasing delivery so each increment produces working software you can evaluate.
Can we start with an off-the-shelf ERP and build custom later?
Yes, and it is frequently the correct sequence. Configure a standard platform for your commodity processes — finance, procurement, HR — then build custom systems for the differentiating parts and integrate them through APIs. This is how most sophisticated organisations actually operate, rather than running one monolith. The prerequisite is choosing a platform with genuinely good APIs and confirming, before you sign, that your data is exportable. Ask what it costs to leave. The reaction to that question is more informative than the answer.
How do we know if our processes are 'standard' enough to buy?
Run a fit-gap analysis before any purchase, not after. Document how each core process actually works today — including the informal workarounds nobody has written down, because those are where the gaps hide — and map each against what the platform does natively. Where the platform differs, decide explicitly: change the process, or customise the software. If most gaps can be closed by changing your process, and the change would not harm your business, buy. If the gaps sit in processes that make you money, no configuration will save you. Vendors will always tell you their platform fits. That is not a fit-gap analysis; it is a sales meeting.
Who owns the code if you build our ERP?
You do, entirely — source code and intellectual property, written into the contract rather than promised verbally. You receive the repositories, the infrastructure configuration and the documentation, and you may take them to another developer at any time without our involvement or consent. We think a client who stays because they are locked in is a client we did not earn. Confirm this explicitly with any developer you engage, because retaining the IP and licensing the result back to the client is common practice in this market and is rarely made prominent in the proposal.