Zapier, Make and When to Build Instead
Last updated:
They are genuinely useful
Connecting two systems and adding an AI step in an afternoon has real value, particularly for proving that an automation is worth having at all.
Dismissing them is a mistake. So is building your core operations on them without noticing what it costs.
Where they work well
- Low to moderate volume — hundreds of runs a month, not tens of thousands
- Simple linear flows with few branches
- Connecting popular products with existing connectors
- Proving a concept before committing to a build
- Internal notifications and routing
Where they stop working
| Problem | What happens |
|---|---|
| High volume | Per-task pricing overtakes a build within months |
| Complex branching | Flows become unreadable and unmaintainable |
| Error handling | Limited retry and recovery options |
| Testing | No real way to test a change before it is live |
| Version control | Changes are hard to review or roll back |
The pricing crossover surprises people. A workflow at fifty thousand runs a month can cost more annually than the build it replaced.
A sensible progression
- Build it in the platform to prove the value
- Measure the volume and the monthly cost
- Rebuild the high-volume path as a service
- Keep the platform for the low-volume long tail
That is not a criticism of the tools. It is using each for what it is good at.
The maintainability question
A flow with thirty steps and branching logic is a program written in a form nobody can review, test or roll back properly.
When you reach that point, the platform has stopped saving you effort and started deferring it.
Frequently asked questions
Should we start with a no-code platform?
At what volume should we rebuild?
Can you take over a flow we built?
Are they secure enough?
Automation platform bill growing quietly?
Worth comparing against a build. Tell us your monthly task count and we will do the arithmetic.