Short Answer
Zapier is the right tool for connecting two systems in a simple, low-volume, non-critical way. New form entry creates a CRM contact; new invoice posts to a Slack channel. If the connection is more involved than “when this happens, do that”, if the volume is climbing into thousands of tasks a month, or if the business genuinely stops working when the connection fails, you have outgrown glue and need a built integration. The monthly bill usually announces this before anything else does.
What Zapier Does Well
It removes the developer from small integrations, and that matters. Waiting two weeks for technical help to connect a form to a spreadsheet is absurd, and Zapier ended that era. It supports thousands of apps, fails visibly enough for simple cases, and lets an operations person own their own plumbing.
For prototyping it is excellent even in businesses with developers on hand. Wiring a process together in an afternoon to see whether it is worth automating properly is cheaper than any discovery workshop.
Where the Cracks Appear
Cost tracks volume. Zapier charges per task, so the more your business grows, the more the glue costs. Automations that cost pennies at 100 orders a month become a three-figure line at 5,000. Teams then start economising on automation, which defeats the point of having it.
Multi-step logic gets fragile. Real processes branch. If the client is new do this, if the value exceeds that threshold do something else, unless it is a weekend. Zapier can express some of this, but a fifteen-step Zap with paths and filters is a program written in the least debuggable editor available. When it misbehaves, finding out why means archaeology in a task log.
Failures are silent by default. A Zap that errors pauses or skips. Unless someone watches the dashboards, the first sign is a client asking why nothing happened. For a courtesy notification that is tolerable. For order processing it is not.
Some things it simply cannot reach. Systems without a public API, APIs with unusual authentication, high-frequency syncing, bulk transformations, anything needing state held between events. The workarounds exist but they are workarounds.
What a Custom Integration Changes
A built integration is code that talks to both systems directly. No per-task pricing, so cost stops tracking growth. Logic as complex as the business requires, expressed in a language made for logic. Proper error handling: retries, queues, alerts to a human when something needs one. And access to everything the APIs offer rather than the subset a connector exposes.
The trade-offs are the honest ones of owning software. It has to be built, which costs more up front than a £30 subscription. It needs a home to run in and someone responsible for its health. Building a custom integration for a job Zapier does adequately is over-engineering, and we decline that work when we see it.
A Rule of Thumb That Holds Up
Count what a connection is worth, not what it costs. If a failed sync means a lost order, a compliance problem, or an hour of manual repair, the connection is infrastructure and deserves to be built as infrastructure. If a failed sync means a Slack message arrives late, leave it in Zapier and spend the build budget where it counts. Most businesses have both kinds. The mistake is treating them the same.
How We Approach This
API integrations are core work for us: direct system-to-system connections with proper queuing, retries, and alerting, built around what your business can and cannot afford to have fail. The wider discipline of business automation covers the processes those integrations serve. We regularly leave clients’ harmless Zaps exactly where they are and replace only the load-bearing ones, and we will tell you which is which if you get in touch. If you are earlier in the journey and weighing whether decision-making automation belongs in the picture, AI agents vs automation covers that boundary, and custom software vs off the shelf covers the whole-system version of the same trade.
