A good low-code application still needs an operating plan

Low-code platforms deliver on their central promise. A working application in days is normal rather than remarkable. The interesting question is what the estate looks like after three years of that, and the answer depends almost entirely on decisions made before the first application was built.

The failure mode is not a bad application.

It is forty applications nobody catalogued. Overlapping data, inconsistent access control, no owner recorded, built by people who have since changed roles, each depending on a spreadsheet somebody maintains by hand. That is harder to unwind than the spreadsheets it replaced, because it now has users who depend on it and no one person who understands it.

This does not happen because the platform is bad. It happens because delivery was fast enough that governance never became urgent, and by the time it did there was already too much to catalogue retrospectively.

Decide what belongs on the platform, in writing.

Some things clearly do: a request and approval workflow, a register, an inspection form, a small departmental tool with a few dozen users. Some things clearly do not: anything holding regulated data as its system of record, anything a customer touches unauthenticated, anything with a genuinely complex transaction model.

The middle is where judgement is needed, and the useful test is what happens when it grows. If the plausible success case is ten times the users and twice the integrations, ask whether the platform still fits then. Migrating a successful application off a platform is expensive; deciding it was the wrong home before building costs an afternoon.

Ownership is the field that matters most.

Every application needs a named person, not a department, who is accountable for whether it still does the right thing. That person changes over time, which is exactly why the field has to exist and be reviewed. An application with no owner is an incident waiting for a trigger.

Pair it with a review date. Most applications built to solve a temporary problem outlive the problem, and nobody notices until somebody asks why a workflow still routes to a team that was reorganised.

Governance has to be proportionate or it gets bypassed.

A review gate that takes three weeks guarantees that people build outside it. A gate that takes a day, applies real scrutiny only to applications touching sensitive data or large user groups, and waves through a departmental form, gets used.

The trick is to grade on consequence rather than on effort. A tiny application handling personal data deserves more attention than a large one that reads public reference data.

Environments and naming are boring and load bearing.

Separate development from production, even when the platform makes it easy not to. Agree a naming convention on day one. Decide where data lives and which connections are permitted. None of this is interesting, and all of it is the difference between an estate somebody can audit and one that has to be explored.

Draw the line between citizen building and engineering.

Business teams should be able to build things without asking permission, or the platform has no advantage over a backlog. What they should not be doing is integrating with a finance system, handling personal data at scale, or building something the organisation will depend on operationally.

Write that line down and make it about categories rather than about people. Then give the teams on the near side of it real support: templates, components, a place to ask questions, and somebody who will review a design without turning it into a project.

What good looks like.

Applications delivered in weeks. A catalogue that says what exists, who owns it and when it was last reviewed. A gate light enough that people use it. And a clear, unembarrassed answer to the question of what happens to any of it when the person who built it leaves.