The Hidden Cost of HRMS Customization: What to Evaluate Before Buying

Every HRMS purchase in a large organisation reaches the same moment. The demo is over, the shortlist is down to two, and somebody asks the question that decides the project: 'Can the system do it our way?' The vendor says yes. What they rarely say is how. Whether that 'yes' means a setting in an admin screen or a developer writing code against the product decides what the system will cost you for the next ten years.

This article is about that difference. It is written for HR directors, CFOs and IT leads at organisations of 500 to 10,000 employees in Egypt, Saudi Arabia and the wider GCC who are evaluating an HR management system (HRMS) and want to understand the cost of customization before they sign. The build quote is the smallest part of it. The rest arrives over years, in upgrade cycles, in staff turnover and in audit findings.

We will separate customization from configuration, walk through the full ledger of costs that custom code creates, look at the cases where custom code is still the right answer, and finish with the questions to ask vendors so that the 'yes' in the demo is one you can hold them to.

Customization and configuration are not the same thing

In vendor language the two words are used loosely, and that looseness is where the cost hides. Configuration means changing how the product behaves using tools the vendor built and supports: a designer for salary structures, a screen for approval chains, a template editor for letters. The result is data inside the product. Configuration survives upgrades because the vendor tests the product against configured data every release.

Customization means changing what the product is. Someone writes code: a new screen, a stored procedure, a report that reads tables directly, a script that moves data between the HRMS and the ERP on a schedule. The result is software you now own, whether or not you employ a developer. It sits outside the vendor's test coverage, and every future release of the product is a possible breaking change.

The practical test is simple. Ask who would reproduce the change on a fresh installation. If an HR administrator can do it from the admin menus in an afternoon, it is configuration. If it needs a developer, a code repository and a deployment window, it is customization. Insist that the vendor answers this question for each of your requirements, not for the system as a whole.

The full cost ledger of custom code

The build quote is the only line in the ledger that appears on the purchase order. It covers analysis, coding and a first round of testing. In a regional implementation it is often bundled into the implementation fee, so it looks free. It is not free; it is deferred.

Testing is the second line, and it repeats. Custom code must be tested when it is written, tested again when the product is patched, and tested again whenever the surrounding configuration changes. A custom overtime calculation that reads attendance tables directly must be re-tested when shift rules change, when a new plant is added, and when the vendor changes the table structure. Each round costs consultant days and HR staff time, and the HR staff time is usually not counted.

Documentation is the third line, and it is the one most often skipped. A configured approval chain documents itself: it is visible in the admin screen. A custom stored procedure documents itself only if someone writes the document, and the person who writes it is the person under the most time pressure at go-live. Undocumented custom code is not an asset. It is a liability that has not matured yet.

Then there are the lines that appear only in later years: upgrade breakage, key-person dependency, and the audit cost of changes nobody can explain. The next three sections take each in turn, because these are the lines that turn a reasonable build quote into an unreasonable total.

Upgrade breakage: the cost that arrives later

Every serious HRMS is upgraded. Tax brackets move, social-insurance ceilings are revised, labour law changes, and the vendor ships a new version. Egypt's Labour Law 14 of 2025, in force since 1 September 2025, is a current example: mandatory annual increments on the social-insured wage, Arabic contracts in four copies and five-year record retention all require product changes, and a customer who cannot take the vendor's release must build those changes alone.

Custom code is what stops you taking the release. If a custom report reads a table the vendor renamed, the report breaks. If a custom integration calls a function the vendor deprecated, payroll data stops flowing to the ERP. The organisation then faces a choice between staying on an old version and falling out of compliance, or paying to rework the custom code before every upgrade. Many organisations choose the first option without ever deciding to, one postponed upgrade at a time.

The way to evaluate this before buying is to ask the vendor how long their oldest customer has been on the current version, and what happened to that customer's customizations at the last major release. A vendor who builds behaviour through configuration will have a short answer. A vendor who builds it through code will have a long one.

Key-person risk and the knowledge you do not own

