Choosing between Make, Zapier and self-hosting

What each platform is actually good at

Wobble builds on all three of Zapier, Make and n8n. Saying so matters mainly because it changes what a recommendation is worth. A shop that only builds on one platform has already made your decision for you, and the conversation you get is about how to fit your process into it.

The three are not competing on a single axis. They differ on who can maintain them afterwards, on how they behave once the logic stops being a straight line, and on what happens to the bill and to your data as volume grows.

• Zapier: the widest catalogue of ready-made connections, and the shortest path from an idea to something running
• Make: a visual canvas built for branching, looping and handling collections of records rather than one record at a time
• n8n: the only one of the three that can be self-hosted, with code available where the visual approach runs out

Where Zapier is the right call

Zapier wins on breadth and on time to first working thing. If both applications you want connected are mainstream, the connection almost certainly exists already and somebody else maintains it. That is not a small point. Most automation maintenance is connector maintenance, and a connector a vendor keeps working is one your team never has to fix.

It also wins on who can maintain it. An operations manager with no engineering background can open a Zap, understand what it does and change a field without asking anyone. That matters more than any feature comparison, because the automation that survives is the one somebody inside the business can still change in two years.

Where it starts to hurt is complexity. Branching is possible and it is awkward. Once a workflow has several paths, a loop and its own error handling, a Zap becomes hard to read, and hard to read is where automation quietly goes to die.

• Straightforward triggers with a handful of steps, where the logic runs in a line
• Teams already running Zapier who have somebody comfortable in it
• Applications with a well-maintained Zapier connector and a poor one elsewhere
• Low volume, where per-task pricing costs less than the time spent optimising it

Where Make is the right call

Make is built for the shape of workflow that Zapier makes uncomfortable. The whole flow sits on one canvas, splits into branches, iterates over a list of line items, aggregates the results back together, and carries error handlers attached to individual steps rather than to the scenario as a whole.

Its pricing shape behaves differently at volume too. Make counts operations, so a workflow processing many records inside one run is priced quite differently from a system charging per task step. For anything handling collections, that difference compounds fast enough to decide the platform on its own.

The cost is a steeper first week. Make asks whoever builds it to think about data structures, and a team with nobody willing to do that will produce something they cannot maintain later.

• Workflows with genuine branching, where the path depends on the data
• Anything processing a list: line items on an order, rows in a file, records in a batch
• Cases where somebody needs to see and explain the whole flow in one picture
• Volume high enough that per-step pricing becomes uncomfortable

Where all three lose

The honest part of the comparison. Some requirements sit outside what a hosted automation platform does well, and arguing about Zapier against Make is the wrong argument to be having.

There is also a cost pattern worth naming early. Platform pricing counts steps or operations, so one business event that fans out into a dozen actions is a dozen units. That is comfortable at a hundred events a month and a different conversation at fifty thousand, and it is the most common reason a perfectly good automation gets rebuilt somewhere else a year later.

• Data residency. Zapier and Make are hosted services and your data passes through them, which is why regulated data and strict internal policies usually end up self-hosted on n8n
• Credentials that cannot be handed to a third-party platform, for the same reason
• Heavy data processing. Moving large files or transforming many thousands of records is faster and cheaper as code
• Anything needing a reply in a fraction of a second, which is an application concern rather than a workflow one
• Complex AI orchestration, where an agent calls several tools, keeps state across turns and needs its behaviour inspected step by step
• Review and rollback discipline. None of the three gives you what a codebase gives you, and complicated logic eventually wants it

A decision rule you can run in ten minutes

Five questions settle most of these choices, in this order, because the earlier answers overrule the later ones.

• Where must the data live? If the answer is on infrastructure we control, the choice is self-hosted and the other two are out before you compare features
• Who maintains it after handover? If that is a non-technical person already fluent in one platform, weight that heavily
• How many paths does the logic have? A straight line suits Zapier, several branches and a loop suit Make
• How many runs a month, and how many steps per run? Multiply the two before comparing prices, because the second number is the one that surprises people
• Does AI do more than one thing? A single classification step is comfortable anywhere, and an agent with tools and memory usually is not

