ERP for Growing Businesses: Build, Buy, or Customise?

The right ERP choice depends on how much your operations diverge from industry-standard processes, not on company size alone. Buy off-the-shelf when your workflows are close to standard and speed matters. Customise an open ERP like ERPNext when a meaningful slice of your business, roughly 20-30% of core workflows, is genuinely different and needs to stay that way. Build a standalone custom app only for the rare process that is both mission-critical and has no reasonable ERP equivalent. Most businesses in the 20-500 employee range end up in the middle option.

Why this decision is harder than it looks

Every ERP vendor's sales deck implies their product fits your business perfectly. It does not, because no business runs textbook processes for everything. The real question is not "which ERP is best" but "how much does our specific way of working diverge from the standard workflow this software assumes, and is that divergence worth defending."

A business that has built a genuine competitive advantage around an unusual process (a particular quality-control sequence, a non-standard pricing logic, a unique multi-entity accounting structure) should not flatten that advantage to fit a generic module. A business whose "unique" process is really just an old habit nobody has questioned should absolutely flatten it, because maintaining that divergence costs more than it is worth.

The 70/20/10 rule for fit

A useful rough heuristic when evaluating any ERP option:

• 70% of your processes should match what the software does out of the box, or with minor configuration. If this number is lower, you have either picked the wrong software or you are overestimating how unusual your business is.
• 20% will need real customisation, meaning custom fields, modified workflows, or new reports built on top of the platform's framework. This is where an open, customisable system like ERPNext earns its keep, because you can build this layer without fighting the vendor.
• 10% might genuinely need something outside the ERP, either a specialised tool that integrates via API, or in rare cases a standalone custom application.

If your honest assessment puts more than 30% of processes in the "needs customisation or custom build" bucket, pause and ask whether the process itself needs simplifying before you build software to preserve its complexity permanently.

When off-the-shelf is the right call

Off-the-shelf ERP (or a SaaS vertical tool) wins when:

• Your industry has well-established standard workflows (retail POS, standard accounting, common HR processes).
• Speed to operational matters more than perfect fit. You can go live in weeks, not months.
• You do not have, and do not want to build, internal capacity to manage customisations and upgrades.
• Your competitive advantage is not in how you run operations, so there is nothing to lose by standardising.

The trade-off is that you will bend some processes to fit the software, and if the vendor discontinues a feature or changes pricing, you have limited recourse.

When customising an open ERP is the right call

This is the sweet spot for most established SMEs, and it is where systems like ERPNext are strongest:

• You have specific compliance, taxation, or industry workflows (GST-heavy multi-state operations, a manufacturing BOM structure, a services billing model) that generic software handles poorly.
• You expect to keep growing and adding modules over multiple years, so you want a platform you are not locked out of extending.
• You have, or are willing to fund, either an internal team or an implementation partner who can maintain the customisations through upgrades.
• You want ownership of your data and workflow logic rather than being dependent on a vendor's roadmap.

The cost here is real: customisation work, a support relationship, and the discipline to keep the system upgraded rather than letting a fork of the software calcify at year two. This is exactly the work covered under ERP solutions, where a customised ERPNext implementation is scoped around your actual processes rather than a generic template.

When a custom internal app beats an ERP module

Build standalone only when both of these are true: the process is mission-critical to your competitive advantage, and no ERP module (even customised) models it well without becoming unrecognisable. Examples include a proprietary scheduling algorithm, a highly specific product configurator, or an internal tool that needs a completely different user experience than a form-based ERP screen can offer.

Even then, the custom app should integrate with your ERP via API rather than replace it. Duplicating your inventory or accounting logic in a separate custom system is a reliable way to end up with two sources of truth that quietly disagree with each other.

Comparing the three paths

The hidden costs nobody puts in the proposal

Data migration. Years of inconsistent product codes, duplicate customer records, and spreadsheet-only history need cleaning before they can move into a structured ERP. This routinely takes longer than the software configuration itself, and it is the single most underestimated line item in every ERP project we have seen.

Integrations. Your ERP needs to talk to your payment gateway, your e-commerce storefront, your logistics partner's API, and possibly a government compliance portal. Each integration is a small project with its own testing and failure modes.

Change management. The system can be technically perfect and still fail if the warehouse team keeps using their old paper process because nobody explained why the new screen matters or trained them properly on it. Budget real time for this, not a single afternoon demo.

Training. Ongoing, not one-time. New hires need onboarding to the system for years after go-live, and role-based training (a warehouse clerk needs different training than a finance controller) is easy to skip and expensive to skip.

The second year. Year one gets a project budget and executive attention. Year two, when the initial excitement fades, is when upgrade discipline lapses, customisations go undocumented, and the system quietly starts drifting from best practice. Plan a maintenance budget for year two before you sign the year-one contract.

Signs an ERP project is going to fail

Watch for these together, not in isolation:

• Scope keeps expanding after the initial sign-off, with no corresponding change to timeline or budget.
• The project team is entirely IT and finance, with no one from the operational teams who will actually use the system daily.
• A go-live date is fixed before data migration has been tested end to end.
• Department heads have seen slides about the new system but have not actually used it.
• "We'll customise that later" is the answer to more than a couple of core requirements.

Any two of these together is a strong predictor of a delayed or over-budget go-live. This is also exactly where an outside, on-site perspective helps: understanding how the business actually runs, on the ground, before committing to a scope. That is the premise behind onsite consulting, and it is why we consistently advise clients to walk the floor before writing the specification.

Where to go from here

If you are weighing this decision right now, the honest first step is an operations audit, not a vendor demo. Figure out your real fit percentage before you sign anything. If your team wants to build the skills to run this kind of implementation yourselves, the Frappe/ERPNext developer course at SaaSFarers Academy trains people on live client implementations, not simulated ones, and if you would rather have this scoped for you, our ERP team can walk your floor and tell you honestly which of these three paths fits.