ERP or Custom Software? How to Decide

At some point most companies looking at an ERP quote ask the same question. How much of what this system can do are we actually going to use?

It is a fair question. ERP rollouts usually run long not because the software is bad, but because the company is being reshaped to fit it.

To be clear, we do not sell ERP. What we build are the pieces a company actually uses. For some businesses the right answer really is an ERP, and we say so when it is. Below is where each one wins.

The decision is not really about software

The right question is not which one is better. It is this. What makes you different from your competitors?

If your processes are the industry standard, meaning you take orders the way everyone does, hold stock the way everyone does and invoice the way everyone does, an ERP is cheaper and faster. It already carries that standard inside it, so you are not building it from scratch.

But if your processes are the thing that sets you apart, an ERP turns that back into the standard. If your pricing changes by customer, your production flow is your own, or you offer something nobody else in your sector does, that difference has to live inside the software. In a ready-made system it either disappears or it survives outside the system, in spreadsheets.

Comparing the cost honestly

ERP licences are usually per user and monthly, so the cost grows as the team grows. Take on two more people in the warehouse and two more lines appear on the invoice.

With a custom build most of the cost is one off. There is maintenance and further development afterwards, but nothing that scales with headcount.

In the short term the ERP looks cheaper. Over a longer horizon the sum can change. The honest comparison runs over three years and includes rollout time, consultancy and how long the team takes to settle in. Those three rarely appear on the quote.

Only as much system as you need

Solving three problems should not mean learning fifteen modules. If you need orders, stock and collections, those are what get built.

A module nobody opens is not free. It takes up screen space, it gets covered in training, it gets tested on every update, and nobody uses it. We do not write the second module until the first one is genuinely in daily use.

You do not have to remove the ERP you have

This is actually the setup we build most often. There is already an ERP or accounting package keeping the statutory books. Replacing that is a risk in itself and usually unnecessary.

We build the missing piece and wire the transfer between them. The one thing to settle first is which side holds the truth. Which one wins when the same record is changed in both? If that question goes unanswered the two systems drift apart without anyone noticing, and six months later you cannot say which one to trust.

When an ERP is the right call

Saying this does not win us work, but letting you go the wrong way costs more.

If you run multi-site manufacturing, have complex cost accounting, or your sector mandates specific statutory reporting, a mature ERP is the better answer. Writing those reports from scratch takes a long time, and when the rules change the maintenance falls to you. The ERP vendor already carries that weight.

Where to start

The first job is measuring which parts of the work actually need software. Not all of them do. Building a screen for something done once a month rarely makes life easier for the person doing it.

Then we start with a single module and do not move to the second until the first is really being used. Opening five at once means ending up with five half-finished ones.

What sets the pace is usually not the code. It is the state of your existing data and how quickly decisions get made. The same product recorded under three different names is the most common cause of delay we see.

What happens as the headcount grows

This line rarely comes up at quote stage, but three years on it can be the largest item on the invoice.

Say you started with ten people. Three more in the warehouse, one in accounts. You opened a second site and took on four there. Now you are at eighteen users and the licence line has nearly doubled, while nothing about the software has changed.

On your own system, adding a warehouse operative means creating an account, not adding a cost. In businesses with high staff turnover that difference is noticeable.

Who holds the data

With a cloud ERP the database sits with the vendor. That is not a bad thing in itself, and it is often safer, because backups and maintenance are their job.

The problem shows up on the way out. If you decide to change vendor, does the contract say what format you get your data in and how long it takes? If it does not, that data is effectively immovable.

On a system running on your own server the question never arises. The database is yours and you can take a dump of it whenever you want.

The customisation trap

ERP vendors usually say the system is customisable, and that is true. But there are two kinds of customisation and they behave very differently.

The first is configuration. You add a field, rearrange a screen, define a report. That is safe and survives upgrades.

The second is writing code, embedding your own logic inside the system. The danger there is that every major upgrade requires that code to be reworked, and that work usually arrives as a consultancy invoice. A heavily customised ERP eventually becomes one that cannot be upgraded, and the company stays on an old version.

Five questions to answer before deciding

Which problem are you trying to solve? If it cannot be written in one sentence, the project is already unfocused.

Who does that work today, and how? No system gets built correctly until the current flow is written down.

What is the three year total? Licence, rollout, consultancy and training included.

What happens if you want your data out? The answer should be in the contract.

Does the business stop without this software? If it does, the fallback plan needs discussing from the start.