Capital has settled the question of whether low-code ERP customization is a real category. Siemens agreed to buy Mendix in the summer for a sum in the high hundreds of millions. OutSystems raised a very large growth round at a valuation above a billion. Microsoft has spent this year pulling its app-building and workflow tools into a single platform story alongside Dynamics. Salesforce, SAP and the mid-market vendors all now sell an extension platform beside the application, and Odoo ships a studio tool that lets a business user add fields, screens and reports without touching code. What has not been settled is governance. The tooling is genuinely good now, the licences are already in most enterprise agreements, and the people using them do not report to IT. Two years from now the interesting question will not be whether citizen developers built things. It will be whether anybody kept a list.
Three layers, and only one is safe to hand over
ERP change comes in three kinds, and conflating them is the origin of most bad outcomes. Configuration is what the product expects: company codes, tax rules, approval thresholds, document numbering, chart of accounts. It is supported, upgrade-safe and already owned by functional teams. Extension is new capability sitting beside the core, reading and writing through supported interfaces. A mobile inspection form, an approval workflow, a portal for suppliers. It does not alter standard behaviour and survives upgrades if the interfaces it uses are stable. Modification changes the core itself, and it is the layer that creates upgrade debt, support arguments and the frozen-version problem that eventually forces a reimplementation. Low-code belongs at the extension layer. It gets used at all three, because a platform that can write to the ERP through an API can implement a business rule that contradicts the one inside the system, and nothing in the tool warns anybody that this has happened. The rule is not enforced technically; it has to be enforced organisationally.
| Change | Article's distinction |
|---|---|
| Configuration | Uses changes the product supports natively |
| Extension | Adds capability beside the core through interfaces |
| Modification | Changes core behaviour and needs explicit ownership |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What business users actually build
Four patterns cover the overwhelming majority. Approval and routing workflows, replacing email chains. These are the clearest wins, low risk and high relief. Data capture front ends for people who never had a seat at the ERP: drivers, site supervisors, technicians, store staff. Also high value, because the alternative is paper and a data entry clerk. Reporting and spreadsheet replacements. This is where the trouble starts, because the usual implementation extracts data out of the ERP into the platform's own store, and the copy then lives its own life. Integration glue between systems that were never connected. Genuinely useful and the most common cause of a quiet outage, because a change at either end breaks something nobody registered as production.
The three failure modes worth designing against
The undeclared data copy. An app built to make reporting easier extracts employee, customer or supplier records into a separate store, with its own retention, its own sharing and its own permissions. In the year that Europe made a documented record of processing activities a legal obligation, this is not just untidy. An organisation that has spent the year building a processing inventory, a retention schedule and a request-handling process has done so on the basis of systems it knows about, and every business-built app holding personal data outside that inventory is a hole in all three. Data protection impact assessments were not written for an app somebody built on a Thursday, which is precisely why those apps are the gap. Business logic with no home. A pricing rule, a tax treatment, a credit exception or a discount ladder that exists only inside an app. It is not in the ERP's configuration, not in a specification, and not in anybody's process documentation. It works correctly and invisibly until it stops, and then nobody can say what it was supposed to do. This is the most expensive of the three because the remediation requires reconstructing intent rather than code. The single author. The app was built by one person, who understood the process, left no notes, and has since changed role, moved company or moved country. Low-code makes individual productivity high and organisational resilience low, and the failure only becomes visible at the moment the author is unreachable. Two mechanical risks sit alongside these. Upgrade coupling, because extensions depend on data models and interfaces that ERP upgrades change, and platform licensing, because per-app, per-user and external-user pricing behaves unpredictably once a prototype reaches a few hundred users.
Practical Guidance for an ERP Customization Strategy Consultation
- Keep a register, and make it the only requirement to build. Name, owner, purpose, which systems it reads and writes, whether it holds personal data. One row per app. If the governance is heavier than the build, it will be bypassed.
- Draw the line at the core. Business users may extend; they may not implement rules that contradict what the ERP enforces. Write it as a short standard with examples of both, because abstract policy does not survive contact with a deadline.
- Ask one question about personal data before approval. Does the app store personal data outside the source system. If yes, it joins the processing inventory, the retention schedule and the request process, or it is redesigned to read rather than copy.
- Build a promotion path. Prototype, then piloted, then supported. Each step adds documentation, a named deputy and monitoring. Most apps should never leave the first stage, and the few that reach the third are the ones that deserve engineering attention.
- Set a retirement rule at creation. A review date and an owner. Unowned apps get switched off after notice. This is the only mechanism that keeps the estate from accumulating.
- Test business-built extensions in the ERP upgrade cycle. They depend on interfaces that change. Add them to the regression list or accept that upgrades will break things silently.
- Model licensing at realistic scale before the pilot succeeds. Per-user and external-user pricing is where a popular internal app becomes an unbudgeted line item.
- Make integrations the exception requiring review. Approval workflows and capture forms can be self-service. Anything writing to a second system should be looked at by someone who knows what else depends on it.
The Regional Angle
The baseline this replaces is stronger here than the market discussion assumes, because the regional hub model produces a specific and well-known gap. Groups run one consolidated instance for several countries, the instance reflects the largest market's requirements, and every local variation gets solved by a business user with a spreadsheet. Low-code does not create shadow systems in this market; it inherits an enormous existing estate of them. The clearest example is only a year old. Value added tax arrived in the UAE and Saudi Arabia in January, and finance teams across the region met the first filings with user-built workarounds: invoice format fixes, reclaim trackers, return preparation workbooks, reconciliation sheets bridging what the ERP produced and what the authority wanted. Most of those are still running. They are the first candidates for either proper configuration or a governed extension, and they are also a warning, because they are exactly the class of tool that quietly becomes the system of record for a statutory filing. A second regional pattern deserves specific attention. Visa and document trackers are among the most commonly built business apps in this market, because the renewal cycle is relentless and the ERP does not handle it. They are also, almost always, a concentration of passport, visa and identity document data sitting outside every inventory the organisation maintains. If a governance programme here addresses one category first, it should be this one. Where the upside is genuinely large is the deskless workforce. Construction, logistics, facilities management, retail and hospitality here employ large frontline populations who have never had access to a business system, often work in several languages, and currently pass information through paper, phone calls and messaging apps. Simple capture forms in the right language, on a phone, replace a data entry function rather than a developer. That is the highest-return use of these tools in this market by a wide margin. And there is a political driver nobody puts in the business case. Most regional estates are run by an integrator, and every change goes through a change request with a price and a queue. Low-code is attractive to business leaders partly because it routes around that. That is a legitimate motivation and it needs a condition attached: the extension estate has to be documented well enough that the integrator can support the platform it now sits beside, or the dependency has simply been replaced with a fragility.
The objection worth taking seriously
The objection is that we have done this repeatedly and it has ended the same way each time. Fourth-generation languages, Access databases, Lotus Notes applications, Visual Basic macros, SharePoint workflows. Every cycle promised that business users would build their own software, every cycle delivered a large estate of undocumented, single-author applications, and every cycle ended with IT spending years migrating or rewriting them. The tools are better now, which mostly means the estate will be bigger. The harder version is about where the cost went. Low-code does not remove development work; it relocates it from a visible IT budget with change control into an invisible operational one with none. The apparent productivity gain is partly a measurement artefact, and the accumulated liability appears three to five years later as a migration programme that nobody forecast, on a proprietary platform whose exit path is expensive by design. Meanwhile the vendors have made platform licensing a lever that grows with adoption. That history is accurate and the conclusion still does not follow, because the comparison is wrong. The realistic alternative to a governed low-code app is not a well-specified project delivered by developers. It is the spreadsheet, the email chain and the WhatsApp thread that are running the process today, with no access control, no audit trail and no inventory entry at all. Judged against that baseline, a registered app with a named owner and a review date is a substantial improvement in control, not a loss of it. The lesson from the previous cycles is not that business users should be prevented from building. It is that nobody kept a list, and keeping one costs almost nothing while it is still short.
Common Questions
Where should the line be between configuration and low-code?
If the product supports the change natively, configure it, because configuration is upgrade-safe and supportable. Use an extension platform for capability the product does not have. Use neither to reimplement a rule the ERP already enforces, which is the pattern that produces two answers to the same question.
Do these apps survive an ERP upgrade?
Only if they use stable interfaces and are tested as part of the upgrade. Extensions reading through supported APIs usually survive. Anything depending on a specific table structure, a report layout or an undocumented field will break, and it will break silently unless it is on the regression list.
Who should own a business-built application?
A named business owner for the process and a named technical contact for the platform, with a deputy for each. The most common cause of an unmaintainable app is not poor construction; it is that the one person who understood it is no longer available.
What should we expect over the next twelve months?
Expect more consolidation after the Siemens acquisition, because platform vendors are now strategic assets for industrial and enterprise suites rather than standalone tools. Expect the ERP vendors to push harder on extending rather than modifying, and to price their extension platforms as a growth lever in renewals. Expect the first governance reckonings at organisations that adopted these tools early, arriving as an audit finding about an app holding personal data outside the inventory. Expect frontline capture to be where the demonstrated returns come from, and reporting apps to be where the problems come from. And expect anyone starting a register now to find it cheap, and anyone starting it in two years to find it archaeology.
ERP Customization Strategy Consultation — we draw the line between configuration, extension and modification for your platform, inventory what the business has already built, and set governance light enough that people actually follow it.