Should we buy an ERP or build one?

The real choice is an operating boundary

Buy versus build is often framed as licence cost against development cost, but the consequential decision is which system owns each business rule and record. Packaged ERP brings established ledgers, tax handling, permissions and upgrade paths. Custom software can model unusual production, pricing, fulfilment or service workflows without forcing them into generic abstractions. Neither removes implementation work. A purchased system still needs configuration, migration, integration, testing and organisational change, while a custom system needs continuing product ownership, operation and regulatory maintenance.

Begin with business capabilities and transaction volumes, not vendor feature lists. Map representative events end to end, including corrections, reversals, approvals and period close. Distinguish a genuine differentiator from a historic preference. If the organisation benefits from adopting a standard process, product constraint can be useful. If a workflow determines service quality or encodes physical operations that products handle poorly, forcing conformity may produce spreadsheets, duplicate entry and brittle customisation. The fit assessment must use configured demonstrations with the organisation’s scenarios and data vocabulary.

Assess fit at the exception level

High-level requirements make every credible ERP appear suitable. The differences emerge in partial receipts, retrospective corrections, mixed tax treatment, unit conversion, intercompany movement and unusual approval delegation. For each scenario, record whether the product supports it through standard configuration, supported extension, external service, workaround or not at all. Configuration survives upgrades more reliably than modifications inside vendor code. A long list of small workarounds can be more damaging than one explicit custom module because it distributes control failure across daily operations.

• Identify the authoritative system for every master record and transaction state.
• Test complete exception paths using configured software, not presentation slides.
• Model licence, implementation, integration, support and exit costs together.
• Check upgrade compatibility for every extension and marketplace dependency.
• Define how data can be exported with meaning and audit history intact.

A hybrid architecture needs firm seams

A common pattern retains packaged finance and builds operational services around it. This works only when boundaries are explicit. The operational system may own an order lifecycle while the ERP owns posted invoices and journals. Interfaces then carry stable business events with identifiers, dates, currencies and reconciliation status. Duplicating mutable rules in both systems causes divergence. Integration should be observable and replayable, with rejected messages visible to accountable operators. A hybrid is not automatically lower risk; without ownership rules it becomes two partial ERPs joined by manual correction.

Compare change over several cycles

Initial fit can conceal long-term constraint. Review how the package handles vendor upgrades, API retirement, data-volume growth and changes to entities or operating models. Review how a custom system will receive security updates, statutory changes and knowledge transfer. Product roadmaps are not contractual delivery, while custom backlogs are not funded capacity. The decision model should include probable changes and the cost of validating them, not speculative feature totals. Reversibility matters: standard interfaces, documented data models and controlled exports reduce the consequence of a later change in direction.

Account for organisational capacity

Custom ERP requires an empowered product owner, accessible finance and operations expertise, and a durable engineering and support arrangement. Without those capabilities, decisions accumulate in code and maintenance becomes reactive. A packaged implementation still requires process owners capable of rejecting unnecessary customisation and governing master data. Outsourcing delivery does not outsource accountability for controls or operating design. The preferred option is the one the organisation can govern after launch, not merely the one a procurement or engineering team can initiate.

Run a decision process, not a feature contest

Shortlist plausible boundaries, gather evidence through discovery and product trials, and score them against weighted operating criteria. Include security, auditability, data portability, integration, accessibility and support alongside functional fit. Document disqualifying constraints separately from preferences so a strong total score cannot conceal a mandatory failure. The decision record should explain assumptions and triggers for review. A small prototype may test the riskiest custom workflow, while a configured vendor proof tests product claims. Comparable evidence produces a defensible choice without pretending uncertainty has disappeared. Reference checks can illuminate implementation practice, but they do not replace testing the organisation’s own scenarios and constraints.