Low-code MES platforms made a genuinely appealing promise: put app-building in the hands of the manufacturing engineer or line supervisor who actually understands the problem, skip the months-long IT project queue, and get a working andon board or work-instruction app running in days. Tulip Interfaces has been the platform most associated with this pitch, though it’s not the only one — Tempo Automation’s shop-floor tools, Poka (owned by Ivanti), and elements of Siemens’ Opcenter Execution and Rockwell’s FactoryTalk suite have all leaned into some version of “citizen developer” app-building for manufacturing. Two years into real adoption, enough plants have accumulated enough homegrown apps that the industry is having an honest conversation about what this approach is actually good for, and where it quietly turns into a mess.
This is worth examining now because low-code MES vendors are pushing hard into 2026 planning cycles as the faster, cheaper alternative to a traditional MES rollout. That pitch is legitimate in places. It’s also incomplete, and the plants that piloted these tools a couple of years ago are the ones who can tell you why.
What Tulip actually is
Tulip is a cloud-connected, no-code/low-code application platform purpose-built for manufacturing. Instead of writing a program instruction by instruction, an app builder drags together widgets — a table, a step-by-step instruction sequence, a variable, a trigger — into a “workflow” that runs on a tablet, a fixed-mount terminal, or a station PC. It ships with connectivity to PLCs, IoT devices, barcode scanners, and torque wrenches through its own edge device (the Tulip Player and associated gateways), plus a data layer that lets you build dashboards and reports off whatever the app collects. The pitch is that a process engineer with no software background can build a digital work instruction, an andon system, or a simple quality-check app without opening a ticket with IT or waiting for a systems integrator.
That pitch is not marketing fiction. For a specific class of problem, it holds up well in practice.
Where it genuinely earns its keep
Low-code app-building is at its best on the shop floor’s long tail of small, high-friction problems that never justify a full MES module: a changeover checklist that used to live on a laminated sheet, a manual defect-logging form that used to be a spreadsheet someone forgot to update, a simple first-article inspection app, an andon trigger tied to a light stack. These are use cases where the “app” is really digitizing a paper process or a spreadsheet, where the logic is straightforward, and where the person closest to the process is also the best-qualified person to design the interface.
The other place it earns its keep is speed of iteration. A traditional MES change — even in a well-configured, well-supported suite — usually runs through a change request, a test environment, and a release cycle. A low-code app can be revised on the floor in an afternoon based on operator feedback. For processes that are still being tuned, or that vary a lot between product families, that iteration speed is a real advantage, not a gimmick.
Where it quietly breaks down
The trouble starts exactly where you’d expect: scale, ownership, and lifecycle. A citizen developer builds a genuinely useful app for their line. Word gets around. Six months later, three other lines have copied and modified it. A year after that, nobody’s entirely sure which version is authoritative, who’s responsible for it when the builder changes roles or leaves, or whether it’s pulling from the same data model as the app next to it. This is shadow IT with a friendlier name, and manufacturing IT teams are now dealing with the same sprawl problem that corporate IT fought with departmental Access databases and Excel macros a generation ago — just now it’s touching production data and, in some cases, quality records.
The failure mode isn’t usually dramatic. It’s slow: duplicate apps with slightly different logic, inconsistent naming and units across “the same” metric on different lines, no real version control, and no clear answer to “who approves a change to this app before it goes live on a regulated process.” For general work instructions and andon boards, that’s an annoyance. For anything touching genealogy, in-process quality holds, or data destined for a quality record, it’s a real risk.
A practical governance framework
The plants that have handled this well didn’t ban citizen development — they tiered it. A workable version looks like this:
- Tier 1 — Free build, light governance: visual aids, checklists, non-regulated data collection, andon and messaging apps. Owned by the line, built by whoever’s closest to the problem, reviewed informally.
- Tier 2 — Registered apps, formal review: anything feeding a dashboard, KPI, or OEE calculation that other teams rely on. Requires a named owner, a change log, and a basic test step before deployment — even if that’s just a peer review, not a full change-control board.
- Tier 3 — Regulated or genealogy-critical: anything touching traceability, quality holds, work-order dispositioning, or data that ends up in a compliance record. This belongs in a configured module of a traditional MES suite — think Rockwell’s FactoryTalk, Siemens Opcenter, or a similarly validated system — with proper role-based access, audit trail, and IT-owned change control. Low-code platforms can feed data into these systems, but the system of record for anything audit-relevant shouldn’t be a tablet app someone built between shifts.
The other piece that matters is version control and an app registry — a simple, IT-maintained list of what apps exist, who owns each one, what data model they touch, and when they were last reviewed. Without that single artifact, governance is theoretical. With it, a plant manager can actually answer “how many apps do we have running on the floor” without guessing.
How it stacks up against the alternative
Traditional MES suites win on structure: built-in ISA-95 data models, audit trails, validated change control, and integration patterns that assume the software is a system of record, not a convenience tool. They lose on speed and cost of iteration — configuring a new workflow often means a project, not an afternoon. Low-code platforms invert that tradeoff almost exactly. Neither approach is wrong; they’re solving for different failure modes. In our assessment, treating low-code MES as a replacement for a traditional MES backbone is the mistake that produces the sprawl story above. Treating it as a fast front end that complements a properly governed data layer is where it actually delivers on the promise.
Who this fits and who it doesn’t
Tulip and its low-code peers fit discrete manufacturers with high product mix, frequent changeovers, and a strong bench of process engineers who are comfortable owning software without being developers — think contract electronics manufacturing, medical device assembly, or automotive sub-assembly. It may not suit plants without any IT governance capacity at all, since the tool doesn’t create discipline on its own; it just makes it easier to skip. It’s also a weaker fit for heavily regulated, audit-intensive processes where the system of record needs validated change control from day one — that’s still a job for a configured MES module, not a citizen-built app, however good the app is.
The honest bottom line: low-code MES platforms are a real tool with a real, narrower job than the pitch suggests. The plants getting the most out of them in year two aren’t the ones who built the most apps. They’re the ones who figured out, early, which apps deserved a tier and an owner — and which processes never belonged in a tablet app to begin with.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
