Short answer: a standard ERP like SAP is worth it when your processes are already standard and you accept adapting the company to the software; a custom ERP wins when your competitive advantage lives in non-standard processes, when you need to integrate with what you already run and when you want to own the code, avoiding vendor lock-in and per-seat licensing. It is not always either/or: often the best choice is a custom layer on top of the ERP you already have.
This is the point of view of Codebaker, a Bologna software house founded in 2019 that builds in-house exactly this kind of custom ERP and business management software — and, where useful, makes it talk to SAP and other standard systems instead of replacing them. In this guide you'll find a comparison table, the reasoning on cost over time, two real cases and a checklist to decide.
Standard ERP vs custom ERP: the comparison
The underlying difference is one: with a standard ERP you adapt the company to the software, with a custom ERP you adapt the software to the company. Here is how that choice plays out across the criteria that matter.
| Criterion | Standard ERP (e.g. SAP) | Custom ERP |
|---|---|---|
| Fit to your processes | You adapt the company to the product's best practices | The software follows your processes, even non-standard ones |
| Time to launch | Fast on standard modules, long if customisation is needed | Incremental: you go live module by module |
| Initial cost | Licences + implementation and configuration | Investment in development, no licence fees |
| Cost over time | Recurring per-seat licence fees | Code you own, no licence fees |
| Customisation | Within the limits the platform allows | Unlimited: you define it |
| Vendor lock-in | High: you depend on the vendor and its price list | None: the code is yours, switch supplier anytime |
| Integration with existing software | Possible, but often costly and constrained | Native via API with ERP, machinery and legacy |
| Updates | Driven by the vendor, to be adopted | Driven by you, on your priorities |
| Ideal for | Standard processes, consolidated areas (accounting, warehouse) | Distinctive processes, deep integrations, data control |
Cost over time: recurring licences vs code ownership
The honest comparison is not made on the initial quote, but on the total cost over time (TCO). A standard ERP follows a model of recurring per-seat licence fees: you pay every year, the spend grows with users and enabled modules, and on top of licences come the module customisation costs to bring the product closer to your processes. Add lock-in: the more you invest in the platform, the harder and costlier it becomes to leave it.
A custom ERP flips the logic: there is an upfront investment in development, but then no licence fees and, above all, the code is your property. With many users, the per-seat fees of a standard product can exceed, over the medium term, the cost of software you own — which in the meantime becomes a company asset instead of an endless expense. To reason about the cost items of a custom project, we have a dedicated guide on how much custom software costs.
The third way: a custom layer on top of the ERP you already have
Often the question «SAP or custom?» is badly framed. The best answer is not to replace the standard ERP, but to build a custom layer or integration around it that fills exactly the point where the standard product falls short. Codebaker does both — replace with custom and integrate with standard — and two real cases show it.
Granarolo. We built a custom identity and access management (IAM) system that integrates with SAP, HR, Active Directory and Office365 — without replacing them. The result: over 2000 users managed, a 95% reduction in IT onboarding time and 5 years in production. Custom here does not replace the ERP: it enhances it.
Conor. With ConorShop we built a custom B2B e-commerce integrated in real time with the AS400 ERP through custom APIs. Today it serves over 5000 customers a day and handles more than 300,000 orders a year, in production in around 6 months. Here too the standard ERP stays the operational core; the custom software is the sales channel the standard product did not cover.
How to choose: the 4-question checklist
To decide without stopping at a generic «it depends», answer these four questions. The more «yes» you collect, the more custom (or a custom layer on top of the standard) makes sense.
- Are your processes a competitive advantage? If the way you work sets you apart from competitors, flattening it onto a standard product means throwing that advantage away.
- Do you need deep integration? If you must talk in real time with ERPs, machinery, e-commerce or legacy systems, custom is built for it from the start — and it is the heart of business process digitalisation.
- How many users do you have and how much do licences weigh? With many users the per-seat fees of a standard ERP grow fast; at a certain point software you own costs less.
- Do you need to own the code and control your data? If you want code ownership, no lock-in and GDPR by design, custom is the only path that guarantees it.
Cost over time: how the spend is shaped in the two models
The honest comparison is not on the price of year one but on the shape of the spend over five years. We do not publish vendors' list prices — they vary far too much by sector, volume and contract — but the shape of the spend is always this:
| Cost item | Standard ERP | Custom system | When it weighs most |
|---|---|---|---|
| Licences | Recurring, per user or per module | None | Grows with every new user: heavy with large teams |
| Initial analysis/development | Configuration and rollout | The main item, one-off | Year one |
| Customisations | Billed separately at every process change | Included in the agreed evolutionary maintenance | Every time the company changes how it works |
| Maintenance | Annual fee calculated on the licence | Only what you choose | Every year, in both models |
| Integrations | Vendor connectors, or bespoke if none exist | Native: the software is born to integrate | When legacy or vertical systems stay outside |
| Cost of leaving | High: data and processes live inside the platform | Low: the code and data are yours | The day you want to change supplier |
| Shape of the curve | Low at first, then recurring and rising | High at first, then decreasing | The curves cross: where, depends on user count |
We publish the real cost bands of a custom project openly: €5,000–15,000 for a single module, €15,000–50,000 for a mid-complexity system integrated with the ERP, above €50,000 for multi-plant platforms. The detail, applied to the manufacturing case, is on the page about how much a custom management system for a manufacturer costs.
The five costs that vanish from comparisons
They apply to both routes and are the most frequent reason a project costs more than expected, whichever choice was made.
- Data migration. Master data, price lists, jobs and history must be extracted, cleaned, deduplicated and reconciled. It is a project inside the project and must be quantified separately, never assumed.
- Internal staff hours. The people answering the analysis questions, running acceptance tests and training colleagues are taking time away from their own work. It never appears on an invoice, but it is a real cost.
- The systems left outside. An ERP almost never covers everything: the departmental vertical, the warehouse system and the e-commerce remain. Each has to be integrated, and this is the item most often missing from the initial quote.
- Training and the learning curve. Productivity always dips in the weeks after go-live. With software that mirrors existing processes the dip is short; with a product imposing new workflows it can last months.
- The cost of leaving. Nobody calculates it at signing, and it is the only one that cannot be reduced afterwards. It depends entirely on who owns the code and the data.
When custom would be a waste
We say this even when it costs us the deal: custom software built for the wrong reasons is simply a more expensive standard ERP. There are four situations where standard is the correct choice.
- The process is purely regulatory. General accounting, tax filings, statutory returns: identical for everyone, already solved by standard products that update themselves when the rules change. Rebuilding them bespoke means paying to chase the legislator.
- The company does not yet know how it wants to work. Building custom means crystallising a process: crystallising a confused one is worse than adopting a standard one and using it as discipline.
- There are few users. If licence fees stay marginal, the main economic advantage of custom never materialises.
- There is no internal availability for analysis. Custom work requires somebody in the company to answer questions about how the work is really done. Without that time, the result will be software that guesses at the processes.
The third way in practice: a custom layer on top of the ERP
This is what we propose most often, because in most companies the ERP is not wrong: it is simply incomplete on two or three processes. It is built like this:
- 1. The ERP stays the source of truth for the entities it already governs well: master data, documents, accounting. That way no two versions of the same data appear.
- 2. Isolate the uncovered process, the one where the standard product forces people to work badly or to keep parallel spreadsheets. Those parallel spreadsheets are the best map of where the layer is needed.
- 3. Build only on that process, connecting the application to the ERP via API, so data flows in and out without double entry.
- 4. Plan logs, reconciliation and monitoring from the start: the layer must notice by itself when synchronisation breaks, rather than leaving users to discover it.
This is exactly the pattern behind Granarolo over SAP (2,000+ users, -95% IT onboarding effort, 5 years in production) and Conor over AS400 (300,000+ orders a year, live in 6 months). In both cases the core system was never touched and risk stayed confined to one process at a time — the same principle as the gradual approach described in digitalising an SME without disrupting its processes. If the real question is who to entrust the project to, we have collected the criteria in what to assess when choosing a technology partner.
SAP, custom or a mix of both? Let's assess it together
Codebaker designs custom ERPs and business software and, where useful, makes them talk to SAP and other systems you already run. Tell us your processes: we'll show you where standard is worth it, where custom is, and where the third way fits.
Request a consultationFrequently asked questions about standard vs custom ERP
SAP or a custom ERP: which is better?
It depends on where your competitive advantage lives. A standard ERP like SAP is worth it when your processes are already standard and you accept adapting the company to the software, with a faster start on consolidated modules. A custom ERP wins when your processes are specific and distinctive, when you need to integrate deeply with the systems you already run, and when you want to own the code, avoiding lock-in and per-seat licensing. Often the answer is not even exclusive: you can build a custom layer on top of an existing ERP.
How much does a custom ERP cost?
The cost depends on the number of processes to cover, the integrations with existing systems and the level of automation required. Unlike a standard ERP there are no per-seat licence fees: it is an upfront investment in development, with code ownership included. To get your bearings on the cost items we have a dedicated guide on how much custom software costs.
Does custom software integrate with SAP?
Yes. Custom software can integrate with SAP and other ERPs through APIs, staying complementary instead of replacing them. For Granarolo we built a custom identity and access management (IAM) system integrated with SAP, HR, Active Directory and Office365: over 2000 users, a 95% reduction in IT onboarding time and 5 years in production. It is the example of the third way: a custom layer on top of the standard ERP.
When is a standard ERP like SAP the right choice?
A standard ERP is worth it when your processes fit the best practices the product provides, when you are willing to adapt the organisation to the software, and when you need to cover highly standardised areas such as accounting or warehouse quickly. In these cases starting from consolidated modules cuts initial time, provided you accept recurring licence fees and the platform's customisation limits.
Is the code my property?
With a custom ERP built by Codebaker the source code is your property: no vendor lock-in and no per-seat licence fees. This means you can evolve it over time, switch supplier if needed and keep control of your data, with GDPR by design. With a standard ERP, instead, you stay within the vendor's perimeter and licensing model.
How long does a custom ERP take?
Timelines depend on scope, but an incremental approach lets you go live module by module without stopping operations. For Conor we built ConorShop, a B2B e-commerce integrated in real time with the AS400 ERP through APIs, brought to production in around 6 months and today serving over 5000 customers a day and more than 300,000 orders a year.
How do you really compare the cost of a standard ERP and a custom one?
By comparing the shape of the spend over five years, not the price of year one. A standard ERP concentrates cost in recurring licences that grow with users, an annual maintenance fee calculated on the licence, configuration days and customisations billed separately every time a process changes: the spend starts lower and never ends. A custom system concentrates cost in the initial analysis and development, then continues with only the evolutionary maintenance you choose, with no per-user fees: the spend starts higher and decreases. Where the two curves cross depends mostly on the number of users and on how many customisations the standard product would need anyway. Then add the items that disappear from comparisons: data migration, training, integrations towards the systems left outside, internal staff hours and the cost of leaving the supplier.
When would a custom system be a waste?
In four concrete situations. First: when the process is purely regulatory and identical for everyone, such as general accounting or tax filings, where a standard product has already solved it and keeps updating itself as the rules change. Second: when the company does not yet know how it wants to work, because building custom means crystallising a process, and crystallising a confused process is worse than adopting a standard one. Third: when volumes and user numbers are so small that licence fees stay marginal. Fourth: when there is no internal availability to take part in the analysis, because custom work requires somebody in the company to answer questions about how the work is really done. We say this even when it costs us the deal: custom software built for the wrong reasons is just a more expensive standard ERP.
How do you build a custom layer on top of an existing ERP?
In four steps. First: establish that the ERP remains the source of truth for the entities it already governs well, typically master data, documents and accounting, so no two versions of the same data appear. Second: isolate the uncovered process, the one where the standard product forces the company to work badly or to keep parallel spreadsheets. Third: build the custom application on that process only, connecting it to the ERP via API so data flows in and out without double entry. Fourth: plan logs, reconciliation and monitoring from the start, because the layer must notice by itself when synchronisation breaks. This is the pattern we applied at Granarolo over SAP, with more than 2000 users managed and a 95% reduction in IT onboarding work, and at Conor over AS400, with more than 300,000 orders a year. The advantage is that the core system is never touched and risk stays confined to one process at a time.