Make or Zapier: which one for automating a small or mid-sized company?

It is the point almost nobody explains, and it is the one that counts.

Zapier counts one task per successful action. A Zap that receives a form and creates a record in your CRM consumes one task. Easy to anticipate.

Make counts one operation per module executed. The same flow, if it passes through a filter, a search, a formatting step and then a creation, consumes four operations. So the counter rises with the complexity of the scenario, not only with the number of triggers.

That gives a counter-intuitive rule. On simple, numerous flows, Zapier is often clearer on cost. On complex flows, Make costs more operations per execution, but lets you do in a single scenario what would need several chained Zaps, and the total generally tips in its favour. On flows processing lists, Make wins by a wide margin: an iterator handling a hundred rows is still one scenario, where the Zapier equivalent quickly becomes expensive or impossible.

The only honest way to decide: take your three real flows, draw them, count. That is twenty minutes of work and it avoids an unpleasant surprise the following quarter.

The practical consequence is counter-intuitive: the most expensive scenario is not the most complex one, it is the one processing the most rows. A three-step chain triggered 1,000 times a day will always weigh more than a twenty-step scenario triggered ten times. It is the first thing to check before estimating an automation budget, and it is almost always the last thing people look at.

Most automations start simple and grow complex. When a quote is signed, create the project. Then: unless the client already exists. Then: and if the amount exceeds ten thousand euros, notify the manager. Then: and create one task per line of the quote.

By the third condition, a Zap becomes hard to read and to maintain. On Make, those rules are routers and filters laid out visually on the diagram. You see the flow, you see the branches, you understand what happened when it breaks.

That readability is not an aesthetic comfort. It is what determines whether your teams can maintain the flow without calling us back.

The threshold is easy to spot. As long as the flow reads like a sentence, “when this happens, do that, then that”, both suit and the simpler one wins. As soon as you have to write “unless”, “for each of the items” or “while waiting for”, the visual representation stops being a comfort and becomes a necessity.

It is not a question of raw power: both can handle complex cases. It is a question of re-reading. A flow that can no longer be read is a flow that will not be corrected, and an automation nobody corrects ends up being worked around by hand.

An automation in production with no alert is not finished. That is true on both sides, with a different level of precision.

Zapier reports failures, allows replays and keeps a history. Enough for simple flows. Make lets you define error routes per module, with retry, holding or targeted notification. You decide the behaviour for each breaking point.

In both cases the rule we apply is identical: every flow in production has an alert on failure, and a named owner who receives it. Without that, a broken automation stays invisible until a client complains about it.

The point to settle before building is not technical, it is operational: who is warned when an automation fails, and how quickly? A silent automation that falls over on a Friday evening produces incomplete data all weekend, and nobody finds out before the client points it out.

Our requirement on this kind of project: any automation touching a client or an invoice must raise an alert visible to a human, not just a line in a log nobody opens.

We do not publish figures here: the price lists change too often to stay accurate, and a wrong price in a comparison discredits the rest of the page. The mechanics, on the other hand, are stable and enough to decide on.

Both bill on the volume processed, in tiers. So the cost follows the number of triggers and the number of steps executed, not the number of scenarios created. An automation that is rarely triggered costs almost nothing, however sophisticated it is.

On top of that subscription come two lines nobody budgets for. The design time first, which is one-off. The monitoring time next, which is recurring: somebody has to check that the flows are running, deal with failures and adapt the scenarios when a connected tool changes its interface.

That second line is what decides the real return. An automation that saves two hours a month and requires one hour of maintenance is not a gain, it is a shift of workload.

It is the most frequent risk on these projects, and it never appears in feature comparisons.

An automation is software written by somebody. If that person leaves, what remains is a sequence of steps with no comment, whose intent has to be guessed. On a visual scenario, that re-reading is tedious but possible. On a linear chain of thirty steps, it often amounts to rebuilding.

Our rule on this kind of deliverable: every scenario carries an explicit name, a description of what it does and what happens if it fails, and the list of tools it touches. That takes ten minutes at build time and makes the difference between an automation that survives a departure and one that dies with it.

So the question to ask before choosing the tool is this: in a year, who will open this scenario, and will they understand what they are looking at?

A very small company starting out, with a few simple automations between common tools and nobody technical in-house: Zapier. Getting going is more direct, the vocabulary more accessible, and at that volume billing per task remains advantageous.

A mid-sized company scaling up, with flows that process lists, conditions and several hundred triggers a day: Make. Billing per operation becomes more favourable as soon as volume climbs, and the visual representation stays readable where the linear chain becomes unreadable.

A team bringing things in-house, with somebody able to maintain the scenarios and the intention of covering complete business processes: Make as well, for readability and handover. It is also the moment when the question of a self-hosted tool arises seriously, for reasons of cost at volume and control of the data.

If you hesitate at low volume, start with the simpler one. Migrating three scenarios is an afternoon; migrating thirty is a project.