Strategy
Low-code, and where the ceiling is
The app the operations manager built is usually the right first move, and the objection to it is almost never that it should not exist. It is what happens at the ceiling, and who is standing under it.
In short
- Low-code platforms genuinely build real applications, and an argument that they cannot is wrong in a way any practitioner will immediately recognize. The limit is not capability, it is that the platform is the ceiling.
- The ceiling is structural rather than technical: a single vendor sets the pace of change, the scripting stack is whatever the platform ships, and testing, identity and audit exist only to the degree the platform offers them.
- The characteristic failure is reputational before it is technical. The app was built by a named person outside IT, so when it breaks at scale it breaks on their standing rather than on a vendor's support contract.
- The signals you are approaching the ceiling are organizational: people outside the original team now depend on it, an auditor has asked a question about it, or it has become something nobody is willing to change.
- Approaching the ceiling does not mean rebuilding everything. Usually one capability crosses out of the platform and the rest stays exactly where it is.
Somebody in operations built an application. Not a spreadsheet, an actual application, with screens and a database and people using it on a tablet on the floor. They built it in a low-code platform, possibly one that came bundled with the control system, and it works. It was delivered in weeks, it cost a fraction of a project, and it solved a problem that had been sitting in a backlog for two years.
We want to be precise about our view of this, because the version of this argument you usually hear from firms like ours is wrong. These platforms build real applications. The industrial ones ship genuine browser-facing operational apps and there are thousands of integrators who do exactly that, competently, every day. Anybody telling you low-code cannot build production software is describing a market from a decade ago, and a practitioner will spot it immediately.
The limit is real, but it is not capability. It is that the platform is the ceiling.
What the ceiling is made of¶
Inside the platform, you get what the platform decided to offer. That is the entire trade, and it is a good trade for a long time. It stops being a good trade at the point where the things you need are the things a platform structurally does not provide.
| Constraint | What it means in practice |
|---|---|
| One vendor sets the pace | Your ability to adopt anything new (a protocol, an identity standard, a language feature, a security control) is bounded by the vendor's roadmap, and their priorities are set by their whole customer base rather than by you. |
| The scripting stack is whatever shipped | You write in the language and runtime the platform embeds, on the version it embeds. Modern dependency management, current libraries and the ability to hire for the skill are all outside your control. |
| Test and release discipline is bounded by the tooling | Automated tests, code review, staged environments and a real deployment pipeline exist to the extent the platform supports them. Where it does not, the mitigation is care, and care does not survive staff turnover. |
| Blast radius is shared | An application living inside an operational platform shares that platform's exposure. A compromise or a bad release is not neatly bounded to the app, which is a different risk conversation than a separate system with its own credentials and its own failure domain. |
None of these is a reason not to start in low-code. They are a description of what you are choosing, so that you recognize the moment the choice stops fitting.
The failure is reputational before it is technical¶
This is the part that gets least attention and causes the most damage. The application was built by a named individual who does not work in IT. There is no vendor support contract behind it, no team that owns it, and often no second person who understands it.
So when it does hit a limit, it does not fail the way purchased software fails. It fails publicly, on one person's standing, usually during something that matters. That person then becomes extremely reluctant to change it, which is its own problem: an application nobody will touch is a constraint on the process it was built to serve.
The signals, which are organizational¶
You are approaching the ceiling when:
- People outside the team that built it now depend on it, including people who do not know it is a low-code app.
- An auditor, a customer or a regulator has asked a question about it that requires knowing who changed what, and when.
- It needs to talk to something the platform has no connector for, and the workaround is a scheduled export.
- Somebody has asked whether it can be accessed by people outside the organization, which is an identity and exposure question the platform may not answer well.
- It has become something nobody is willing to modify before a busy period.
- The person who built it has changed role, or is about to.
What to do about it, which is less than people expect¶
The instinct is to treat this as a rebuild, and it very rarely is. In most cases exactly one capability needs to leave the platform (the part that has to be identity-aware, or auditable, or reachable by outsiders, or connected to something the platform cannot reach) and everything else is fine where it is.
The good version of this is a system that sits beside the platform rather than replacing it: it takes over the one capability that crossed the ceiling, talks to the platform over a defined interface, and leaves the screens people already know exactly as they are. That is a much smaller piece of work than a replacement, and it keeps the thing that made low-code the right answer in the first place.
The bad version is a replacement project justified on the grounds that the original was built the wrong way. It usually takes longer than the platform took, delivers the same screens, and spends its budget re-earning ground that was not lost.
If what you actually need is somebody to run it¶
One honest possibility worth naming, because it is a common one and it is not a software project at all. If the real problem is that nobody is keeping the systems you already have running (patching them, backing them up, answering the phone when something breaks at seven in the morning) then what you want is managed IT rather than an application, and the sensible move is to ask a provider rather than a builder. That is a different division of this firm (opens in a new tab), and it is a different engagement with a different shape; we would rather point you at it than quote you a build for a problem that is not one.
Related reading
- Strategy5 min read
When a spreadsheet becomes a system
Most operations run on a spreadsheet, and most of them should carry on doing it. But there is a real line, it is not where people expect, and crossing it is not obvious from the inside.
- Strategy4 min read
Should your ERP partner build it?
It is the first question to ask and the one most often skipped. How to tell what a partner will take on, what they will decline, and why the answer is rarely about their ability.
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.