Make vs Zapier vs n8n: choose by billing unit

Zapier bills per task, Make in credits (formerly operations) and n8n Cloud per workflow execution. Zapier and Make both scale with steps multiplied by records, while n8n Cloud scales with the number of times a workflow starts, however many steps it contains. Each vendor states this in its own documentation, and each has exceptions for particular step types (on Make, a credit is one module run for a non-AI app, while other modules can cost differently), so confirm the current rules for your plan.

Here is the arithmetic with example inputs, which are hypothetical and chosen only to show the method. Take a workflow you define as 10 billable steps over 100 records, run daily. That is a ceiling of 10 x 100 = 1,000 units a run on a per-step platform, or 1,000 x 30 = 30,000 over a 30-day month. On n8n Cloud the same month is 30 executions if the records travel together as items, or 100 x 30 = 3,000 if each record starts its own run. These are ceilings, not quotes. Vendors differ on which step types they count, change their plan limits, and Make now bills in credits rather than operations, so check the current pricing page and Make's Credits page for the modules you use, and confirm your own plan's unit, before you forecast.

That structure is why a workflow that is trivial at ten records a day can become the largest line on the subscription at ten thousand. It is also where Blueprint Runner started: Make's per-operation meter at the time was fine until a scenario iterated (Make now bills in credits, and the multiplication still applies), after which the bill tracked the number of rows rather than the value of the work.

Before switching platform, look for the three structural causes of an inflated count. A polling trigger that runs more often than the data changes: every 5 minutes is 288 checks a day, so data that changes twice a day means 286 checks that find nothing. Whether those empty checks are billed depends on the platform. Make's documentation counts a check for new data as a credit, while Zapier's states that polls never use tasks, and for n8n you should check how your particular trigger behaves. Per-row work that could be one batched call. And an iterator over a whole table where a filtered query would return a handful of rows. Fixing these changes the unit count without changing what the automation does.

In our experience Make is the most direct fit for lists, branching and aggregation without code, Zapier suits straight-line flows, and n8n is closest to code. The difference is how each treats a trigger that produces many items rather than one.

Zapier

A Zap is built around one trigger event walking down a straight line of steps. Paths add conditional branches and Looping by Zapier repeats actions for each item in a list, but both are layered onto that model. That is a strength when a non-technical person has to build and maintain a simple flow alone. It is a constraint when you need to iterate over a collection, aggregate results or route on several conditions at once.

Make

In Make a module emits bundles and the next module runs once per bundle. Once that clicks, the pieces compose: an iterator splits a list, modules do work per item, a router sends items down different branches, and an aggregator collapses them back into one bundle so you can write a single summary record. Error handlers attach per module, and the expression language does date arithmetic, string handling, array mapping and conditionals inline. When we built Blueprint Runner to execute Make blueprints outside Make, the flow control (routers, iterators, if/else with merge, merge filters) and the expression language were what made a blueprint portable rather than merely readable.

n8n

n8n nodes pass arrays of items, and where the visual nodes run out a Code node takes JavaScript or Python against the data directly. That escape hatch means you are less likely to hit a wall. It also means a workflow can quietly become a codebase with no tests, no review and no version history.

By each vendor's own published counts Zapier has the largest catalogue of the three, so for a niche SaaS app it is the most likely to have a native integration. But catalogue size matters less than whether the specific operation you need is exposed.

Make's catalogue is smaller, but many of its apps include a generic Make an API call module that reuses the connection you already hold, so an endpoint without its own module may still be reachable. n8n also has fewer native nodes by the vendors' counts, and its HTTP Request node can authenticate with the credentials you have already stored for an app, which covers many gaps. Check how much of the API each module exposes for the app you care about.

Test before you commit. List the exact operations the project needs (create, update, search, delete, and a trigger) and tick each one against the app's modules. An integration that can create a record but not update one cannot run a two-way sync. Also check whether the trigger is instant or polling. On the FormCraft build, a database webhook fires on every new entry so Make receives it immediately, with polling kept only as the fallback. Instant triggers are faster, and on Make they also avoid the credits (formerly operations) that empty polling checks use.

Version history, credential handling, failure alerts and ownership decide whether an automation survives its second year, and none of the three platforms solves them for you.

• Version control. All three keep some version history (Zapier's version rollback, Make's scenario history, n8n's workflow history), with retention and availability depending on plan. None replaces Git. n8n's own documentation says its Git-based source control is not full version control, and that feature is limited to its higher plans. Make exports a scenario as a blueprint JSON file and n8n exports workflows as JSON, which you can commit yourself, and should. Zapier offers JSON import and export of Zaps on its Team and Enterprise plans. A committed export is the closest thing to a safety net you control.
• Secrets. A credential pasted into an HTTP module's headers travels with every export and screenshot. Make's connections and n8n's credential store keep it out of the workflow body. Audit existing scenarios for tokens pasted in a hurry.
• Failure visibility. A run that fails is manageable. A run that stops quietly and is found a week later by a customer is the real risk. On Make, for example, a scenario can be switched off after a set number of consecutive errors (a scenario setting; instant-trigger scenarios can be deactivated sooner), so a failure can look like silence. Error handlers and an alert into somewhere a person looks are part of the build, not a later phase.
• Ownership. Automations built by someone who has left, with no notes and credentials nobody can rotate, are a common and expensive inheritance. Write down what each scenario touches and who owns it.

Choose by the constraint that bites. Zapier when a non-technical owner must maintain simple flows or the app only has a Zapier integration. Make when the work is branching, iteration or reshaping data. n8n when you need code in the flow, self-hosting, or execution that is not billed per step.

Running two platforms is not indecision. Simple, low-risk flows on Zapier and complex orchestration on Make is a sensible split. What to avoid is the same process implemented on both, because that is how two systems of record appear and start disagreeing.

There is a fourth option that comparisons rarely mention: take the logic off the platform. A Make blueprint is a JSON document, so a scenario can be executed elsewhere. Blueprint Runner is our implementation. It reads blueprint JSON directly, covers routers, iterators, aggregators and the expression language, has no per-credit or per-operation meter, and has a dry-run mode that shows every resolved request before anything is called. It skips app modules it does not implement, so check coverage against your own scenario first. It makes sense only when volume is high enough for the meter to matter and someone is prepared to run it.