Zapier, or a real integration?

Most of the integration work we get called about starts the same way. Someone set up a Zap two years ago, it worked, so they set up another one. Now there are fourteen, nobody remembers what half of them do, one of them has been silently failing since March, and the monthly bill has quietly become a real line item.

None of that means Zapier was the wrong call. It usually was the right call at the time. The question is whether it still is.

The short version

Where you are	What to do
A handful of simple handoffs, low volume, nothing mission critical	Stay on Zapier. Don’t call anyone.
Growing volume, a few workflows that matter, occasional breakage	Stay, but get it organized and monitored
High volume, real money moving, or logic Zapier can’t express	Time for a real integration

Most small businesses are in the first row and should stay there. We’d rather tell you that than sell you something.

When Zapier is genuinely the right answer

It’s not a beginner tool you graduate from. For a lot of jobs it’s the correct engineering choice, and it stays correct:

• The workflow is a straight line: this happens, then do that.
• Volume is low. Under a few thousand tasks a month, the economics are firmly on Zapier’s side.
• A few minutes of delay doesn’t matter.
• If it fails, someone notices, and the cost of it failing is an annoyance rather than a bad invoice.
• The connector already exists for both ends.

Building custom for that is a waste of your money. You’d be paying real build cost to replace something that works, plus taking on the maintenance yourself.

The four ways it stops working

Nobody makes a decision to outgrow it. It happens quietly, in one of four ways.

The bill. Zapier prices per task, so cost scales with your success. The gap opens up somewhere north of five thousand tasks a month, and by around twenty thousand you’re looking at roughly $200 a month for plumbing. That’s not outrageous on its own, but it’s a permanent bill that grows, and it buys you nothing you own.

The delay. Scheduled syncs typically land in the five to fifteen minute range. Fine for adding someone to a mailing list. Not fine when a dispatcher is looking at a screen that doesn’t yet show the job that came in four minutes ago.

The overwrite. This one does the real damage. Most simple automations push in one direction and assume they’re the only thing touching the record. When two workflows both update a customer, or someone edits by hand between syncs, the later write wins and quietly destroys the earlier one. You often find out weeks later, from a customer.

Ownership. You don’t own the logic. When a sync fails you get the vendor’s error log and the vendor’s support queue. If a connector gets deprecated or the pricing changes, your workflow is somebody else’s business decision.

The numbers that say you’ve crossed over

As of August 2026, roughly:

• Under 5,000 tasks a month: stay. The math isn’t close.
• 5,000 to 50,000: the grey zone. Worth pricing the alternative, and worth cleaning up what you have either way.
• Over 50,000: you’re paying a lot for something you don’t control.
• Break-even on a custom build typically lands somewhere between eight and twelve months, if cost were the only factor.

Treat those as a prompt to look, not a rule. We’ve seen businesses at three thousand tasks a month that genuinely needed a real integration because of the overwrite problem, and businesses well past fifty thousand who were fine because every workflow was a simple one-way push nobody depended on in real time.

The honest test isn’t the task count. It’s this: if this stopped working on a Friday afternoon, would you find out before your customers did, and would it matter? If both answers are yes, the volume number is beside the point.

What “a real integration” actually means

It’s less exciting than it sounds. It’s a small piece of software that sits between two systems and does what the no-code tool couldn’t:

• Talks to both systems’ APIs directly, so it isn’t limited to the fields a connector chose to expose.
• Knows which system is authoritative for which field, so nothing gets overwritten by accident.
• Runs when something happens rather than on a timer.
• Keeps a record of what it did, so when something looks wrong you can find out what happened instead of guessing.
• Tells someone when it fails, rather than failing quietly.

That last one matters more than people expect. The difference between an integration you trust and one you don’t is usually not sophistication. It’s whether it shouts when it breaks.

What we’d actually tell you to do

In order, and most people stop before the end:

1. Write down every automation you’re running and what it does. Half the time this alone solves the problem, because two of them turn out to conflict and one has been dead for months.
2. Check whether anything is failing silently. If nobody would notice for a week, that’s the thing to fix first, and it’s usually free to fix.
3. Look at the bill against the volume. If you’re under a few thousand tasks, stop here. You’re fine.
4. Work out which fields have more than one thing writing to them. That’s where the overwrite damage lives, and it’s the strongest argument for building something real.
5. Only then price a custom build, and price it against the next three years of subscription rather than next month’s.

Where we come in

We build the integration when it’s genuinely time, and we’ll say when it isn’t. Plenty of the calls we take end with us suggesting a tidy-up and some monitoring on the setup you already have, which is a smaller job and sometimes no job at all.

If we do build it, we’re looking at the whole picture: which system owns which data, what happens when one end is down, who gets told when something fails, and what it costs to keep running. That’s the systems integration work we’ve been doing for twenty years, long enough to have been called in to clean up after plenty of integrations, including our own.

If you’re not sure which side of the line you’re on, tell us how it works today and we’ll give you a straight answer.