Custom ERP: when it beats a standard one

A custom ERP pays off when the process that sustains your business is what sets you apart and does not fit an ERP designed for a generic sector, or when you already pay for a licence and still fill the gaps with spreadsheets. In every other case, a well-configured standard ERP is usually cheaper.

And even when it pays off, it is almost never right to start with a complete ERP: it is built module by module and connected to what already works, not as a single program that replaces everything at once.

An ERP is the system where a company manages its operations: orders, stock, customers, invoicing, work orders. It can be an off-the-shelf product that is configured, or a system built for that company’s specific process.

“Custom” is used for three different things, and it is worth knowing which one the person quoting you means: an off-the-shelf ERP configured your way, an off-the-shelf ERP with modules of your own added, or a management system built from scratch with the modules your business needs. Each has a different cost, a different risk and a different owner.

This comparison describes types of solution, not specific products or suppliers. No row carries figures because they depend on each case.

When it fits

A standard ERP, when the way you work resembles your sector’s. A custom one, when your process is part of what sets you apart.

What you pay for

A standard one usually means a licence and its configuration. A custom one, building it and maintaining it. Neither has a price that can be given without scoping the case.

How the process fits

With a standard one, your team adapts to the tool. With a custom one, the tool adapts to the process, but the process has to be well defined before building.

Who maintains it

A standard one is updated by its manufacturer. A custom one needs someone to maintain it, which is why it is delivered with its code and its documentation.

What happens if you change supplier

With a standard one it depends on the licence and on whether you can export your data. With a custom one, on the code and the documentation being yours.

This is the half that gives value to the other. It does not pay off when what you need is standard: buying it is the cheap option, and a studio that says building always pays off is not informing you, it is selling.

• The way you work is the usual one for your sector and an off-the-shelf ERP covers it with configuration.
• The problem is in a small part of the process: extending the ERP you already have, or connecting two tools, solves more with less.
• There is nobody who can decide what is in and what is out. Without someone responsible, the scope grows and the system is never finished.
• It is not yet clear which process needs improving. Before building comes the preliminary analysis.

If after comparing it does pay off to build, it is done module by module. You start with the one that hurts most, validate it with real data and move to the next, instead of launching a single program that replaces everything at once.

The method is that of any custom software project: understand the real process, define in writing what is in and what is out, design before building, deliver in phases and leave what was done measured.

• First it is compared with an off-the-shelf ERP and with extending the one you already have.
• The first module is for the process that takes the most time or causes the most errors.
• It connects to what already works (invoicing, warehouse, management) instead of replacing it.
• Each module is validated with real data before it is opened to the whole team.

These decisions belong to the business and not to the system. Having them thought through shortens the preliminary analysis.

• Which process is the core and which can stay in a standard tool.
• Which system is the authority for each piece of data when several keep it.
• Which data is migrated, which is cleaned and which is left out.
• Which programs it must coexist with and whether they allow a connection.
• What is essential in the first delivery and what can wait.
• Who decides the scope and who signs off each module.
• Who will maintain it once it is running.

Almost all of them are avoided if they are named at the start.

• Wanting to replace everything at once: if something fails, the whole operation fails.
• A scope with no written limits: without a list of what is in and what is out, the ERP is never finished.
• Undecided data: when there are several versions of the same information, someone has to choose the right one, and that takes your team’s time.
• Integrations with third-party programs that do not allow a connection: this is found out before designing, not halfway through.
• A system only one person understands: avoided with documentation and with the code handed over.
• If the system is going to issue invoices, first check what the regulation on invoicing systems requires.

Guide

Verifactu in the Canaries: 2027 dates and delay

A working system, with its repository and its documentation. The code we develop specifically for your project is yours once the corresponding amounts have been paid, and if we use third-party libraries or services, their licences are identified before they are incorporated.

To decide whether it pays off in your case, the first step is a preliminary analysis, with its scope, its deliverable and its fee agreed in writing before starting.

Custom software

When it pays off and what we deliver

Consulting and discovery

The preliminary analysis, before building

Custom CRM: when it beats a standard one

The same comparison for the relationship with customers

What is a custom ERP?

It is a management system built for a company’s specific process, with the modules it needs (orders, stock, customers, work orders), instead of adapting the process to an off-the-shelf ERP. The term is also used for a standard ERP extended with modules of your own.

When does a custom ERP pay off against a standard one?

When the process that sustains your business is part of what sets you apart and does not fit a generic ERP, or when you already pay for a licence and still fill the gaps with spreadsheets. If what you need is standard, buying it is cheaper.

How much does a custom ERP cost?

It depends on the scope, on the systems and data that already exist, on the integrations and on the number of users. A serious figure cannot be given without scoping the problem first, which is why the fee is agreed in writing before starting. A well-configured standard ERP is usually cheaper than one of your own.

Can an ERP be built module by module?

It is the recommended way. You start with the module for the process that hurts most, validate it with real data and connect it to what already works, instead of building a single program that replaces everything at once. That way each step can be corrected before the next.

Can it connect to the invoicing program or the warehouse system I already use?

It is the usual case and it conditions the whole project, so integration is studied before designing. We review what each tool offers, which system is the authority for each piece of data and what happens if one does not respond. If something cannot be integrated, we say so at the start and not halfway.

Who owns the code of a custom ERP?

The code developed specifically for your project is yours, with its repository and its documentation, once the corresponding amounts have been paid. If third-party libraries or services are used, their licences are identified before they are incorporated.

How much custom software costs and what drives it

What the price of custom software depends on, how to estimate it rigorously and how to compare two proposals without being sold an invented number.

When the spreadsheet stops being enough

A four-step ladder to decide when to move from Excel or a spreadsheet to a tool, an automation or custom software.