ERPNext or custom software? A decision rule that holds up

ERPNext gets you most of the way for free. The remaining stretch — the module matching how your business actually operates — is where implementations either succeed or get quietly abandoned for spreadsheets.

Customise ERPNext if your core process is a recognisable business document flow. Purchase order to goods receipt to invoice to payment. Stock entry, transfer, reconciliation. Employee, leave, payroll. Work order, BOM, production. You inherit years of edge-case handling — tax treatments, multi-currency, reconciliation, permission models — that would take a year to rebuild badly.

Build custom if the software is the product, or the workflow is genuinely unusual. A relocation survey app producing volume-based quotes is not a business document flow. Neither is a VVIP itinerary with dependent segments. Forcing those into DocTypes produces something that fights you forever.

The tell: if you find yourself explaining your process in ERPNext's vocabulary and it fits awkwardly but recognisably, customise. If you have to redefine what "Sales Order" means, build.

1. 1You are overriding core behaviour rather than extending it. Hooks and custom DocTypes survive upgrades. Monkey-patched core files do not, and you discover this during a version bump at the worst possible time.
2. 2The custom app is larger than the standard modules in use. At that point you have a custom application carrying an ERP as dead weight, paying the maintenance cost of both.
3. 3Your users only ever touch custom screens. If nobody opens standard ERPNext, you bought a framework and a database, which you could have had with less overhead.

At fit-gap stage, a good third of requested customisations are better solved by changing the process. A three-stage approval chain that exists because two people once disagreed in 2021 is not a software requirement.

We write these down as "gap accepted — process change recommended" and let the client decide. It makes the proposal smaller, which is worth saying out loud given the incentive to do the opposite.

• Everything in a custom app, never in core.
• Fixtures for custom fields and property setters, so a fresh bench reproduces the configuration.
• Migration patches for data shape changes, versioned and idempotent.
• A staging bench that takes the upgrade first, always.
• Client scripts kept thin; business rules on the server, where they cannot be bypassed.

Done this way, an ERPNext upgrade is a scheduled afternoon rather than an incident.

Common, and worth doing properly. Start with an audit of the bench, the custom apps, unmigrated patches and the permission model. The two things that most often turn up: business rules implemented only in client scripts (so they are advisory rather than enforced), and core file edits that will break at the next upgrade.

Get that written down before agreeing any scope.