The four actual limits
The first limit is branching complexity. Make and Zapier handle simple conditional logic well. Once you need a workflow with more than about three branches, or where branch conditions themselves have conditions, the visual builder becomes harder to read and reason about than code would be. This is not a criticism — it is the nature of visual representations of logic. At a certain point, a function is a better abstraction than a flowchart.
The second limit is error handling. No-code platforms have improved at this, but they still assume a happy path. When something upstream returns an unexpected structure, the automation tends to stop silently or send a generic error notification. Building proper recovery behavior — retry with backoff, route to a human reviewer, log the anomaly for later inspection — requires either a lot of workaround scaffolding in the platform or a decision to move outside it.
The third limit is state. Most no-code automations are stateless. They receive a trigger, do a thing, finish. If your workflow needs to remember something from a previous run, or coordinate across concurrent operations, you end up storing state in a spreadsheet or database and building logic around that, which is a significant source of eventual brittleness.
The fourth is cost structure. No-code platforms charge per operation. For low-volume workflows that do not require much complexity, this works fine. For workflows that run thousands of times a day or have complex multi-step logic, the monthly cost of the platform can become significant relative to the cost of a purpose-built solution that runs on infrastructure you already pay for.
How to recognize when you have hit the ceiling
The most reliable signal is that your team has started building a second layer of complexity to support the automation. You have a spreadsheet that stores state for the Make scenario. You have a Slack bot that handles the cases the automation does not cover. You have someone who checks the error log every morning as part of their routine.
None of these things are failures of the team. They are rational responses to the constraints of the tools. But they are also a signal that the tool is no longer doing what it was supposed to do — reduce operational overhead.
When to stay with no-code
If the workflow is stable, low-volume, does not require complex error handling, and the team can maintain it without engineering support — stay with no-code. Replacing a working Make scenario with a custom agent because it feels more sophisticated is a bad use of time and money.
The point at which a transition makes sense is when the maintenance cost of the no-code solution exceeds what it would take to build and maintain a narrower custom system. That threshold is different for every team and context. We try to be honest about it when clients ask, and we have sent people back to Make when that was the right answer.