Configure, Customise or Build: Telling the Three Apart

There are two ways to ruin a system, and they are opposites.

The first is to customise for something you could have changed about the way you work. The code goes in, everyone is pleased, and then it sits in the middle of your platform for the next decade. Every version bump has to be negotiated with it. Every support question has to be answered around it. The manager who insisted on it leaves in year two, and by year four nobody in the building can say why the field exists, only that removing it feels dangerous.

The second is to configure a standard process over the top of something your business genuinely does differently, and to call the difference a bad habit. The system goes live. Within a quarter, a spreadsheet appears. Within two, the spreadsheet is the real system and the ERP is where somebody types yesterday's answers. Nobody reports this as a failure, because the project was delivered on time.

Both failures look like discipline while they are happening. The first looks like listening to the business. The second looks like sticking to standard. The work — the actual, difficult, unglamorous work of an implementation — is telling which one you are in.

The three options are not on a spectrum

They are treated as a spectrum, from cheap and quick to expensive and slow. They are not. They are three different kinds of commitment with three different costs at three different times.

Configuration is a decision recorded in the system's own data. An approval threshold, a tax rule, a warehouse structure, a document sequence, a field made mandatory. It survives upgrades because the vendor built the setting deliberately and has an interest in keeping it working. Its cost is almost entirely in the deciding, which is why configuration-heavy projects fail on governance rather than on technology.

Customisation is code that extends the product. Its build cost is visible and usually modest. Its real cost is a subscription you did not sign: every upgrade, every support call, every new consultant who has to understand it before they can help you, and the day the vendor implements the same feature in a slightly different way in standard product.

Building is a separate piece of software that you own entirely, integrated with the ERP rather than living inside it. It carries the highest first cost and the most honest ongoing cost, because you know from day one that you own the maintenance. It is nearly always the wrong answer, and in a small number of cases it is the only right one.

The mistake is treating these as escalating levels of effort. They are not levels. Choosing between them is a judgement about where a piece of your business belongs, and that judgement is worth more than the estimate that follows it.

The question that resolves most cases

Before any technical discussion, ask this about the requirement in front of you:

Would a well-run competitor in our sector, in our market, do this differently from us — and would they be right to?

Three answers, three routes.

No, they would do it the same way and the product supports it. Configure. The fact that your current method differs is history, not identity.

Yes, they would do it differently, and the difference is why customers choose us or how we are legally required to operate. This is a real difference. Configure if the product bends far enough, customise if it does not, and be prepared to defend the choice for a decade.

Yes, they would do it differently, but honestly they are probably right and we are the odd ones. Change the process. This is the most valuable answer in the whole exercise and the hardest to get, because the person who designed the current method is usually in the room.

The test works because it moves the conversation away from preference and towards competitive reality. "We have always raised the invoice before the delivery note" is a preference. "Our clients will not pay without a certificate signed by their consultant, and the sequence is contractual" is a difference. The first is negotiable at zero cost this month. The second is not negotiable at any cost.

Where genuine difference actually lives

In practice, real differences cluster in a small number of places, and understanding the pattern saves weeks of argument.

They live in your commercial model. How you price, what you promise, how risk is shared between you and the customer. A contractor's retention chain and advance recovery are commercial structure, not administrative preference. A trading business's landed cost allocation determines whether its margin figures mean anything. This is where a product either fits or does not, and it is why sector coverage beats brand reputation in an ERP for a UAE contracting business.

They live in regulation. VAT treatment, e-invoicing, WPS payroll, end-of-service accrual, free zone and mainland structure. These are not preferences and cannot be process-changed away. They are also, usefully, the easiest requirements to verify early, because they are written down by somebody who is not selling you anything.

They live in the physical constraints of your operation. A plant that runs a process nobody else runs. A warehouse whose layout dictates a picking sequence. A field service model with a genuinely unusual dispatch problem.

They live, occasionally, in a real competitive advantage: the thing you do that customers can name and competitors cannot copy quickly.

