One of the big promises I keep seeing is that non-technical teams can build their own automations using visual builders. I tested this with a couple of people on our ops team, and the result was interesting—they could definitely put together something, but whether it was production-ready was another question.
We wanted a simple ROI calculator that would let a manager input labor hours, costs, and expected efficiency gains, then output potential savings. Straightforward enough. Using a no-code approach, they got it working in a day. But the logic for handling edge cases, data validation, and making sure the calculations didn’t break when someone entered bad data—that’s where it got fuzzy.
The visual builder is great for happy-path scenarios. But when you’re building something that your finance team will actually rely on for decision-making, you need robustness that the no-code interface made harder to implement.
I’m not saying no-code is bad—it’s not. But I think there’s a gap between “someone without coding experience can build a workflow” and “someone without coding experience can build production-grade automation.”
Where do you hit the actual limits? Is it always around validation and error handling, or are there other areas where no-code builders force you back to someone who can write code?