You did the sensible thing. You noticed your team was copying information between systems, and you bought something to stop that — Zapier, Make, n8n, one of the builders inside a platform you already pay for.
It worked. Some of the copying stopped.
And now you have a canvas to maintain, a subscription to pay, and one person who understands the flows.
What these tools are genuinely good at
Let us be straight about this before the argument, because a fair comparison is more useful to you than a sales one.
Workflow builders are excellent at a specific job: when this happens over here, do that over there. A form submission becomes a row in a sheet. A payment creates a record. A file lands and a notification fires. That is real work, it is genuinely removed, and for a lot of small businesses a handful of those flows is the right answer and the whole answer.
If two systems need to stay in step and nothing else about your process is broken, buy the builder. Do not let anyone talk you into a project.
The four things a canvas does not do
The trouble starts when you ask it to run a process rather than connect two points.
- It does not own the whole path. A flow fires on a trigger and finishes. Nothing is watching the job from arrival to finished, so nothing can tell you a job is halfway through and stuck.
- It does not notice absence. This is the big one. A flow triggers when something happens. When the thing never happens — the file that did not arrive, the confirmation that never came back — there is no trigger, so there is no alert, and silence looks identical to success.
- It does not hold a decision. Real processes need to stop and ask a person, then continue with that answer. Builders can send an approval message, but the state of “waiting for Sarah, since Tuesday, on this specific job” is not something the canvas holds and shows you.
- It does not survive change on its own. A service updates its interface, a field gets renamed, an account expires. The flow breaks, and it breaks quietly, and it stays broken until somebody notices work stopped arriving.
The maintenance nobody quoted you
Count your flows. Then ask who checks them.
In most businesses that has an answer, and it is a name. One person built the flows, understands what connects to what, and gets asked when something looks wrong. They frequently did it as a favour, on top of their real job, because they were the one who was interested.
That is a genuine risk and it has nothing to do with their competence. It means your operations depend on one person’s memory of an undocumented diagram. Ask what happens the month they leave, and notice whether the answer is a plan or a wince.
None of that makes the tool bad. It makes it a tool: it sits there, it does nothing until somebody works inside it, and it hands the work of keeping it alive back to you.
A canvas is not an engine
The difference is not sophistication. It is shape.
A canvas is a place you go to build and maintain connections. An engine is the thing that runs the work: it picks a job up when it arrives, carries it the whole way, handles what it can handle, notices when something is missing, keeps a record of everything it did, and stops only where a person should genuinely decide — arriving with the answer already drafted.
Put plainly: we don’t sell you the canvas. The point is to hand you the running thing. A builder is a set of parts and the assembly is left to you. That is a completely legitimate product — it is just not the same product as the work being gone.
How to tell which one you actually need
Six questions. Answer them about your own setup and the answer falls out without anyone selling you anything.
- Do your flows connect two points, or run a process? Two points is builder territory. A process with stages, waits and approvals is not.
- If a record never arrived, how would you find out? If the honest answer is “a customer would tell us”, nothing is watching for absence.
- Can you see, right now, what is in progress and where it is stuck? Not the data in each system — the state of the work.
- Who fixes a broken flow, and how do they know it broke? If both answers are one name and “eventually”, that is your risk.
- How many of your flows exist to compensate for another flow? A patch on a patch is a sign the shape is wrong, not that you need a seventh flow.
- Could a new person understand the whole thing from what is written down? If it only exists on a canvas and in someone’s head, it is not documented.
Why I am careful about this argument
I use automation hard, including AI, and I have built exactly the sort of quick flow this piece is about. The version of this argument that says “no-code tools are bad” is wrong and I am not making it.
What I got burned by was different: I let a fast-moving setup run without any structure underneath it, on a hosting panel I was building with an AI agent doing the typing. It looked like it was working. Then hours disappeared into bugs that should not have existed, and the agent kept reporting success while the code kept not working. Better prompts did not fix it.
Intelligence bolted onto a bad structure is not intelligence. It is faster chaos. That is the same failure as forty flows on a canvas with nobody watching them — the speed is real and so is the mess, and the second one arrives later.
What to do next
Sort your flows into the two groups this week — point-to-point, and process-propping. Then count one flow at both ends and find out whether anything is going missing.
If the second group is where your problems live, the six parts of an engine describes what it takes to run a process end to end, and the gate covers the part that decides whether you can trust it.
If you want the whole picture instead of one workflow: tell us what’s still manual. You get a map of every point where your business stops and waits for a person, what that costs you in hours, and which of those an engine would take over first. Free, yours to keep, and useful even if you never hire us — including on the days the honest answer is that you should not build anything yet.
Common questions
So should we cancel our automation subscription?
Almost certainly not, and doing it as a first move would cost you working flows for no gain. The useful exercise is to sort your flows into ones that connect two points cleanly and ones that are propping up a process. The first group is fine where it is. The second group is where the maintenance and the silent failures live, and that is the part worth changing.
How do I find out if flows are failing silently right now?
Pick one flow and count both ends for a week. How many things should have gone in, and how many came out the other side? Do it by hand, from the source system rather than from the automation’s own log, because a flow that never triggered has nothing to report. A gap between the two numbers is your silent failure rate, and most people have never measured it.
Our builder has error notifications turned on. Isn’t that covered?
That covers errors, which is not the same as absence. An error notification fires when a step ran and failed. It cannot fire when nothing ran at all, because there was nothing to fail. Those are the failures that hurt, since they look exactly like a quiet day.
Is there a size of business where a canvas is genuinely enough?
Yes, and it is more common than anyone selling builds will tell you. If your volume is low, your flows number in single digits, the person who maintains them is you, and nothing you run would cause real damage by being a day late, a builder is the right tool and a build would be spending money to feel organised.