They do not live in your approval hierarchy, your document numbering, your report layouts, your screen sequences or your month-end checklist. Those feel intensely personal to the people who built them and they are, almost without exception, arbitrary. Most of the customisation budget in a typical project is spent there, defending arrangements whose only justification is that a previous system worked that way.

The customisation that haunts you, and the one that does not

Not all code is equally expensive to own. Two customisations with identical build cost can differ by an order of magnitude over five years, and the difference is structural.

Cheap to own over time	Expensive to own over time
Adds a field and shows it; changes nothing about how core records behave	Overrides how a core document posts, prices, values or approves
Sits at the edge: a report, an export, an import, a printed layout	Sits in the middle of a process the vendor also develops actively
Uses the product's documented extension points	Reaches around them because the documented route was slower to build
Has a written owner and a stated reason	Exists because somebody senior asked for it in month four
Can be switched off and the business still runs, badly	Cannot be switched off without the business stopping
Duplicated by standard product later, and can be retired	Duplicated by standard product later, and conflicts with it

The right column is where upgrade projects come from. A field added to a form is a nuisance at version time. A rewritten posting routine is a negotiation, every version, forever — and the negotiation is conducted by whoever is available at the time, not by the person who wrote it.

There is a practical rule that follows. Push customisation outward. If a requirement can be satisfied by a report, an integration or a separate small tool at the edge rather than by changing how the core document behaves, satisfy it there, even if the edge solution is slightly less elegant. Elegance in the core is paid for at every upgrade. Awkwardness at the edge is paid for once.

When configuration is the wrong answer even though it is possible

The standard-first instinct is correct as a default and wrong as a religion. There are situations where a configured standard process is technically achievable and still the wrong choice.

The clearest signal is when configuration is possible only by asking people to do meaningful extra work every day. A workaround that takes a storekeeper an extra minute per receipt is not a workaround; at four hundred receipts a month it is a part-time job you did not hire for. Multiply every proposed workaround by its volume before accepting it. Most of them collapse under that arithmetic, and the ones that survive are genuinely fine.

The second signal is when the configured process breaks the audit trail. If the only way to represent your transaction in standard product is a manual journal that a human being writes from memory each month, you have not configured anything. You have moved the risk to a person and hidden it from the system.

The third is when configuration would require the business to promise customers something different from what it promises today. That is not a system decision and it should never be taken inside a configuration workshop, by whoever happened to attend.

When any of these three appear, the honest move is to escalate the requirement out of the workshop and into a decision with a named owner. What usually kills projects here is not choosing wrongly; it is choosing by default, in a room without the authority to decide, and discovering the choice during user acceptance testing.

The rare case where building is correct

Building your own software is almost always a mistake, and the reasons are boring and reliable. You become responsible for the maintenance, the security, the hosting, the documentation and the knowledge, indefinitely, with a team that will change. Most companies that build discover in year three that the two people who understood it have left.

There is a narrow set of conditions where it is nonetheless right. The useful version of the test is that all of them must hold at once, not merely some.

The capability is genuinely part of what you sell, not part of how you administer yourself. A logistics business's routing engine, a manufacturer's configurator that customers use directly, a service company's field application that customers see. If the thing touches your customer and shapes their experience, ownership starts to make sense.

No product exists that is close. Not "no product does it exactly our way" — close is enough for administrative functions. Genuinely close means you have looked at the specialist products in your sector, not only at ERP modules.

The requirement is stable enough to be worth encoding but specific enough that no vendor will build it. If it changes every quarter, you are buying a permanent development team, and you should know that before you start rather than after.

You can commit to owning it for its whole life. A named owner, a budget line every year, documentation, and a plan for what happens when the developer leaves. Most build decisions fail this test, and failing it quietly is how a company ends up with a critical system nobody can modify.

It can live outside the ERP. This is the condition people skip. A built component that integrates cleanly with a standard ERP keeps both halves upgradeable. A built component that replaces part of the ERP's core makes the ERP unupgradeable and the build unsupported at the same time.

