When Should You Move an Automation From Zapier to Code?

When should you move an automation from Zapier to code?

When the per-run cost is genuinely material, when you need control the platform cannot give you, or when you are about to resell the automation to clients. Those are three different reasons with three different answers, and only the first one is about money.

The move people actually make most often is the wrong one. They leave a hosted platform because the bill got annoying, rebuild in code, and inherit a maintenance obligation worth far more than the subscription. The bill was visible and the maintenance was not.

So this article treats it as three separate questions, and includes the licensing trap that catches consultants who assume self-hosting is the obvious middle ground.

How do you tell if cost is really the problem?

Do the arithmetic against the published numbers rather than against the invoice. Zapier's documentation states that each successful tool call through its MCP server consumes two tasks at a fixed rate, and that failed calls do not consume tasks. It also spells out the batch behaviour: adding five rows to a spreadsheet is five tool calls and ten tasks.

That makes your cost curve predictable, which is the point people miss while complaining about it. You can calculate what a workflow will cost before you build it, and a cost you can calculate is a cost you can design around by batching, filtering earlier, or running less often.

Zapier also says that if you reach your plan's task limit, MCP tool calls stop working until the allowance resets or you upgrade. That is a real operational risk, and it is an argument for monitoring your consumption rather than automatically an argument for rewriting anything.

What does the hosted platform actually buy you?

Connections you would otherwise maintain yourself. Zapier says it connects AI tools to Gmail, Slack, Salesforce and more than 9,000 apps, and that your existing app connections are brought in automatically. Every one of those is an authentication flow, a token refresh, and an API change you are not handling.

That is the part that never appears in the comparison spreadsheet. Writing the integration is a day. Keeping it working through three years of upstream changes is the actual cost, and hosted platforms absorb it invisibly until you leave.

There is also a governance property worth naming. Zapier's documentation says each MCP client requires its own MCP server and that you can have multiple servers but only one per named client, which draws a clear boundary around what each AI tool can reach. Rebuilding in code means rebuilding that boundary yourself, deliberately.

When is control the real reason?

When you need behaviour the platform does not expose, and the workarounds have started to look like programming anyway. Complex conditional logic, custom retry strategies, precise rate limit handling, or transformations that need a real language rather than a field mapper.

Rate limits are the specific case where code earns its place fastest. Airtable's documentation says its API is limited to 5 requests per second per base, that exceeding it returns a 429 and requires waiting 30 seconds, and that integrations should back off and wait before retrying. Webflow's documentation gives 60 requests per minute on Starter and Basic plans and 120 on CMS, eCommerce and Business, with a 429 and a Retry-After header.

Implementing considered back-off, batching and concurrency control against those numbers is straightforward in code and awkward inside a visual builder. If your workflow is fighting its platform to respect published limits, that is a real signal rather than a preference.

What is the licensing trap with self-hosting?

That self-hosted does not mean unrestricted, and the restriction bites exactly where consultants operate. n8n uses the Sustainable Use License, which its documentation describes as a fair-code software license created by n8n in 2022, alongside a separate n8n Enterprise License.

The Sustainable Use License allows use, modification, derivative works and redistribution with three limitations that n8n states directly. You may use or modify the software only for your own internal business purposes or for non-commercial or personal use. You may distribute it or provide it to others only free of charge for non-commercial purposes. And you may not alter, remove or obscure licensing, copyright or other notices.

n8n explains what internal business purposes means in practice: all use is allowed unless you are selling a product, service or module in which the value derives entirely or substantially from n8n functionality. It names white-labeling n8n and offering it to customers for money, and hosting n8n and charging people to access it, as examples that would not be allowed.

So can an agency use n8n for client work at all?

Yes, and n8n says so explicitly, which is the part that gets lost in the argument. Its documentation lists providing consulting services related to n8n, for example building workflows, custom features closely connected to n8n, or code executed by n8n, as allowed. Supporting n8n, for example setting it up or maintaining it on an internal company server, is also listed as allowed.

n8n also gives a useful worked distinction for embedding it behind a product feature. In its example, using n8n to embed an AI chatbot where the credentials in n8n are the company's own is allowed, while collecting each user's own credentials to sync their data into an app is not.

If your situation sits near the line, n8n's own answer is to sign a separate commercial agreement, and it publishes a licensing contact address for questions. I am not a lawyer, and the right move here is to read the current license text yourself rather than take any blog post's summary as sufficient. But knowing the line exists before you architect around it saves a great deal of rework.

What do you actually inherit when you move to code?

Four jobs, and only one of them is writing the automation. Authentication and token refresh. Deployment and scheduling. Error handling, retries and alerting. And ongoing response to upstream API changes that used to be somebody else's problem.

The Model Context Protocol illustrates the shape of the work if agents are involved. Its specification defines hosts, clients and servers communicating over JSON-RPC 2.0, with servers offering prompts, resources and tools. That is a well designed surface to build against, and it is still a server you now operate.

My rule of thumb is unglamorous. If nobody on the team will own the automation in eighteen months, do not write it in code, regardless of what the cost comparison says. Unowned code is a liability that starts cheap and gets expensive at the worst moment.

Is there a middle path worth taking?

Usually, and it is the one I reach for most. Keep the hosted platform for the connections and the trigger, and move only the hard part into code called from it. You get maintained authentication and a visual trigger with a real language where the logic lives.

That split also makes the cost behave. If the expensive part of your workflow was a loop making one platform call per record, doing the loop in code and returning a single result collapses the task consumption without abandoning the platform.

It has a nice failure property too. If the code step breaks, the platform reports a failed step, which you can alert on. A fully custom system fails silently unless you built the alerting, which takes us straight to the thing that actually breaks first when automations grow, covered in what breaks first when an automation scales.

How should you sequence a migration if you commit to one?

One workflow at a time, starting with the least critical, and run both in parallel before you switch anything off. The comparison run is the whole value, because it surfaces the assumptions the old system was quietly handling that nobody documented.

Migrate the workflow you understand best rather than the one costing the most. The expensive workflow is usually expensive because it is complicated, and complicated is the worst possible place to learn your new stack's failure modes.

Decide your rollback before you start, and write down what would make you go back. A migration without a stated reversal condition tends to continue on momentum long after it stopped being a good idea. If you are still choosing between platforms rather than leaving them, I compared the main options in Make versus Zapier versus n8n for small businesses.

What should you do next?

Before deciding anything, calculate what your heaviest workflow actually costs per run using the published rates, and separately write down who will own the code version in two years. Those two answers settle most of these arguments in an afternoon.

If the cost is trivial and nobody owns the code, stay where you are and optimise the workflow instead. If you are about to resell an automation built on self-hosted software, read the license before you architect, not after. And if the question is really about agents rather than workflows, that is a different decision, which I set out in MCP server or Zapier integration. If you want a second opinion on a specific workflow, reach out and tell me what it does and how often.