Custom ERP vs Ready-Made ERP: How to Decide

Start by asking whether the process is your advantage

The economics of packaged software are hard to argue with. A vendor spreads development across a large customer base, employs people whose only job is the statutory update, and ships a tested upgrade path. For ordinary finance and operations processes, you cannot match that by building.

The exception is narrow but real. When the sequence of steps your business follows is the thing competitors struggle to copy, forcing it into someone else's product means filing down exactly the edges that make it work. Teams end up running the distinctive part in spreadsheets beside the ERP, which is the worst of both outcomes.

A useful test: describe your process to someone in the same sector. If they shrug, buy. If they take notes, that part may be worth building.

Three routes, three risk profiles

Implementing a packaged ERP as designed is the cheapest and fastest route, and it carries the highest change cost for your people — you are adopting the vendor's model of how a business runs, and some teams will have to work differently.

Implementing and customising keeps the vendor's core and adds your specifics through configuration, extension points or add-on modules. The money moves from the build into the upgrade path, where it stays for as long as you own the system.

Building takes longest and costs most up front, and gives you complete control. It also makes you responsible for everything a vendor used to absorb: tax-rule changes, security patching, browser compatibility, the lot. That is a permanent commitment, not a project cost.

There is a fourth route that often fits best and rarely gets considered: run a packaged ERP as the system of record, and build purpose-made applications around it only for the few processes that genuinely differ, connected by proper integration. You pay for custom engineering only where it earns its place.

Where packaged ERP breaks down

Unusual units of measure, pricing models and costing methods are the first pressure point — batch costing, conversions between buying and selling units, or a bundle of goods and services priced as one line. Products handle the common cases well and the uncommon ones awkwardly.

Multi-entity structures are the second. Once there is intercompany trading, elimination on consolidation and more than one statutory regime, the gap between a product that was designed for this and one that was extended to cope becomes obvious quickly.

The strongest signal is structural rather than functional. If something central to your business has no place in the product's data model — not a missing field, a missing entity — then any customisation will be a parallel system wearing the product's interface. Adding a field is configuration. Adding an entity the product does not know exists is a build, whatever the proposal calls it.

Every customisation is an upgrade you maintain forever

The cost of a customisation is not what it costs to write. It is what it costs to write, plus regression testing at every upgrade, for the entire life of the system. That second part is rarely in the business case.

Customisations that live in supported extension points are cheap to carry. Ones that alter core behaviour are expensive and can eventually block upgrades altogether, which is how organisations end up running unsupported versions and calling it stability.

A discipline worth adopting from day one: keep a register of every customisation with the business reason beside it. At each upgrade, ask whether the reason still holds. A surprising number do not survive the question, and removing one is cheaper than carrying it for another five years.

A decision framework you can apply

Work through these in order. The first clear answer usually settles it, and the rest of the questions tell you what the engagement needs to cover.

• Does a product in your sector already model your core operation? If yes, buy, and spend the saved budget on implementation quality.
• Is this process the reason customers choose you? If yes, consider building that part — and only that part.
• How many legal entities, currencies and statutory regimes are in scope? The more there are, the more a packaged product's existing compliance surface is worth.
• Could you change the process instead of the software? It is the cheapest change available and the one least often considered.
• Who owns the system in three years? Building implies permanent engineering capacity, in-house or contracted. If that is not funded, do not build.
• What happens if your supplier disappears? With a packaged product there is a migration path. With custom software, make sure you hold the source, the documentation and the deployment credentials from the first day.

What discovery should settle before you commit

Before any route is chosen, you should have a process map of the current state with transaction volumes and the exceptions people actually handle, an honest shortlist of which steps are genuinely distinctive, and a fit-gap assessment against at least two candidate products.

You should also have the scope of data migration written down, because it is the item most likely to change the answer. A business carrying a decade of inconsistent master data may find that cleaning it is the larger project, regardless of which software sits on top.

Finally, compare total cost of ownership over five years rather than purchase price. Licences, hosting, support, internal administration and the upgrade effort belong in the same number. Build and buy look very different once they are.