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
| Criterion | Off-the-shelf ERP | Custom ERP | Hybrid (packaged + custom modules) |
|---|---|---|---|
| Fit with your processes | Through configuration, within vendor limits | Complete | Complete on the core, standard elsewhere |
| Time to go live | Fastest | Module by module, over several months | Gradual, nothing replaced wholesale |
| Upfront cost | Low to medium (implementation) | Highest | Medium, focused on one module |
| Recurring cost | Per-user licences that grow with headcount | Hosting, maintenance, enhancements | Fewer licences plus module maintenance |
| Tax and payroll compliance | Handled by the vendor | Your responsibility | Left to the vendor |
| Roadmap | Set by the vendor | Set by you | Both, each on its own scope |
| Lock-in | Vendor and implementation partner | Developer, limited by the contract | Shared, 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
| Risk | Off-the-shelf ERP | Custom ERP | What reduces it |
|---|---|---|---|
| Poor fit | High if your business is unusual | Low | Demos on your own cases, not the vendor's script |
| Project overrun | Real (implementation, customisations) | Real (vague scope) | Scoping, modular delivery, fixed price per module |
| Lock-in | Vendor and partner | Developer | Data export, code and documentation covered by contract |
| Price changes | Licence increases possible | Maintenance costs to plan | Committed term, written rate card |
| Data migration | Always underestimated | Always underestimated | A 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
- Choosing on a sales demo. Ask to see your own cases, exceptions included, before you sign.
- 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.
- 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.
- Forgetting frontline users. Screens are designed for the people who enter the data, not for the people who buy the software.
- Ignoring the exit. Whatever you choose, make sure you can get your data back in a usable format.
A simple grid to decide
| Your situation | Best fit |
|---|---|
| Standard processes, industry well served by vendors | Off-the-shelf ERP |
| ERP in place, one core process poorly covered | Hybrid: custom module connected to the ERP |
| Unusual operations, many operators, complex quoting | Custom ERP built in modules, accounting kept standard |
| No internal owner, mostly a finance need | Off-the-shelf ERP, no customisation |
Where to start
- Map your real core process, exceptions included, and mark where the current tool forces workarounds.
- List every instance of double entry between systems: who, what, how often.
- Price licences over five years for your actual number of users, implementation included.
- 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.