Zapier or Make vs a custom integration: the break-even

Where is the break-even between Zapier or Make and a custom integration?

There is no universal number, and anyone who gives you one without seeing your flow is guessing. The break-even is where the monthly platform bill plus the time you spend babysitting it passes the one-off build cost plus its running cost. For most small flows that point never arrives. For a few flows it arrives quickly, and you can find out which kind you have with a short calculation.

We build custom software, so we have a stake in this question. Our honest starting position is the opposite of a sales pitch: start with the no-code tool, and move only when one of the criteria below clearly points the other way.

How do Zapier and Make bill?

Both bill by usage per month, not by number of automations. The details change, so check the vendor pages at the time you decide. At the time of writing (2026-10):

• Zapier counts tasks. According to Zapier, a task is anything it successfully completes on your behalf, such as creating a row or sending an email. Triggers, filters and paths, formatting steps, built-in loops and delays, and failed steps do not count. Advanced AI steps count for more than one task. You choose a plan and a monthly task tier. If you go over, Zapier's pricing page says automation either pauses or extra tasks are billed at a higher multiple of your base rate.
• Make counts credits. Make's help pages say that by default one operation equals one credit, and that AI and some advanced features consume credits based on actual usage, such as tokens. Plans include a set number of credits per month. When they run out, scenarios stop until you buy more or change plan.

The practical consequence is the same on both: cost scales with steps times runs. A flow with five action steps that runs 200 times a day uses far more than a flow with one step that runs 200 times a day. Look at the usage report for your busiest real flow, not at the plan headline, and multiply by what your business will look like next year.

What are the decision criteria?

Score your flow against these five. They matter more than any price.

1. Volume. Steps per run times runs per month. Low and steady: stay. High, or spiky (a sale, a month-end batch): the bill and the pause-when-limit-is-hit behavior both become risks.
2. Error handling. What happens when the other system is down, a record is malformed or a call times out? Make documents error handlers and retries with exponential backoff, and Zapier does not charge for failed steps, but in both cases you are working within the tool's model. If you need custom rules such as "retry for an hour, then queue, then alert a named person, and never create a duplicate order", that is code.
3. Data sensitivity. Every record passes through a third party's servers. For marketing leads that may be fine. For health, payment or legal data, check your contracts, your regulator and the vendor's terms, and ask whether data should leave your systems at all.
4. Ownership. A no-code flow lives in someone's account. Ask who owns that account, who can see the logic, and what you would do if the vendor changed pricing or closed a feature. Code in your repository can be moved, reviewed and versioned. Our clients own their code, and we think that is the right default.
5. Change frequency. If the business rules change monthly and a non-developer needs to edit them, a visual tool wins. If the rules are stable and the cost of a mistake is high, code wins, because it can be tested and reviewed before release.

What does a custom integration actually cost you?

Do not compare a platform bill with a build price only. Put both on the same footing:

• Build: specification, development, testing against the real systems, and the handover.
• Running: hosting, monitoring, alerts, and someone to fix it when an API changes. APIs do change, and a custom integration breaks when they do just as a Zap or scenario can.
• Change: what each future rule change costs, in money and in waiting time.
• Failure: what one missed or duplicated record costs you, in money and in trust.

On the no-code side, add the hours your own team spends fixing broken runs, reconciling records by hand and working around the tool's limits. Those hours are real and usually left out.

How do you work out the break-even for your case?

1. Open the usage report for the flow and write down monthly steps for the last three months.
2. Take the plan tier that covers your peak month, from the vendor's current pricing page, and write down the yearly cost.
3. Add the hours per month your team spends on that flow, at your own hourly cost.
4. Ask for a written estimate for the custom version, split into build, running and change.
5. Compare the yearly cost of both over three years, and note which one carries the bigger risk if it fails.

If the custom estimate is not clearly lower over three years and safer, stay on the tool. If the platform bill is rising with volume and the flow touches money or sensitive data, the custom side usually deserves a closer look. Keep a third option in mind: hybrid. Many teams keep the tool for simple notifications and move only the one critical flow into code.

When this is not for you

• If your flow has two or three steps, runs a few hundred times a month and an error is easy to spot, do not build custom. A no-code tool is cheaper and easier to change.
• If you do not yet know what the process should be, automate nothing. Writing it down comes first, and a tool is a good way to test it cheaply.
• If your team will change the logic every few weeks without a developer, a visual tool fits that better than we do.
• If you want a build because "custom is more professional", we will tell you that is not a reason.

What should you do next?

Bring one flow, its monthly step count and the last time it failed, and we will tell you plainly whether it should stay on a tool, move to code, or be split. You can book a free call and we will go through it with you.