Make.com scenarios that batch their work instead of billing per row
Scenario architecture, rebuilds and cost repair on Make.com, with routers and aggregators arranged so work happens once per bundle, error handlers on the modules that can fail, and credentials out of the blueprint JSON.
Make is the most capable of the mainstream workflow platforms for anything involving real branching, iteration or data transformation, and the reason is its execution model. A module emits bundles; the next module runs once per bundle. Once that idea lands, routers, iterators and aggregators compose properly: split a collection, do the work per item, aggregate back to a single bundle, write one record instead of two hundred.
The expression language is the other half of it. Date arithmetic, string surgery, array mapping and conditionals happen inline, with backticked module references and one-based indexing, so a scenario that would need a code step elsewhere stays declarative here. And where a module does not expose the endpoint you need, the generic API-call module reaches it through a connection you already hold, so there is no second credential to manage.
Where it stops is governance. There is no version control a developer would recognise, error handling is opt-in per module, and Make bills in credits (formerly operations): one credit per module run, per bundle, for a non-AI module. A loop nobody noticed therefore becomes a bill nobody predicted. None of that is a reason to avoid Make. It is a reason to build on it deliberately.
What we build on Make.com
Scenarios with routes that state the actual rule
Routers with filters that express the business condition rather than approximating it. Make's condition matrix is OR across groups of ANDs, which covers most real rules without nesting three scenarios inside each other. A fallback route catches everything that matched nothing, because the bundles that fit no branch are the ones that go missing.
Iterators and aggregators, in that order
Split a collection with an iterator, do the per-item work, then bring it back with an array or text aggregator so the write happens once. This is the single largest difference between a scenario that costs what it should and one that does not, and it is usually a restructure rather than a rewrite.
Error handlers on the modules that can fail
Break with a retry interval on anything talking to a flaky API, Resume with a sensible default where a missing record is not an emergency, Ignore only where it genuinely is not, and Commit or Rollback where a partial write would leave the data wrong. The incomplete executions queue is then a work list rather than a surprise.
The generic API call, instead of waiting for a module
Most major apps ship a make-an-API-call module that authenticates with the connection you have already made. An endpoint with no dedicated module is therefore usually reachable today, with the token still living in the connection rather than in a header you typed.
Blueprints treated as build artefacts
Export the blueprint JSON, extract hardcoded bearer tokens into variables and connections, and commit it. That turns a scenario into something reviewable, diffable and restorable, and it is also what makes leaving possible later, because the logic is portable even though the platform offers no migration path.
What goes wrong on Make.com
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
Credits (formerly operations) billed per row where one call would do
The usual pattern is a search module returning a whole table, an iterator over every row, and a write per row, so a scenario that should cost a handful of credits costs thousands. The fixes are unglamorous and immediate: filter in the search rather than after it, set a result limit, aggregate before writing, and use the batch endpoint where the API has one. The scenario does the same thing afterwards; the meter does not.
- 02
Polling triggers running far faster than the data changes
A fifteen-minute poll against a table that changes twice a day burns credits to learn nothing. Where the source can push, we move to an instant webhook trigger; where it cannot, the schedule is matched to the real rate of change and the trigger is filtered so empty polls cost one credit rather than five.
- 03
Bearer tokens pasted into HTTP module headers
A token typed into a header travels with every blueprint export, every screenshot and every shared scenario, and it cannot be rotated without editing each module that holds it. We move them into variables and connections, then scan the blueprint for the ones that were pasted in a hurry before anyone commits it anywhere.
- 04
A scenario that stops and tells nobody
Make deactivates a scenario after repeated failures, and if the notification goes to one person's inbox (often someone who has left), the discovery comes from a customer a week later. Error handlers route failures somewhere a human actually looks, the incomplete executions queue gets checked rather than accumulated, and the alert names the scenario and the bundle rather than saying an error occurred.
Where Make.com is the wrong answer
Make is the wrong answer in two situations. If a non-technical owner has to build and maintain the automation unaided and the logic is genuinely linear, Zapier's simpler model and larger connector catalogue will serve them better, and pushing them onto a canvas they find intimidating produces an automation nobody touches. And if the work is high-volume, step-heavy and per-row by nature, credit-based billing (credits were formerly called operations) will eventually dominate every other consideration, at which point the answer is to move the execution rather than to keep restructuring the scenario. Because the blueprint format is documented JSON, that move can keep the logic intact: we have built a runner that executes Make blueprints natively, and n8n is the other sensible destination. Neither is a reason to start somewhere else.
Built on Make.com
The disciplines behind it
Related reading
Make.com, specifically
Count module runs, not modules: a scenario with ten modules processing a hundred bundles is a thousand module runs, not ten, and for non-AI modules that is a thousand credits (one credit per module run since 27 August 2025; other modules can cost differently, so check Make's Credits page for the modules you use). Make's run history still calls each module run an operation. That multiplication is why structure matters more than the price list: a scenario that filters early and aggregates before writing can cost a fraction of one doing the same job per row. We estimate it from the real trigger volume before building, and check it against the first week of run history.
Almost always because a retry or a re-delivered webhook runs the same bundle twice and the write is a plain create. The fix is find-or-create against a stable key, or an upsert where the target supports one, so running the same bundle twice leaves the same result. Webhook triggers in particular will re-deliver on timeout, which is correct behaviour on their side and a duplicate on yours.
Yes, and it is a common way to start. The first pass is an audit rather than a change: export every blueprint, list what each scenario touches, find the credentials that are hardcoded, and read the incomplete executions to see what has been failing quietly. That produces a list of what to fix now and what to leave alone, before anything is edited.
It depends on the shape of the work, not the feature list. Make is genuinely better where there is branching, iteration, aggregation or data reshaping. Its router and aggregator model has no real equivalent on Zapier. Zapier is better where the automation is linear, the app is obscure enough that only Zapier integrates with it, or a non-technical person must maintain it alone. Running both is common and sensible; running the same process on both is how two systems of record start disagreeing.
The logic is portable if you have kept the blueprints. Make exports a scenario as JSON including routers, iterators, aggregators and every expression, which means it can be version-controlled and in principle executed elsewhere; we built a runner that does exactly that. What does not come with you are the connections, so credentials have to be re-established wherever the scenario lands.
Where this is applied
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no