There’s a lot of talk about no-code and low-code builders for workflow automation, and the pitch is always about reducing the need for developers and letting business users own their own processes. Which sounds great in theory.
But I’m skeptical about what “no-code” actually means in practice, especially when we’re talking about BPMN-level complexity. Does it mean you can drag and drop boxes and draw arrows? Because that’s not the same as actually building a workflow that handles edge cases, error conditions, complex conditional logic, and integration with real systems.
I’m trying to understand the actual boundary. What can you genuinely build without a developer versus what’s still going to require engineering expertise, even if the interface is visual? And if business users are building stuff in a no-code builder, who’s responsible for maintaining that when things break or requirements change?
From a TCO perspective, does a no-code builder actually let you reduce headcount, or does it just let you shift some work from developers to business users, which might not be a cost reduction so much as a redistribution of effort?
Has anyone who isn’t a developer actually built and deployed a meaningful workflow in a no-code builder without developer support? What actually worked and what required going back to engineering?
We gave our operations manager access to our no-code builder to build a vendor management workflow. She could handle the basic stuff—“if approval comes back, do this, otherwise do that.” She built the first version in a day. But when we needed to add conditional logic based on vendor tier, or handle cases where the approval takes longer than expected, she hit a wall. She built 75% of what was needed, and a developer finished the rest in a couple of hours.
The real value wasn’t that she replaced a developer. It was that she handled the straightforward parts, and the developer only had to handle the complex conditional logic. That’s a genuine efficiency gain because the developer wasn’t wasting time on boilerplate.
TCO-wise, yes, it helped. Less developer time overall, but not zero developer time.
No-code builders are best for processes that are 80% straightforward and 20% complex. Drawing the flow, setting basic conditions, connecting to APIs—all doable without code. But the moment you need custom logic, data transformation, or complex error handling, someone with engineering skills needs to step in.
It’s not about replacing developers with users. It’s about letting each person do what they’re best at. Business users model the process, developers handle the exceptions and custom logic.
For BPMN specifically, the visual builder gets you most of the way, but BPMN has a lot of subtle nuances about gateways, intermediate events, and subprocess handling that actually matter in production. A business user might not know they need a subprocess handler until the workflow fails.
Maintenance is actually the bigger question than initial build. We had three workflows built by business users without developer involvement. Six months later, one of them broke because an API changed format. The business user who built it didn’t know how to fix it. We ended up assigning a developer to maintain these things anyway, which kind of defeats the purpose.
No-code is great for speed, but if you want actual TCO reduction, you need to think about who maintains these workflows long-term. That usually still requires developer time.