Skip to content
LPR Studio
FREN
Contact us

ERPCustom softwareBudgetIntegrationSMEs

Custom ERP vs off-the-shelf ERP: how to choose, and what each really costs

10 min read

Choose an off-the-shelf ERP when your processes look like everyone else's in your industry: it goes live faster and costs less up front. Build a custom ERP when the way you quote, plan or deliver is what sets you apart, and a packaged product would force you to bend it. Between the two, the most common and often the most sensible route is hybrid: a packaged ERP for finance and payroll, custom modules for what is truly yours. Whatever you choose, decide on five-year total cost, not on the entry price.

This article does not rank ERP vendors. It gives you a method to decide, the cost lines to compare, and the mistakes we see most often.

Definitions: off-the-shelf ERP and custom ERP

An ERP (enterprise resource planning) system brings a company's core operations into one database: purchasing, inventory, production, sales, invoicing, accounting, sometimes payroll and HR. Its value comes from that single database: an order entered once updates stock, invoicing and the general ledger.

An off-the-shelf ERP is a packaged product built by a vendor for thousands of companies, each of which configures it. Microsoft Dynamics 365 Business Central, NetSuite, SAP Business One, Odoo, Sage and many industry-specific systems fall into this category.

A custom ERP is built for one company, around its actual processes. It contains only what that company needs and changes when the company decides. In practice it is rarely "total": most custom ERPs are an operational core connected to a packaged accounting system.

ERP is now mainstream. According to Eurostat (published 20 May 2026, 2025 data, EU enterprises with 10 or more employees), 41% of small enterprises use ERP software, against 89% of large ones. The real question is no longer whether you need an ERP, but which one and how far to adapt it.

What off-the-shelf ERP does very well

For a company with conventional processes, a packaged ERP brings things a custom build does not give you on day one:

  • compliance maintained by the vendor: chart of accounts, sales tax or VAT, statutory reporting, payroll, and the e-invoicing mandates now spreading across many countries;
  • features proven by thousands of users;
  • an ecosystem of implementation partners, connectors, training and community knowledge;
  • a faster go-live, since most of the software already exists.

If your business fits the standard modules with reasonable configuration, start there. The same reasoning applies to any software decision, as explained in our build vs buy guide.

Signs a packaged ERP will not fit

Every workaround in a packaged ERP has a cost. These are the signals we see most often:

  • Quoting or scheduling is your business. Quotes calculated from bills of materials, machine time and material constraints, or shop-floor planning with rules nobody else uses: a generic product reduces them to an approximation.
  • The spreadsheet next to the ERP. If teams export data every week to rework it elsewhere, part of the process already lives outside the system.
  • Customisations keep piling up. When every vendor upgrade forces you to redo adaptations, you pay for the licence and for custom code, while controlling neither.
  • Frontline staff do not adopt it. A screen designed for the finance team is not a screen for a supervisor wearing gloves or a technician on a tablet.
  • Per-user pricing grows faster than value. A monthly licence per person becomes heavy when fifty operators only need two screens.

One sign alone rarely justifies a custom ERP. Two or three, on a core process, justify a proper side-by-side costing.

The three options compared

CriterionOff-the-shelf ERPCustom ERPHybrid (packaged + custom modules)
Fit with your processesThrough configuration, within vendor limitsCompleteComplete on the core, standard elsewhere
Time to go liveFastestModule by module, over several monthsGradual, nothing replaced wholesale
Upfront costLow to medium (implementation)HighestMedium, focused on one module
Recurring costPer-user licences that grow with headcountHosting, maintenance, enhancementsFewer licences plus module maintenance
Tax and payroll complianceHandled by the vendorYour responsibilityLeft to the vendor
RoadmapSet by the vendorSet by youBoth, each on its own scope
Lock-inVendor and implementation partnerDeveloper, limited by the contractShared, each part replaceable

Five-year total cost: the lines to compare

Comparing a development quote with a monthly licence fee is meaningless. Put both options on the same timeline, five years being a common horizon for an ERP, and list every cost line.

Off-the-shelf ERP

  • Licences. The only line you can calculate in advance. As an example, Microsoft's US price list shows Business Central Essentials at $80 per user per month, billed yearly (checked on 6 November 2026). For 30 users, that is $144,000 over five years before any services. Actual prices vary with discounts, regions, user types and add-ons.
  • Implementation: configuration, data migration and training, usually by a partner.
  • Customisations, and the cost of reworking them at each major upgrade.
  • Connectors and add-on apps, often billed separately.
  • Internal time spent on the project, which nobody budgets.

Custom ERP

  • Development, one module at a time.
  • Hosting and operations: servers, backups, monitoring.
  • Maintenance: bug fixes, security updates, framework upgrades.
  • Enhancements that follow your business as it changes.
  • Connectors to accounting, banking and e-invoicing networks.
  • The same internal time, usually heavier during scoping.

