Zapier is getting expensive: when to self-host, and when to build

It started at twenty a month and nobody noticed. Now it is several hundred, somebody has asked what it is for, and the honest answer is that eleven automations run and three people could explain four of them.

Zapier getting expensive is usually a design problem rather than a pricing problem, and most businesses can cut the bill substantially without moving anywhere. Whether to self-host or build is a second question, and it is worth answering only after the first.

Why Zapier gets expensive the way it does

These tools charge by how much runs, not by how much value it produces, which is why the cost rises fastest exactly when the business is doing well.

• Every step counts, not every automation. A flow with six steps costs six times a flow with one, and people design flows the way they think rather than the way they are billed.
• Polling burns runs on nothing. An automation that checks every fifteen minutes whether something changed uses the same budget on a quiet Sunday as a busy Monday. Most of those checks find nothing.
• Filters run after the trigger. A flow triggered by every new email and then filtered down to the three that matter has already paid for all of them.
• Failures and retries cost too, and a broken automation retrying quietly can consume a surprising amount before anyone notices.
• Tiers jump rather than slope. You are fine, then you cross a threshold and the price steps, which is why the increase feels sudden.

Cut it without moving

Do these first. They cost an afternoon and frequently remove the reason you were considering a project.

1. Filter at the trigger, not after it. Where the source app can send only the records you care about, the flow stops paying for the ones you discard.
2. Replace polling with a push wherever the source supports it. This alone can remove most of the volume, because you stop paying to ask whether anything happened.
3. Collapse steps. Three steps formatting a value can frequently be one. Look at the flows with the most steps first, since they cost the most per run.
4. Delete what nobody uses. Every audit we have run finds automations built for a campaign that ended, a person who left, or a process that changed.
5. Batch what does not need to be immediate. A daily summary costs one run and often serves better than thirty individual notifications.
6. Then look at the annual plan, which is a discount for a decision rather than for engineering.

When self-hosting genuinely pays

Self-hosted automation tools are capable and the appeal is obvious: predictable cost regardless of volume, your data staying on your infrastructure, and no per-run arithmetic.

The cost does not disappear, it changes shape. You now pay for a server, for updates, for the connections that break when a vendor changes something, and above all for somebody who understands it. That last one is the real number and it is the one omitted from every comparison.

The middle option nobody proposes

The choice is usually presented as three doors: stay, self-host, or build. There is a fourth that suits more businesses than any of them, and nobody sells it because it is the smallest sale.

Keep the hosted tool for the long tail of small, low-volume, genuinely simple automations where it is excellent and cheap. Move only the two or three flows that account for most of the runs, or most of the risk, into something built properly. You end up paying a small subscription plus a modest one-off, instead of either a large subscription or a large project.

• Find the flows generating the volume. In every account we have looked at, a small number of automations account for most of the runs, and it is rarely the ones people assume.
• Move those, and leave the rest. The forty flows sending a notification twice a month cost almost nothing and are perfectly well served where they are.
• You keep the flexibility for everything new, which is the real value of these tools: trying something on a Tuesday without a project.
• And you remove the fragility from the handful of things that genuinely matter.

The reason this is worth insisting on is that both alternatives are all-or-nothing by default. A supplier proposing a full migration and a vendor proposing a higher tier are each solving the whole problem when only part of it needs solving.

When the tool has become a liability

Separate from cost, and more important. Some automations should be built properly regardless of what the subscription costs.

• One person understands it. A tangle of flows with names like Copy of Zap 4 that only one person can follow is a business risk wearing a low monthly fee.
• Something important depends on it silently. If invoices, compliance dates or customer communications run through automations nobody monitors, the cost of a silent failure exceeds any saving.
• The logic has outgrown the interface. Once you are chaining conditions and building workarounds for things the tool cannot express, you are writing software in a tool that was not designed for it, and doing so more slowly and less reliably than writing it.
• It handles data that should not be passing through a third party. Worth checking rather than assuming, particularly for anything personal or financial.

In those cases the question is not what it costs but what happens when it fails at four in the morning. A built automation with proper alerting, retries and a record of what happened is a different class of thing, and that is what workflow automation work usually means once volume is real. Where the job is genuinely moving data between systems on a schedule, data pipelines is the cheaper and sturdier shape.

What good looks like at any size

Whichever route you end up on, a handful of habits separate an automation estate that stays cheap and trustworthy from one that becomes a monthly argument.

1. Name things properly. Copy of Zap 4 is how an estate becomes unmaintainable. A name should say what triggers it and what it does, so somebody who has never seen it can decide whether to switch it off.
2. Write down what each one is for, in one line, somewhere findable. Not documentation, a list. The absence of this is why nobody dares delete anything.
3. Give every automation an owner, by name. Unowned automations are never reviewed, never deleted and never fixed until they break something visible.
4. Send failures somewhere a person looks. Not the account owner's ignored inbox. The silent failure is the expensive one, and it is silent by default.
5. Review the list quarterly, which takes twenty minutes and is where the savings actually come from. Businesses that do this rarely have a cost problem in the first place.
6. Do not automate a process you have not tidied. Fix the process before automating it covers why, and it is the cheapest advice on this page.

None of that requires a decision about tools, and most of it would have prevented the situation that brought you here. It is also the part that makes any future migration straightforward, because you will know what you actually have.

Not for you if

One exercise before deciding anything: list every automation you run and write next to each what breaks if it stops. The ones with a serious answer should be built properly whatever they cost. The ones with no answer should be switched off, and that alone frequently settles the bill.