When those conditions hold, building is not a compromise. It is the correct answer, and the resulting system is usually smaller and more focused than the customisation it replaced. The same logic applies to the smaller pieces that sit around an ERP — the workflow tools and interfaces that do one job well, which is the shape most genuinely useful bespoke software takes in practice.

The mechanism that keeps the decision honest

The decision itself is the easy half. The hard half is preventing the answer from drifting during the eight months after it was taken.

Classify every requirement in writing before contract. Standard, configuration, customisation, build, or process change. Per requirement, signed by both sides. This single document does more to control cost than any negotiation on rates, because it converts a vague scope into a countable one. It is also the thing to demand during selection, since a demo is the cheapest place to make a vendor commit to that classification.

Give customisation a price that includes its tail. When a request arrives mid-project, price the build, then state the annual maintenance and upgrade regression that comes with it. This is the same discipline that makes the rest of an implementation budget behave, and it works for the same reason: a cost stated at the moment of the decision changes the decision. Requests that are worth it survive this. Most do not, and they are withdrawn by the requester rather than refused by you, which is a much better conversation.

Name one person allowed to say no. Not the sponsor, who is too senior for the detail and too invested to refuse a colleague. Somebody with explicit written authority to say: that is a genuine requirement, it is not in this phase, and here is where it is recorded. Without that role, every request is accepted, because accepting is polite.

Keep a register with reasons, not just decisions. Every customisation gets one line: what it does, who asked, what business fact justifies it, and what would have to change for it to be removed. That last field is the useful one. It is the only thing that lets a future team retire code safely, and it costs a sentence to write and a year of investigation to reconstruct.

Re-test the register at every upgrade. Products absorb features. A customisation built in year one is frequently standard by year four, and nobody notices because nobody looks. The upgrade is the natural moment to ask which pieces of code are now redundant, and retiring one is worth more than adding two.

What this looks like when it goes well

A healthy implementation is mostly configuration, with a small number of customisations that everyone can justify in a sentence, and either no build at all or one clearly bounded build that sits at the edge of the system and speaks to it through an interface.

More importantly, it contains a list of process changes the business agreed to make. That list is the strongest single indicator of a project that will still be working in year five. Its absence is the strongest indicator of the opposite, because a project where the business changed nothing is a project where the software was asked to absorb every inconsistency the company had accumulated. That absorption is exactly what makes systems unupgradeable, and it is why the sequencing argument in deciding how the business should run before choosing a platform is not a philosophical preference but a cost control.

A second indicator, less obvious: someone can point at the customisation register and explain why each line is there without checking. If nobody can, the register was written for the auditor rather than for the team, and the code in it will outlive everyone's memory of why.

If you are already past this point

Plenty of readers are not choosing. They are living inside a system where the wrong choice was made repeatedly, and the question is what to do now.

Start with an inventory. List every customisation, and mark each one: still justified, no longer justified, superseded by standard product, or nobody knows. The last category is usually the largest and it is the most useful finding, because a customisation nobody can justify is a candidate for retirement at the next upgrade, and each retirement makes the next upgrade cheaper.

Then look at where the spreadsheets are. A spreadsheet that has become load-bearing is a requirement the configuration did not meet, and it is more reliable evidence than any user survey, because somebody built it on their own time. Some of those gaps are automation problems rather than ERP problems, and the cheapest fixes tend to be at the edges — the sort of work covered by automating the process rather than the paperwork.

And if the system has stopped moving altogether, the customisation register is one of the first things worth reading, because a project that has stalled under the weight of its own change requests has a different remedy from one that stalled on data. That diagnosis is its own exercise, and it is set out in what to do when an implementation has stalled.

If you have a requirement you suspect is genuinely yours and cannot find a product that covers it, that is the conversation we have at the start of a custom software engagement — and the honest outcome is quite often that you should configure instead.