Choosing an ERP is one of the more consequential technology decisions a growing business makes, and it is usually made with incomplete information. The vendor demo looks capable, the price is known, and the timeline sounds reasonable. Two years later the finance team is maintaining a parallel spreadsheet because the system cannot model how the business actually works.
Where packaged ERP wins
If your processes are broadly conventional — standard purchasing, standard inventory movements, standard invoicing — packaged ERP is almost always the right answer. You get years of accumulated domain logic, compliance updates handled by the vendor, a support ecosystem, and a go-live measured in months rather than years. Fighting that with a custom build is expensive vanity.
The honest test is this: can you describe your core operational workflow in terms a generic ERP consultant would recognise? If yes, buy.
Where a custom build wins
Custom becomes justified when the process itself is the competitive advantage. If your margin comes from a scheduling model, a pricing mechanism or a fulfilment sequence that nobody else runs, forcing it into a packaged system usually means one of two bad outcomes: you abandon the advantage to fit the software, or you accumulate so much customisation that you own a bespoke system anyway — but built on someone else’s foundations, with upgrade pain forever.
The second trigger is integration depth. When an ERP has to sit at the centre of many bespoke systems, the cost of bending a packaged product can exceed the cost of building the core deliberately.
The hybrid position
Most businesses land in the middle, and that is a legitimate place to be. Run packaged ERP for the commodity functions — ledger, payroll, standard reporting — and build custom services around the two or three processes that genuinely differentiate you, connected through a documented API layer. This keeps the compliance burden with the vendor and the competitive logic under your control.
Questions to answer before you commit
- Which of our processes would we refuse to change to fit software, and why?
- How much of the vendor demo covered our actual edge cases, rather than the happy path?
- What is the realistic cost of customisation over five years, including upgrades?
- Who owns the data model, and can we get our data out in a usable form?
- If this vendor doubled its licence cost, what would we do?
The answers usually make the decision obvious. The mistake is not choosing wrong — it is choosing before those questions have been asked.