What drives the price of a custom build is the number of business rules, not the number of screens; our article on custom business application cost breaks it down. Nor do you have to pay everything up front: custom development can also be funded through a monthly subscription, which puts it on the same footing as a licence.

The classic trap: comparing the licence price of a packaged ERP, without implementation, with the full cost of a custom ERP. An honest comparison puts total cost against total cost, for the same scope and the same period.

The hybrid route: packaged ERP plus custom modules

Most comparisons skim over it, yet it is what many small and mid-sized companies end up doing. The idea:

  • the packaged ERP keeps what is the same for everyone: accounting, payroll, tax filings, e-invoicing;
  • a custom application covers the process that sets you apart: quoting, production scheduling, field service, product configuration, a dealer portal;
  • the two talk through an API, with one simple rule: every piece of data has a single system of record. Items and customers live in the ERP, the schedule lives in the application, and nobody retypes anything.

This limits risk: you do not replace an ERP that works, you add a component where it falls short. It can also limit licence costs, since frontline users may work in the application without a full ERP seat, depending on your vendor's licensing terms, which you need to check. It requires the ERP to expose a documented API: check that first. If you are weighing a specific platform, our comparison of Odoo and custom software goes into detail.

Risks on each side, and how to reduce them

RiskOff-the-shelf ERPCustom ERPWhat reduces it
Poor fitHigh if your business is unusualLowDemos on your own cases, not the vendor's script
Project overrunReal (implementation, customisations)Real (vague scope)Scoping, modular delivery, fixed price per module
Lock-inVendor and partnerDeveloperData export, code and documentation covered by contract
Price changesLicence increases possibleMaintenance costs to planCommitted term, written rate card
Data migrationAlways underestimatedAlways underestimatedA test migration checked by real users

Data migration deserves particular care whatever you choose: duplicate items, customers with missing tax IDs, wrong stock levels. It is often what delays go-live. Before signing anything, also read our guide to avoiding vendor lock-in.

When not to build a custom ERP

Custom is not always the right answer. Avoid it when:

  • your processes are those of your industry and a vertical ERP covers them;
  • nobody internally can own the project: a custom ERP needs regular decisions on business rules;
  • the real need is accounting or payroll: rebuilding what the law governs adds no value;
  • the budget covers development only, not the maintenance and enhancements of the following years;
  • your current ERP works and only falls short in one place: a custom module connected to it will do.

The most common mistakes

  1. Choosing on a sales demo. Ask to see your own cases, exceptions included, before you sign.
  2. Building the complete ERP in one go. A two-year project without interim releases is a risky project. One module in production beats a large system on paper.
  3. Copying today's process exactly. A new ERP, custom or not, is the moment to remove steps that only exist to work around the old tool.
  4. Forgetting frontline users. Screens are designed for the people who enter the data, not for the people who buy the software.
  5. Ignoring the exit. Whatever you choose, make sure you can get your data back in a usable format.

A simple grid to decide

Your situationBest fit
Standard processes, industry well served by vendorsOff-the-shelf ERP
ERP in place, one core process poorly coveredHybrid: custom module connected to the ERP
Unusual operations, many operators, complex quotingCustom ERP built in modules, accounting kept standard
No internal owner, mostly a finance needOff-the-shelf ERP, no customisation

Where to start

  1. Map your real core process, exceptions included, and mark where the current tool forces workarounds.
  2. List every instance of double entry between systems: who, what, how often.
  3. Price licences over five years for your actual number of users, implementation included.
  4. See it before you commit a budget. We build a free visual prototype of the module that falls short, presented over video within 5 working days, so your team sees the scheduling or quoting screen before any decision. Our article on prototypes, MVPs and proofs of concept explains what a prototype is and what it is not.

Frequently asked questions

How much does a custom ERP cost?

No credible figure exists without a scoping phase, because cost is driven by business rules, integrations and data migration rather than by the number of screens. Always compare over five years: development, hosting, maintenance and enhancements on one side; licences, implementation partner, customisations and upgrades on the other.

Is a custom ERP riskier than an off-the-shelf one?

The risks are different rather than larger. Off-the-shelf ERP mainly exposes you to poor fit and dependence on the vendor; custom ERP exposes you to project overrun and dependence on the developer. Building module by module, validating a prototype first and writing exit terms into the contract reduce the custom risks considerably.

Can I keep my current ERP and build only what is missing?

Yes, and it is often the best option. The packaged ERP keeps accounting, payroll and tax compliance, while a custom application handles the process that sets you apart, such as shop-floor scheduling or quoting. The two exchange data through an API, with one system of record for each piece of data.

How long does a custom ERP take to build?

Do not aim for a complete ERP in one go. A first useful module that covers one process end to end can go live within a few months, and further modules follow one at a time. This approach delivers value early and lets you stop or change direction without losing everything already built.

When should a company avoid a custom ERP?

Avoid it when your processes match your industry and a packaged or vertical ERP covers them, when nobody internally can own the project, when the real need is accounting or payroll, or when the budget covers development but not the years of maintenance and enhancements that follow.