Genuine question for people running production workflows in n8n, Zapier, Make: at what node count does the canvas stop helping you and start being the thing you're maintaining?
— Mitchell Tessier (@tessi3r) May 13, 2026
every operator I talk to has some sort of maintenance frustration, but it's hard to put a number on it
I remember where I was when I first used Zapier.
2016. Young marketer at a small startup. The growth-hacking era, everyone was scrappy, everything was a funnel.
I'd come to startups in a roundabout way: graphic designer → comms → move to Canada → fintech marketer. New world. New tools.
I remember how effective and accomplished I felt. Pulling a response out of an email, dropping it into a Google Sheet, kicking off a content campaign, all without filing a ticket. Ten years ago, that felt like the future.
Workflow canvases have had their time in the sun. And I think there's something we all got wrong about them. The people who built canvases got it wrong. The people who bought them paid for the mistake. The second wave, me included, built new ones on the same broken assumptions.
The promise
It was a very simple, and effective pitch: You don't need to be an engineer. Drag some nodes, connect them, ship something that used to require a sprint.
For a specific class of problem, this worked. A trigger, two or three steps, no edge cases. Email comes in, add a row, send a Slack message. The demo workflow that every canvas vendor used to sell the tool was the workflow the tool was actually good at. The feeling of doing it yourself was the product.
And it was a real feeling. The 2016 version of me wasn't wrong to feel like a wizard, Harry. The tool let me ship something useful without depending on an engineer who didn't have time for me. That's a real win for a real user with a real problem.
Syntax was never the hard part
But what nobody really seemed to want to reconcile was the fact that building anything non-trivial on a canvas still requires programming-shaped thinking. Data flow. Looping. Branching. Handling nulls. The shape of a conditional that depends on the shape of the data coming in.
The canvas hides syntax. But syntax was never the hard part. Logic was.
You can drag a node onto a canvas without knowing what a variable is. You can't actually use the node to do anything interesting without thinking about variables. You're now a programmer who doesn't know they're programming, working in a medium designed to obscure the fact that you're programming.
This is fine for the three-step workflow. It falls apart fast for the twenty-step one. Loops that need to break early. Branches that share state. Error handling that depends on what kind of error it is. The canvas has answers for some of these. The answers are usually worse than the equivalent in code, because the medium wasn't built for them. They were retrofitted in.
The artifact is sealed
The other thing nobody priced in: The workflow you build on a canvas is sealed inside the tool that made it.
You can't grep it, diff it, refactor it with a model, or review it the way you review a pull request. The medium doesn't support the same kind of review surface that code supports. And if you're asking it to do programmer-adjacent things, this might be an issue.
Maybe this was once tolerable, when the canvas was a tool for the operator who wasn't going to write code anyway. The maintenance cost was real but it was the cost of having any automation at all, and the alternative was no automation. The tradeoff made sense.
It doesn't anymore. The operator who used to need a canvas can now ship a working script with an AI assistant in an hour. The medium they were supposed to be afraid of, the medium the canvas was designed to protect them from, is the medium AI is most useful inside of. Challenges abound, but those challenges are different and (I believe) solvable.
Code is grep-able, diff-able, and legible to a model that can read, refactor, debug, and explain it. A node graph is none of those things. The accessibility argument that defined the category for a decade flipped while the category was still selling on it.
There is no node count
So back to the tweet. At what node count does the canvas stop helping you and start being the thing you maintain?
There isn't one. The trap is structural, not quantitative.
The canvas was never doing the thing it looked like it was doing. It looked like it was making the work easier. It was actually deferring the work to a phase the buyer didn't know to price in. The setup was cheap. The maintenance was expensive. The marketing only talked about the setup.
This is what I think most operators are feeling when they describe their canvas frustration. The problem isn't size. It's that they're maintaining an artifact they can't reason about, that nobody else can confidently touch, and that the tool itself can't help them improve. The thing that was supposed to give them leverage took it away the moment shit got real.
You don't outgrow the canvas. The canvas outgrows you.
The medium flipped
The canvas was the right answer for a particular user in a particular era. That era ended when the user got an AI assistant. Not in a vague "AI is changing everything" way. In a specific, measurable way. The non-coder the canvas was built for can now write, read, run, and debug code with a model in the loop. The thing the canvas was protecting them from stopped being scary.
Meanwhile the canvas itself didn't get more accessible. If anything it got less so, because the medium underneath it (a graph stored in proprietary JSON) is something models struggle to reason about. You can't ask Claude to refactor your Zap. You can ask it to refactor a Python script.
The accessibility argument inverted. The medium that was supposed to be the gentle on-ramp is now the dead end. The medium that was supposed to require an engineer is now the one that doesn't.
What we built
I'm not writing this from outside the category. We built one too. We watched our customers love it and we watched some of them hit the wall I described above. We had our assumptions, and those assumptions were challenged. We watched the ground move under the whole premise faster than we expected.
I don't think the people who built canvases were wrong. The 2016 operator was a real user with a real need, and the canvas was a reasonable response to it. I don't think the people who bought canvases were wrong either. The tradeoff made sense when it made sense, and the alternative was nothing.
But the world the canvas was built for may no longer exist. We've been selling and buying tools designed for a user who got upgraded out from under us. The reckoning isn't that canvases are bad. It's that the operator the canvas was built for doesn't need that specific tool anymore. They need something that meets them where they actually are now. Somewhere closer to code than to nodes.