A new order lands. Zapier copies it into a spreadsheet, creates a contact in the CRM, posts a message in the team chat and drafts an invoice. It took someone an afternoon to set up, it costs less than a lunch a month, and for a year it just works.
Then somebody asks why a customer was invoiced twice. Or why an order from Tuesday never reached the warehouse list. The person who built the Zap left in the spring, it runs on their login, and the run history that would explain what happened only goes back a couple of months.
None of that makes Zapier a bad tool. It is a very good one. The problem is what it quietly turns into: the place your business process actually lives, without anyone deciding that it should.
Symentic Technologies is a UK software company that builds custom operations systems and integrations for SMEs in the UK, Australia and New Zealand, and we run two live SaaS platforms of our own. This post is how we decide, with clients, when a no-code automation is the right answer and when a custom integration has earned its place. We often recommend keeping the Zap.
The short answer
Use Zapier (or a similar tool such as Make) when the automation is a convenience: moving a copy of data from one system to another, sending a notification, saving a file. If it fails, someone is mildly annoyed and fixes it by hand.
Consider a custom integration when the automation has become a core business process: it creates invoices, commits stock, takes payments, assigns jobs or decides what happens next. If it fails, money, customers or compliance are affected, and someone needs to know straight away.
The question is not "which tool is better". It is "how much of our operation now depends on this, and who would notice if it stopped?"
What Zapier is genuinely good at
It is worth being fair here, because a lot of "custom vs no-code" writing is a sales pitch for one side.
- Speed. A competent person can connect two mainstream apps in an hour. No developer, no deployment.
- Breadth. Thousands of apps already have connectors, built and maintained by someone else.
- Cheap experiments. If you are not sure a process is worth automating, a Zap is the cheapest way to find out.
- Low-stakes plumbing. Notifications, copies to a spreadsheet, saving attachments, adding someone to a mailing list.
If that describes your automations, keep them. Paying a developer to rebuild a working notification is not a good use of anyone's money.
Five signs your Zap has become your operations system
1. It writes records that money depends on
Creating invoices, issuing refunds, committing stock, booking jobs. Once a workflow writes those, a duplicate or a missed run is not an inconvenience. It is a billing error or an unhappy customer. We covered what it takes to make accounting syncs reliable in your ops system and Xero should agree. Most of those safeguards, such as idempotency keys and storing the other system's record ID, are hard to express in a chain of Zap steps.
2. The logic lives in filters and paths nobody can read
Business rules start small: "only if the order is over £500", "send to the Brisbane team if the postcode starts with 4". A year later there are nested paths, formatter steps and lookups across several Zaps. The rules that run your business are now spread across a visual editor, with no tests and no change history that a new person can follow.
3. Several Zaps depend on each other
One Zap writes to a sheet, another triggers on that sheet, a third updates the CRM, which triggers a fourth. Zapier's own help centre warns that if a Zap writes back to the same app and resource its trigger watches, it can retrigger itself in a loop that rapidly uses up tasks. Chains like this are where the hardest-to-find bugs live.
4. It runs on one person's account
Who owns the Zapier account, the connected app logins and the API keys inside them? If the answer is "a former employee" or "our old freelancer", you have the same problem we wrote about in every supplier looks the same until you try to leave, just in a smaller box.
5. Your team has started checking it
If someone opens the run history every week, or keeps a spreadsheet of records the automation got wrong, you already have a manual process. It just has an automation in the middle. That is the same pattern as the spreadsheet that became custom software.
What Zapier's own rules mean in practice
Zapier documents how its platform behaves clearly. A few of those rules matter once an automation becomes important. The figures below come from Zapier's help centre at the time of writing; check the current versions for your plan.
Polling means delay
Most triggers are polling triggers: Zapier checks the source app on a schedule rather than being told the moment something happens. Zapier lists the interval as 15 minutes on its Free plan, 2 minutes on Professional and 1 minute on Team and Enterprise. Some apps support instant, webhook-based triggers instead, but the trigger type is set by the app's API and you cannot change it. For "add this lead to a list" a few minutes is fine. For "reserve the last item in stock" it may not be.
Retries are generous, but slow to tell you
On plans that include it, Zapier's autoreplay retries a failed step up to five times, with gaps that grow from 5 minutes to 6 hours. Zapier says the final attempt happens roughly 10 and a half hours after the first error, and error notification emails are not sent until that final attempt fails. That is a sensible default for convenience automations. For an order that a customer is waiting on, it means you may find out the next morning.
History is short
Zapier says it can only guarantee up to 60 days of run data in your Zap history, and displays up to 10,000 runs, and its data retention page lists 29 to 69 days in your account. If you need to answer "what happened to this order in March?" in September, you need to export that history yourself or keep the record somewhere you control.
Cost scales with activity, not value
Zapier counts a task for every successful action step. Triggers, filters and some built-in tools do not count. A three-action Zap that runs 2,000 times a month uses 6,000 tasks. That is often still cheap. But it is worth working out, because busy processes grow faster than anyone expects, and loops can burn through an allowance quickly.
None of these are flaws. They are design choices for a general-purpose tool. They only become a problem when a general-purpose tool is running a specific, critical process.
What a custom integration gives you instead
A custom integration is code that connects your systems directly, usually a small service or part of your own operations system. Done properly, it gives you:
- One owner per record. A written decision about which system creates and edits each type of data, so you never get two versions of the truth.
- Safe retries. Idempotency keys and stored IDs, so a network failure never becomes a duplicate invoice.
- Failures your staff can see. A "not synced" list inside the system they already use, with a reason and a retry button, and an alert to a named person straight away.
- Rules in code, with tests. Business logic that can be read, reviewed and tested against real past orders before a change goes live.
- Your own logs, kept as long as you need. Retention set by your business, not by a vendor's plan.
- Ownership. The code, the credentials and the hosting registered to your business. That is our default on every project: the client owns the code.
It also has real costs. Someone has to build it, host it and maintain it when the other systems change their APIs. That is why we would not recommend it for every automation.
The middle path most businesses should take
It is rarely all or nothing. A pattern we often suggest:
- List every automation and what it writes. Many businesses are surprised how many they have.
- Mark the critical ones: anything that creates money records, commits stock, assigns work or talks to customers on your behalf.
- Move only those into a custom integration or into your operations system, with ownership, retries and visible failures designed in.
- Leave the rest in Zapier. Notifications, copies and low-stakes tasks stay where they are cheap and easy to change.
Each step has a written scope and cost before it starts, which is how we run all of our work. Integration is one of the four things we do.
If the real problem is that an order passes through five tools before anyone acts on it, replacing the glue will not fix it on its own. We wrote about that in you don't need another SaaS login, you need fewer handoffs.
Questions to ask before you decide
- If this automation stopped for a day, who would notice, and how?
- Does it create or change anything that affects money, stock or customers?
- Could someone new read and understand the rules it follows?
- Whose account is it on, and whose logins does it use?
- How far back can we see what it did to a specific record?
- Have we worked out what it will cost at twice today's volume?
If most answers are reassuring, keep the Zap. If several make you uncomfortable, that automation has become part of your operations system and should be treated like one.
FAQ
Is Zapier good enough for a small business?
For many automations, yes. Zapier is a strong fit for notifications, copying data between mainstream apps and low-stakes workflows. It becomes less suitable when an automation creates invoices, commits stock or runs critical business rules, because those need guaranteed handling of duplicates, immediate visible failures and long-term records.
When should I replace Zapier with a custom integration?
When the automation has become a core business process: it writes records that money depends on, contains complex business rules, chains several Zaps together, or your team regularly checks and fixes its output. Replace only those critical workflows and keep simple ones in Zapier.
Is a custom integration more expensive than Zapier?
Upfront, almost always. A custom integration costs development time and needs hosting and maintenance, while a Zap can be built in an hour. The comparison changes when you include the cost of errors, manual checking and task usage at high volume. Work out what a failure actually costs before deciding.
How fast do Zapier triggers run?
It depends on the trigger. Polling triggers check for new data on a schedule that Zapier lists as 15 minutes on the Free plan, 2 minutes on Professional and 1 minute on Team and Enterprise. Instant triggers, available when the source app supports webhooks, run as soon as the app sends the data.
Can I own a Zapier automation?
You can own the Zapier account and export your Zaps and history, but the automation runs on Zapier's platform and in Zapier's format. With a custom integration built for you, the code and credentials can be registered to your business, and moving to another host or developer is under your control.
The short version
Zapier is excellent glue. Keep using it for convenience. Once an automation creates invoices, commits stock or runs rules your business depends on, it has become part of your operations system, and it deserves one owner per record, safe retries, visible failures, your own logs and code your business owns. Move the critical workflows, leave the rest alone.
Running part of your business on Zaps nobody wants to touch? Book a 30-minute discovery call and walk us through how an order, job or request moves through your tools today. We will tell you which automations we would move, which we would leave in Zapier, and why. You can also see what we've built or get in touch by email.
Related reading: Your ops system and Xero should agree. Usually they don't. · You don't need another SaaS login. You need fewer handoffs. · Every supplier looks the same until you try to leave · "We just use Stripe" is not an architecture