Custom code has an author, and the author leaves. The consultant moves to another project; the in-house developer takes a better offer; the partner firm is acquired. What remains is code that works until it does not, and nobody who knows why it was written that way.

This risk is sharper in the region than it looks from a global vendor's head office. Implementation partners for global suites are often small firms, the number of certified developers in a country can be counted on two hands, and the person who built your payroll extension may be the only person in the country who understands it. When that person is unavailable, the fix waits, and payroll does not.

Configuration reduces this risk because the knowledge lives in the product's own screens and in the vendor's training material. A new HR administrator can open the approval chain designer and see the chain. A new payroll officer can open the salary structure and see the formula. Nobody needs to read code to understand how the organisation is set up, and the vendor's support team can help because they are looking at the same screens.

Audit, compliance and the change you cannot explain

An external auditor, a labour inspector or a GOSI reviewer will eventually ask how a number was produced. For a configured calculation the answer is a screen the auditor can read. For a custom calculation the answer is a developer's explanation of code the auditor cannot read, and that is a finding waiting to be written.

Custom code also weakens the audit trail itself. Standard product changes are logged by the product: who changed the approval chain, when, and what it was before. Custom scripts that update tables directly often bypass that logging. The organisation then has a payroll history it cannot fully reconstruct, which matters in a jurisdiction that requires five years of records and in a dispute over an end-of-service calculation.

The evaluation question here is concrete. Ask the vendor to show the change log for a salary structure edit, and then ask whether the same log would capture a change made by a custom script. If the answer is no, every customization you commission is a gap in your audit trail from the day it goes live.

Where customization is still the right answer

None of this means custom code is always wrong. Some requirements are genuinely unique: an integration with a production system that has no standard connector, a report format demanded by a parent company overseas, a legacy allowance scheme that no configurable designer will express. In those cases custom code is the honest answer, and a vendor who pretends otherwise is hiding a cost of their own.

The discipline is to keep customization at the edges. Integrations that read from the HRMS through a supported interface are safer than scripts that write into its tables. A custom report is safer than a custom calculation, because a wrong report is visible and a wrong calculation is paid. And any customization should be treated as a product of its own, with a documented owner, a test script and a line in the upgrade plan.

The ratio matters. If a vendor's proposal for a mid-market implementation lists more custom developments than configured modules, the product does not fit the organisation, and the customization is compensating for that. Configuration-first products aim to make the ratio very small. Orgarise, for example, builds salary structures, approval chains, appraisal sheets, letters and forms in built-in designers, so the requirements that most often become custom code in other systems become configured data instead.

Questions to ask every vendor before you sign

Ask for a written classification of every requirement in your scope as configuration or customization, with the tool named for each configured item. Ask what the upgrade process is for customized items, who performs it, and who pays. Ask how many customers run the current version and what was customized for the largest of them. Timelines are a signal in themselves: configuration-first vendors such as Orgarise quote typical mid-market go-lives of two to six weeks depending on modules and data, and a proposal that runs far longer usually has custom code in it.

Ask to see the designers in a live session, not in slides. Build an approval chain with a conditional step in front of you. Change a salary structure and run a retroactive recalculation. Design a letter in Arabic and English. If the vendor cannot do these during the demo, they will be done in code during the implementation.

Finally, ask for references with a similar profile. Giza Cable Industries, an Egyptian manufacturer established in 1993 with more than 1,000 employees producing low- to extra-high-voltage cables across several plants, runs attendance, payroll and personnel on Orgarise. The relevant question for a reference like that is not whether the system works, but how many of its plant-specific shift rules, overtime calculations and approval chains were configured rather than coded, and what the last upgrade cost them.

Takeaway: price the fifth year, not the first month

The cheapest HRMS proposal is often the most expensive system. Before you compare prices, compare the ledgers: build, test, documentation, upgrade rework, key-person exposure and audit cost, across the years you expect to run the system. Then ask each vendor to classify your requirements honestly and to show configuration working in front of you. An organisation that does this will still customize occasionally. It will do so knowingly, at the edges, and with the total cost written down before the contract is signed.