The business case for low-code has already been won, and it was won by arithmetic rather than by argument. IT departments emerged from last year with a change queue measured in quarters, and the platform vendors have spent two years pushing app builders and automation designers into seats organisations were already paying for. So the finance analyst builds the approval app, the operations supervisor builds the inspection form, and the work gets done. None of that is the problem. The problem arrives eighteen months later, when the analyst has been promoted, the app is in the month-end close, and the only person who understood the logic left in June. Low-code does not create legacy through code. It creates legacy through ownership — and the governance question is not "should the business build?" but "what has to be true before something the business built is allowed to matter?"
Why this kind of legacy is harder than the old kind
A badly written custom program is at least a file. It sits in a repository, it can be read by a stranger, it can be diffed, and somebody's name is on the last change. Citizen-built artefacts routinely fail on five counts that traditional development solved decades ago: There is no readable source. The logic lives inside a proprietary designer as a graph of clicks. Reading it requires opening the tool and understanding a mental model nobody wrote down. It runs as a person. The connection is authenticated with an individual's account, so the automation inherits that person's permissions and dies, silently, when they change role or leave. This is the single most common cause of a citizen automation failing at the worst moment. It moved data without telling anyone. To make the app responsive, the builder copied a customer list, a price table or a cost centre hierarchy into the platform's own storage. That copy is now a shadow master, and it started diverging the day it was created. It was built in production. There is no development environment, no test environment and no release. The first user is also the test. Nothing is tested. Not because the builder was careless, but because the tooling did not ask for it and no reviewer existed.
Classify by consequence, not by technology
The cheapest governance model I have seen working sorts everything into three tiers, and the sorting criterion is consequence, not sophistication. Tier one: personal. One user, no shared data, no financial or statutory output. A tracker, a reminder, a personal dashboard. Governance here should be zero. Not light — zero. This is most of the volume and all of the goodwill. Tier two: team-supported. A handful of users, real operational value, but nothing that feeds the ledger, a statutory return or a customer commitment. Requirements: a register entry, a named owner, a named deputy, and a review date. That is four fields. Tier three: business-critical. It touches money, a regulator, a statutory filing, a customer promise, or personal data at any scale. This tier must be promoted before it is allowed to carry that weight. The important nuance: tier is determined by what the thing does, not by who built it. An analyst's spreadsheet automation that calculates a tax figure is tier three on day one, whether or not anybody in IT has heard of it.
| Tier | Consequence described | Minimum treatment proposed |
|---|---|---|
| Personal | One user; no shared, financial or statutory output | No additional governance under this model |
| Team-supported | Shared operational value without ledger, statutory or customer output | Register entry, owner, deputy and review date |
| Business-critical | Money, statutory duties, customer commitments or personal data | Promotion gate before the extension becomes load-bearing |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The promotion gate
Promotion is a checklist, not a committee. Seven items, and any competent builder can satisfy them in a day with help: It runs under a service identity owned by the organisation, not under a named person's account. It exists in a managed environment separated from where people experiment. It has a business owner and a deputy, both named in the register. Its data flows are documented — what it reads, what it writes, and where any copies live. Its licences and connectors are attached to the organisation rather than to an individual's subscription. It has a one-page runbook covering what it does, what breaks, and who to call. And it carries a review date, because the most valuable governance artefact in this entire discipline is an expiry. Everything that passes the gate is supported. Everything that does not pass the gate is not allowed to be load-bearing — which is a statement about accountability, not a punishment.
The rule that prevents the worst outcome
One line, worth more than the rest of the framework combined: an extension may read master data; it may not own master data. The damaging artefact is almost never the app. It is the list behind it — the customer table, the rate card, the approved supplier list, the cost centre mapping — that was copied out of the system of record for convenience and has since been edited by hand. Two years later, two answers exist to the same question and the newer one is in the tool with the better interface. If an extension needs reference data, it reads it live or on a scheduled refresh it does not modify. If the business genuinely needs a new master data set, that is a request for the system of record, not a reason for a parallel one.
Build against published interfaces, not internals
The second technical rule is about survival. Extensions that scrape screens, depend on table layouts or reach into database internals break on the vendor's next release, and on a managed platform that release arrives whether or not you are ready. Anything expected to live longer than a quarter should be built on published interfaces and events. This also has a cost dimension that catches finance by surprise. Premium connectors, per-automation plans and application programming interface call quotas turn a "free" platform into a real bill, and the bill arrives centrally with no department attached. Attribute platform consumption to the business area that owns the artefact from the first month, or nobody will ever retire anything.
Practical Guidance for Low-Code Governance Design
- Write the three tiers down and publish them, with examples from your own business. People self-classify accurately when the criteria are concrete.
- Govern nothing in tier one. The credibility of the whole model depends on this.
- Make the promotion gate a seven-item checklist with a two-day turnaround, not a review board that meets fortnightly.
- Ban person-authenticated connections for anything promoted. Service identities, owned by the organisation, with the credentials in the same vault as everything else.
- Enforce one rule absolutely: extensions read master data, never own it.
- Adopt a naming convention that encodes owner, purpose and review date, and run a quarterly sweep that disables anything unused for ninety days, with a thirty-day restore window.
- Attribute platform and connector cost to the owning department monthly. Consumption without an owner grows forever.
- Keep a register with fewer fields than you want. Name, owner, deputy, tier, what it touches, review date. Registers with twenty fields are not maintained.
The Regional Angle
Three regional patterns turn citizen-built tooling into fragile infrastructure faster here than elsewhere. The first is that approval logic in this market encodes people, not roles. Authority in family-owned and owner-managed groups is personal and often informal: a particular individual signs off above a threshold, a relative approves anything involving a specific counterparty, and the finance manager knows to call before releasing certain payments. Citizen builders faithfully reproduce what they observe, which means the app contains a named individual as a routing destination. When that person changes role, travels for six weeks, or leaves, the workflow stops or — worse — routes to someone who now has authority they were never granted. Insist on one design rule for anything promoted: approvals route to a role or a group, and the mapping from role to person lives in one place that a human maintains deliberately. The second is the calendar. Scheduled automations in this region are routinely built on assumptions imported from templates and documentation: business days Monday to Friday, escalations after twenty-four hours, reports on the first working day. In most Gulf states the weekend falls on different days, which means an approval with a two-day expiry issued on a Wednesday afternoon can lapse before anybody is at a desk, and a Monday-morning report can land after the week has already begun. Add Ramadan working hours, national holidays announced at short notice, and multi-country groups operating on more than one working week, and the scheduling assumptions become a source of silent failure that nobody attributes to the automation. Build working-day calendars as configuration, per country, and test escalation timings against the actual week. The third is licensing, and it quietly decides what gets built. The employees whose work would benefit most from a simple form — drivers, storekeepers, technicians, site supervisors, cleaners, security staff — frequently do not hold a named licence for the platform the apps are built on. So apps get designed for the minority who have seats, the majority stay on paper, and somebody re-keys the paper into the app at the end of the shift. The result is an automation that has added a data entry step rather than removed one. Before designing anything for frontline operations, establish who actually has access, and price the licences for the people who will use it rather than for the people who will build it. A final practical note: where the IT function is effectively an outsourced support contract, promotion has a price and a lead time, which is precisely why the business built its own tool in the first place. If you want the gate to be used, negotiate a standing allowance for adoption of promoted artefacts into the support agreement, or promotion will be refused on budget grounds and the estate will stay ungoverned.
The objection worth taking seriously
The strongest objection is that governance destroys the value. People went around IT because IT was slow, and a framework with tiers, registers, owners, gates and review dates is simply a slower queue with a friendlier name. Most citizen-built artefacts are trivial, most will be abandoned within a year, and the effort spent cataloguing them exceeds the harm they could ever do. Meanwhile the genuinely dangerous things in most organisations are not low-code apps at all — they are the spreadsheets that have run the business for fifteen years, which nobody proposes to register. There is a great deal of truth in this, and any governance model that does not concede it will be ignored, which is the worst outcome available. The concession is tier one, and it should be loud. No registration, no owner, no review, no approval — build whatever you like. That covers most of the volume and most of the enthusiasm. The gate exists only where the artefact touches money, statute, customers or personal data, and at that point the requirement is not bureaucratic taste; it is that somebody other than the builder can keep it running. The spreadsheet objection is also correct and points the same way: a fifteen-year-old spreadsheet that calculates a statutory figure is tier three, has always been tier three, and should go through the same gate. If the framework is applied honestly it does not add a queue — it names the small number of things that were never anybody's responsibility.
Common Questions
Who should own governance — IT or the business?
The register and the gate belong to IT; the artefacts belong to the business. IT's job is to make promotion fast and to say clearly what is unsupported. If IT owns the apps themselves, you have recreated the backlog.
What do we do with the estate that already exists?
Discover, then triage by consequence rather than by age. Find everything authenticated to a departed employee's account first — that list is short, alarming and quick to fix.
Should we restrict who can build?
Restrict connectors and data, not people. Blocking creation drives the work into personal accounts and unmanaged tools, which is strictly worse than governing it where you can see it.
What should we expect over the next twelve months?
Expect the platform vendors to keep pushing this capability into licences you already own, including desktop automation, which will accelerate adoption faster than any governance programme can be stood up. Expect the first uncomfortable audit conversations about a control performed by an app nobody could produce documentation for. Expect platform consumption to become a visible budget line by the third quarter and to prompt an unplanned cleanup. And expect the vendors to ship better governance tooling — managed environments, data loss policies, tenant-level controls — which will help with enforcement but will not make the one decision that matters, which is deciding what counts as business-critical.
Low-Code Governance Design — we set the tiers, write the promotion checklist, find the automations running under departed employees' accounts, and leave you with a register short enough that somebody actually maintains it.