Zapier, or a custom integration
What a connector is genuinely good at, and the point it stops being enough.
Connectors are right for low volume, simple mappings and anything still changing shape. Move to a build when volume makes per-task pricing the larger cost, when a silent failure would matter, or when one logical step has grown into a chain of seven nobody can read.
Work it out in a minute
Six questions on one task, scored on volume, rules, stability and judgment. Returns a straight verdict.
What we take on
Connectors are right more often than not
A handful of steps, modest volume, a mapping a person can hold in their head, and a process still changing shape. That is most integrations, and building one of those is a way to spend money slowly.
Volume turns the arithmetic
Per-task pricing is cheap until the task count grows, and it grows with the business rather than with the process. Work out the monthly cost at next year's volume, not this month's.
Silence is the real risk
A connector that stops firing at two in the morning tells whoever set it up, in an inbox they may not read. Anything where a missed record means a missed invoice or a missed order needs a failure somebody sees.
Seven steps is the signal
One logical operation spread across a chain of steps with branches and lookups is a program written in a place that was not built for programs. That is the point to move it.
There is a middle option
Most systems have a native connection to the other system, and it is usually better than either route. Check what your tools already do together before adding a third party between them.
Build the piece, not the platform
A build does not mean replacing everything. It usually means one small service doing one job reliably, with logs, retries and an alert, while the connectors keep the low-stakes work.
How to decide without guessing
Start by writing down what actually flows: which system, which record, how often, and what has to be true for it to count as done. Most integration arguments are two people describing different processes and neither has written one down.
Then check whether the two systems already talk. Native connections have improved sharply and they are supported by the vendor rather than by whoever set them up. This is the cheapest good answer and it gets skipped constantly.
If nothing native exists, a connector is the right first move for anything still settling. Shape changes are cheap there, and a process that is going to change three times this quarter should not be built into code yet.
The three signals to move are volume, consequence and complexity. Volume when per task pricing at next year's numbers is larger than a build. Consequence when a silent miss costs money. Complexity when one step became seven.
A build should still be small. One service, one job, a log of what it did, a retry when the other end is down, and an alert somebody actually receives. The failure behavior is most of the value, and it is what the connector could not give you.
The pattern that lasts is a mixed one. Keep connectors for the low-stakes flows where speed of change matters, and build the two or three paths where a missed record shows up on an invoice.
Questions we get
How do we know we have outgrown Zapier?
Three signals. The monthly task cost at next year's volume is larger than a build would be. A failure has gone unnoticed for longer than a day. One process has spread across more steps than a person can follow.
Any one of them on its own is a conversation. Two together is a decision.
Is a custom integration expensive to maintain?
A small one is not. It is a single service doing a single job, and it changes when the systems either end change, which is rare. What is expensive is a build that tried to replace a platform rather than a path.
Scope it to one flow and it stays small.
What about Make, n8n and the others?
The same decision applies, with better economics at volume and more capability in the middle. They move the point at which a build wins, and they do not remove it.
Self-hosting one of them is a build with extra steps, so count it as a build.
Can you fix what we already have rather than replace it?
Usually, and it is the first thing to try. Most failing automations are failing because nothing watches them, not because the design was wrong.
Logging, retries and an alert on a path that already works often ends the conversation about rebuilding it.
Who owns the accounts?
You do. Your connector account, your API keys, your logs. Work happens inside your accounts under your login, and a change of provider does not mean a change of anything else.
If the automation lives in somebody else's account, that is the first thing to move.
Should we automate this at all?
Not always. A task that runs twice a month, changes every time and takes ten minutes is not the one to start with. The automation scorecard on this site scores a single task on volume, rules, stability and judgment.
The best first automation is boring, frequent and unchanging.
More in the guides and every answer in one place.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built