Zapier kept for what it is genuinely best at, and moved off where it is not
Zap design, cost audits and migrations on Zapier, including the honest assessment of which automations should stay and which have outgrown a linear model.
Zapier's real advantage is not its feature list. It is that a non-technical person can build a Zap, understand it six months later, and fix it without help, and that its connector catalogue is large enough that an obscure SaaS product usually has a native integration there and nowhere else. For a simple, linear automation owned by the person who needs it, that combination is worth more than any amount of capability they will never use.
The constraint is the same model. A Zap assumes one trigger produces one item that travels in a straight line. Paths add branching and Looping exists, but both feel bolted onto that assumption, and billing is per task (per step, per record), so cost scales with steps multiplied by volume. When a process needs to iterate a collection, aggregate results back, or route on several conditions at once, Zapier can usually be made to do it, and the result is expensive and hard to follow.
What we build on Zapier
Zaps that stay legible to the person who owns them
One Zap does one job, named so the list tells you what it is for. Filters go as early as possible, since a Zap stopped at step two does not consume the tasks for the steps that never ran, which means step order is a cost decision as well as a logic one. Formatter handles the dates and text so nobody has to maintain a code step they cannot read.
Paths, while the branching is still shallow
A handful of mutually exclusive conditions is what Paths are for and they are perfectly good at it. Once the branching becomes a matrix, or once two branches need to rejoin and produce one result, the automation is telling you it belongs on a platform with a router and an aggregator, and we say so rather than nesting Zaps.
Zapier as the connector, not the logic
Where an app integrates with Zapier and nothing else, the sensible pattern is to let Zapier do exactly the part only it can do: catch the trigger, and hand the payload straight to a webhook. The work then happens where the logic, the error handling and the run history live, and the task count stays at one or two per record instead of ten.
What goes wrong on Zapier
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
Task cost multiplying quietly
Tasks count per action step per record, so adding two steps to a Zap that runs ten thousand times a month is a twenty-thousand-task decision made in a minute. The bill rises with no change in what the automation does. The audit looks for steps that could be filtered out earlier, lookups that repeat work already done, and Zaps triggering on every update when they only care about one field.
- 02
Polling delay mistaken for a broken Zap
Polling triggers check on an interval set by the plan, so a Zap can be working perfectly and still look dead for several minutes. Teams respond by rebuilding something that was never broken. Where the source app offers an instant trigger or a webhook we switch to it; where it does not, the honest answer is to tell people the latency rather than let them keep discovering it.
- 03
A Zap that turned itself off, emailing someone who left
After repeated errors Zapier pauses a Zap and notifies its owner, and Zaps are frequently owned by a personal account rather than the team, so the notice goes to a mailbox nobody reads. We move ownership into the shared account, route error notifications into a channel a team watches, and check the held-task list, which is usually where the missing records turn out to have been sitting.
- 04
No export, so a migration is a rebuild
Zaps cannot be lifted out as portable logic the way a Make blueprint or an n8n workflow can. That does not make moving impossible, but it makes it a rebuild, so it is planned as one: document what each Zap does and touches, rebuild the highest-value ones first, run both in parallel against real data, and switch over only when the outputs match.
Where Zapier is the wrong answer
Zapier is the wrong answer the moment the work involves iterating over a collection, aggregating results back into one, or routing on several conditions at once. Make's bundle model handles all three natively and the equivalent Zap will be both costlier and harder to follow. It is also the wrong answer at high volume with many steps, where per-task billing dominates every other consideration and self-hosted execution on n8n, or a small service, will cost a fraction of it. What we would not recommend is moving everything: simple, low-risk, low-volume automations owned by non-technical staff are exactly what Zapier is best at, and migrating those off it usually costs more in lost self-sufficiency than it saves.
Projects that did not use Zapier
Here for the argument rather than as evidence of Zapier work. Each one bears on a decision above, and the note says which.
- FormCraftFormCraft: a form platform with an API automation can callNot a Zapier build. It is a form platform given a token-secured REST API and an outbound webhook precisely so that any automation platform can read from it and react to it, instead of being driven awkwardly through a vendor's own integration.Case study
- FlowForgeFlowForge: a workflow builder with cron, webhooks and run historyNot a Zapier build. It is what we reach for when a schedule, a webhook trigger and a readable run history are the whole requirement and per-task billing is not worth paying for them.Case study
The disciplines behind it
Related reading
Zapier, specifically
Usually volume, or a step somebody added. Tasks are counted per action step per record, so either more records arriving or one more step in a busy Zap raises the bill without any visible change in behaviour. The other common cause is a Zap triggering on every record update rather than on the change it cares about, which does most of its work for nothing.
Only where the shape of the work has outgrown it. Automations that branch, iterate or aggregate belong on Make; high-volume step-heavy ones belong somewhere unmetered. Simple linear Zaps that a non-technical owner maintains should usually stay exactly where they are, and running both platforms is a sensible split rather than a failure to decide.
Yes, with the caveat that it is a rebuild rather than an import, as Zaps have no portable export. We audit first: what each Zap does, what it touches, where its credentials are, and what it costs. The valuable ones get rebuilt, run in parallel against live data until the outputs match, and switched over one at a time.
By making failure arrive somewhere a person looks. Zap ownership moves into a shared account so error notices do not go to an individual's inbox, failures route into a team channel with the Zap named, and the held-task list is checked as part of a routine rather than after a customer complains. Silent failure is the actual risk in automation, and it is an engineering problem rather than a platform one.
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