Your plant already runs on low-code. It has for thirty years, and it was called Excel.
Somewhere in your operation right now is a spreadsheet that schedules production, calculates a blend, or tracks OEE, built by a process engineer who left in 2019, understood by nobody and quietly load-bearing. That spreadsheet is the honest ancestor of today's low-code and no-code platforms, and it's the reason the current wave deserves both enthusiasm and a hard look. The tools are genuinely powerful. So was Excel. That was always the problem. The empowerment case is real Start with why plant-floor low-code is spreading, because the appeal is legitimate. Platforms like Tulip, Mendix, Ignition Perspective and Microsoft Power Apps let the people who actually understand a process build the tool for it, without waiting eighteen months in an IT backlog. Gartner has forecast that developers outside formal IT would make up at least 80% of the low-code user base, and on the plant floor that means controls engineers and line leads shipping their own dashboards and work-instruction apps.
The documented wins are substantial. A Forrester economic study, commissioned by one frontline-operations vendor so weight it accordingly, modeled a 448% three-year return with defect reduction and labor-efficiency gains. When an engineer who knows the process builds the app in an afternoon instead of specifying it across six months, real value gets created. None of what follows disputes that.
The technical-debt case is also real
The trouble is that every property which made the plant-floor spreadsheet dangerous is present in low-code, now connected to live equipment and cloud data.
Consider the spreadsheet precedent honestly. Decades of research by Ray Panko found that around 90% of real-world spreadsheets contain errors, and that error rates compound as models grow. The reason wasn't that people were careless; it was that spreadsheets had no testing, no version control, no code review, and no owner once the author moved on. Low-code platforms inherit that governance vacuum by default and add reach: an app that a spreadsheet couldn't touch, a live PLC tag, a cloud database, a production write, is now one drag-and-drop connector away.
The scale of ungoverned building is already documented. A security analysis found the average large enterprise carrying roughly 80,000 applications built outside the normal software development lifecycle, with a majority containing security weaknesses (that figure comes from a low-code security vendor, so treat it as directional rather than precise). And the risk isn't hypothetical. In 2021, security researchers found 38 million records exposed across dozens of organizations through a default API permission setting on a popular low-code portal platform. Nobody was hacked. The default was simply wrong, and citizen developers had no reason to know it.
Put those together and the technical-debt bomb has a clear shape: undocumented apps, built by one person, connected to production systems, with no test coverage, no versioning, and no plan for the day the builder changes roles. Key-person risk, at plant scale, wired into operations. The discipline that defuses it
The answer is not to ban low-code, which fails the same way banning spreadsheets failed. The answer is to give citizen development the governance that controls engineering already applies to everything else with the power to affect production.
Treat a low-code app that touches OT data as the control asset it is. Under the ISA/IEC 62443 framework this audience already works within, an app pulling PLC tags into a cloud dashboard crosses a zone boundary and functions as a conduit; it deserves the same zone-and-conduit assessment as any other path between levels. That single reframing, low-code apps are conduits, resolves most of the security question.
Stand up a center of excellence, even a lightweight one. An inventory of what's been built, a named owner for each app, tiered environments and a promotion path from prototype to production. The model is well-established, and tellingly, even the platform vendors have had to turn governance into a product feature because ungoverned adoption caused real pain.
Define, in advance, when an app must graduate to real software. A prototype that reads data and helps one person on one shift can live under light governance. The moment an app writes to a production system, becomes multi-site, gets embedded in a validated process, or has someone's shift depend on it, it has stopped being a convenience and become infrastructure, and it needs the version control, testing and documentation that infrastructure requires.
The honest verdict
Low-code on the plant floor is both things at once, and pretending otherwise is how organizations get hurt. It genuinely empowers engineers, and it genuinely manufactures technical debt, and which one dominates is decided entirely by governance, not by the tool.
If I had to reduce it to one rule for this audience: apply the discipline you already apply to a PLC program, change management, testing, documentation, ownership, to any low-code app that can affect production and let everything below that line stay fast and free. Do that, and citizen development becomes the backlog-busting asset it promises to be. Skip it, and in five years someone will be reverse-engineering a business-critical app the way your team currently reverse-engineers that spreadsheet from 2019, except this one is connected to the line.