When you should not hire anyone for this

If you need two applications connected in a straight line and somebody in the business is willing to learn, build it yourself. The platforms are designed for exactly that, the documentation is good, and paying an agency to click through a five-step setup is a poor use of a budget. Come back when the workflows start depending on each other.

If nobody internally will own the result, the workflows decay quietly. Applications change their fields, credentials expire, a connector updates its behaviour, and a system with no owner degrades until somebody notices the numbers stopped making sense.

And if the volume is a task somebody does twice a week in a few minutes, the maintenance cost of any platform outruns the saving. Automate it when it becomes daily, or when getting it wrong once costs more than building it properly.

The sixth question, and who keeps the workflows

A ten minute decision rule is the right shape, and it leaves out one thing: what the workflow does at three in the morning when a step breaks. Each of these platforms will retry, and none of them will tell anybody it is doing so. The habit worth adopting alongside the five questions is that a failure halts rather than loops, with the state at the moment it broke handed to a person, and that spending, pricing, anything published in your name and any serious complaint stop for human approval. It is the only part of this comparison that can be settled before the platform is chosen.

The first question in the rule is about credentials, and it is the ownership question in different clothes. Self-hosted n8n puts the instance, the credentials and the execution history on infrastructure you control, with workflow definitions you can read and version. On the hosted platforms you own the account and the logic inside somebody's product. Either way the account belongs registered in your company's name from the first day, so you own the system and the connections do not end up sitting under somebody's personal login.

The section above is right that some of this should not be bought at all, and it is worth repeating in the plainest form. Two applications connected in a straight line, with somebody in-house willing to learn, is a job for your own team, and the platforms were built for exactly that. What is worth paying for starts where the logic branches, where volume makes the pricing model matter, or where nobody internally will still own it next year.

Ibrahim owns build and workflows at Wobble and is usually the person a client's own team is trained by, on the principle that they should be able to change a workflow without ringing anybody. Moiz Khan owns automation architecture and decides which platform a build belongs on. Wobble works from Karachi, bills month to month and is answerable for what it operates across 25 engagements in six countries, which is the arrangement where a platform choice that turns out to be wrong shows up in the next invoice rather than at a renewal.

Common questions

Is Make better than Zapier?

For workflows with real branching, loops or lists of records, usually yes, and its operations-based pricing behaves better at volume. For a straight-line connection between two mainstream applications, Zapier is faster to build and easier for a non-technical person to maintain. The more useful question is which one the person inheriting it can still change.

When should we self-host instead of using Zapier or Make?

When the data or the credentials cannot pass through a third-party service, when volume makes per-step pricing uncomfortable, or when the work involves AI orchestration with several tools and state carried between turns. n8n can be self-hosted and Zapier and Make cannot, and that single difference settles a large share of these conversations.

How much do Zapier and Make cost to run?

Both price by units of work rather than by workflow, so the figure that matters is runs per month multiplied by steps per run rather than the headline plan. Work that number out before choosing, because one business event that fans out into a dozen actions counts as a dozen units, which is why bills grow faster than usage feels like it did.

Can we move from one automation platform to another later?

Yes, and it is usually a rebuild rather than a transfer, because the logic is expressed in platform-specific steps. What makes it cheap is having the business rules written down separately in plain language, together with a list of triggers, credentials and the systems each workflow touches. Without that, a migration starts with archaeology.

Do we need an agency for Zapier or Make at all?

Not for a couple of straight-line connections. The platforms are built for that and somebody internal can learn it in an afternoon. It becomes worth paying for when workflows start depending on each other, when failures need catching rather than discovering, and when the thing being automated touches money or customer messaging.

How do the platforms differ in handling errors?

Zapier keeps a task history and can replay a failed step, which suits flows that run in a line. Make attaches error handlers to individual modules and holds failed runs in a queue you can resume once the cause is fixed. n8n can trigger a separate workflow when another one fails, so alerting and recovery are themselves automated. All three ship with the option and plenty of builds never switch it on, so ask which was actually configured rather than which is available.