When do you outgrow Zapier, Make or n8n?

Three moments, and none of them is the one people expect. When a flow has to make a judgement only your business can make. When a flow can fail without anybody finding out. When the flows start depending on each other. Until one of those is true, these tools are the right answer, and we will say so and go home.

That last part is worth saying first, because the advice you usually get on this question is sold by somebody with something bigger to sell. Most businesses running a handful of flows should carry on running them.

What are these tools actually good at?

Moving information between applications that were never designed to talk to each other. That is a real problem and they solve it well. A trigger, a few steps, a destination: a new order raises a row, an attachment files itself, a form fills a sheet, somebody gets told. Anyone in your office who is good with a spreadsheet can build one, without a developer, without a project and without asking permission.

They also do something nobody gives them credit for. Every flow in your account was built by a person who felt a specific cost every day and described exactly what should happen instead. That is a better statement of what your business needs than any consultant would produce by asking, and we will come back to it at the end.

When does a flow need to know something only you know?

This is the first limit, and it arrives quietly.

“Put this order into the billing system” is a transport problem. These tools were built for it. “Put this order into the billing system unless the customer is on credit hold, and if the item is short, take it from whichever godown can ship it soonest” is a judgement problem. It needs your credit rules, your stock positions and your dispatch geography, and none of those are in the order.

You can force it, and people do. A lookup table in a sheet. Three filter branches. A second flow that runs first and writes a flag the first one reads. It works, for a while. What has happened is that a piece of your business’s logic now lives on a canvas where nobody can read it as a sentence, nobody can test it before changing it, and nobody can answer why it decided what it decided last Tuesday.

A check you can run today: take your most important flow and ask somebody who did not build it to explain out loud what it does and why. If they cannot, the rule is not written down anywhere in your business. It exists only as boxes and arrows, in an account, in one person’s head.

How would you know if a flow stopped?

The second limit, and the expensive one.

These tools fail quietly, and that is not a defect in them. A run errors, the error is logged, perhaps an email lands in the inbox of whoever built it. The business carries on, not knowing. The order that never reached billing is not discovered as an error; it is discovered as a missing invoice, or as a customer asking where their goods are.

So ask two questions about the flow you depend on most. Who would notice if it stopped tonight? And how would they notice? If the honest answer to the second is “the customer would ring”, you do not have an automation. You have an undeclared dependency.

What fixes this is not a cleverer tool. It is a habit, and it is ordinary engineering: a failure reaches a named person the same day, carrying what failed, what it was holding and what to do about it, and the things that failed sit in a queue somebody can retry once the cause is fixed. Unglamorous, and the whole difference between automation you can run a business on and automation you hear about from a customer.

When does the twentieth flow become the problem?

The third limit is dependency, and it is the one that decides most cases.

One flow is a tool. Twenty flows are a system that nobody designed. The nineteenth writes a row the twentieth reads. Somebody renames a column in a sheet and something stops three flows away, for reasons that take a day to find. There is no list of what runs where, no way to try a change somewhere safe first, and no record of why any of it was built the way it was. Often the person who built the most important ones has changed jobs.

Notice what is not happening here. Nothing is broken. Every flow still does exactly what it was built to do. What has gone is anybody’s ability to change anything with confidence, and that is what outgrowing actually means. Not that the tool became too small. That your dependence on it outran your understanding of it.

What about what it costs?

Worth being plain about, because it is usually what makes an owner finally ask the question, even though it is rarely the best reason to act.

These tools charge by how much they do. Every run, every step, counted and billed. Which means the bill grows in exact proportion to how well the automation is working, and the month you finally get the whole order desk flowing through it is the month the subscription starts to hurt. That is a strange incentive to have sitting underneath something your business depends on, whatever the number attached to it.

So do you throw it all away?

No, and it is the same answer as replacing or connecting the software you run: the question is never the tool, it is which flows fail which test.

Take the list of what you have built. Against each one, three questions. Does it make a judgement only your business can make? Would anybody know if it stopped? Does anything else depend on it? Flows that fail none of the three stay exactly where they are, and most of them will. The flows that fail one or more are your specification: those are the ones that should become your own, watched, tested and written down in something a person can read.

Most businesses that have genuinely outgrown these tools have outgrown them in three or four places, not everywhere. Anyone who tells you otherwise has a platform to sell you.

What should you keep from what you built?

More than you would think, and it is the part most often thrown away.

Every flow in that account is documented demand. A real person, carrying a real cost, describing precisely what should happen instead, and caring enough to build it. That is worth more than the same answer given in a meeting, because it was built rather than requested. Nobody makes a flow for a problem they do not have.

So when the work moves, the flows move with it as evidence rather than as rubbish: what was automated, by whom, in what order of pain. It is the most honest requirements document your business owns, and it cost you nothing to produce.

The furniture maker is what the far side of this looks like. Each stage of an order confirmed on a phone by the person doing it, every order on the owner’s board, nothing retyped between the quote and the dispatch. None of that is beyond a no-code tool to attempt. All of it is beyond one to be trusted with.

So: not when somebody tells you the tool is unprofessional, and not when you reach a particular size. When a flow makes a judgement nobody can read, when a failure reaches you through a customer, and when nobody dares touch the nineteenth flow. Those are three questions about systems you already have, and the answers name the handful worth moving. Everything else stays where it is, which is how we scope AI and automation work in the first place.