Integrations2 min readBy Ry
Zapier vs a custom integration: when to switch
No-code automation is the right answer surprisingly often. Here are the specific signs that you have outgrown it, and what a custom integration actually changes.
Zapier, Make and n8n are genuinely good tools. For a lot of small businesses, a handful of well-built workflows is the correct amount of automation, and paying someone to write custom code instead would be a waste of money.
But there is a point where no-code stops being the cheap option. The trick is noticing when you have crossed it.
Stay on no-code if…
- Volume is low: hundreds of runs a month, not tens of thousands
- Each workflow is a straight line: trigger, a couple of steps, done
- A failed run is an inconvenience, not a financial problem
- The people who built the workflows still work there and understand them
If all four are true, clean up what you have and keep going. Tidy naming, error notifications and a short document describing each workflow will do more good than a rebuild.
Signs you have outgrown it
1. The bill is growing faster than the business
Task-based pricing is fair at low volume and punishing at high volume. When a single high-frequency workflow pushes you up a tier, compare a year of that tier against the one-off cost of building it properly. Hosting a custom integration on a modern platform often costs a small fraction of that.
2. Your workflows are mostly branches and filters
When a workflow has more paths for exceptions than for the normal case, it becomes hard to read and very hard to change safely. Code handles branching logic in a way that can be tested and reviewed.
3. Failures are silent or unrecoverable
If a run fails halfway, did the order get created but the inventory not update? Can you replay it without creating duplicates? Custom integrations can be designed to be idempotent (safe to run twice) and to keep a log you can replay from. That matters most when money or stock is involved.
4. Two systems need to agree, not just notify
Pushing an event from A to B is what no-code does best. Keeping A and B in agreement over time, handling conflicts, edits in both places and missed events, is a synchronisation problem, and it needs a single source of truth that lives somewhere you control.
5. Nobody wants to touch it
The clearest sign of all. When a workflow is load-bearing and people are afraid to edit it, it is already technical debt, just without version control or tests.
What changes with a custom integration
- Cost moves from per-task to mostly fixed hosting
- Logic lives in version-controlled code with tests
- Failures alert a person with context and can be replayed
- Data can be stored in a canonical record you own, so systems reconcile against one truth
- Ownership: you should receive the code, the accounts and the documentation
Questions to ask before you switch
- Which workflows account for most of the task volume?
- Which failures in the last three months cost real money?
- What would a year of the current plan cost versus a one-off build plus hosting?
- Who will own the new integration, and how will it be documented?
If the answers point to a rebuild, keep the scope tight: move the expensive flows, leave the rest. That is how most integration projects should start.
Written by Ry, Evenbuilt · Los Angeles
All posts