Most teams start automating with a no-code tool. Someone connects a form to the CRM, then adds a Slack alert, then an invoice step, and a year later the business depends on dozens of workflows that nobody fully owns. At that point the question comes up: keep paying for Zapier, Make or n8n, or build custom automation instead?
This guide explains what each option is good at, how the pricing models work, what self-hosting n8n really involves, where no-code platforms run out of room, and how to move selected workflows to custom code without a risky big-bang rewrite.
Quick answer
Use a no-code automation tool when the workflow connects well-known apps, the volume is modest, the logic is mostly linear, and a failed run is an inconvenience rather than a business incident. Build custom automation when a workflow is high volume, central to revenue or operations, needs complex rules or strict error handling, touches sensitive data, or relies on systems that have no ready-made connector.
For most companies the right answer is a mix: no-code tools for the long tail of small internal tasks, and custom code for the few workflows the business cannot afford to lose. The choice should be made per workflow, not per company.
What no-code automation platforms are good at
Zapier, Make and n8n all do the same basic job. A trigger (a new order, a form submission, a scheduled time) starts a sequence of steps that read or write data in other applications. They differ in style: Zapier favors simple step-by-step flows, Make uses a visual canvas suited to branching scenarios, and n8n is aimed at more technical users and can be self-hosted.
Their real strengths are:
- Speed. A working automation can exist the same afternoon the idea comes up, without a developer.
- Pre-built connectors. Authentication, pagination and API quirks for popular apps are already handled by the vendor.
- Low commitment. You can test whether a process is worth automating before investing in it.
- Ownership by the business team. Operations or marketing staff can change a workflow without waiting for a release.
- No infrastructure. On the hosted versions there are no servers, deployments or patches to manage.
If a workflow fits those strengths, building it in custom code is usually a waste of money. If you are unsure whether you need rule-based automation at all or something closer to an AI agent, see our comparison of AI agents, chatbots and workflow automation.
How the pricing models work
We are deliberately not quoting prices here because plans change often. What matters for planning is the unit each vendor bills on, since that decides how cost grows with your usage. Always check the vendor's current pricing page before you commit.
| Platform | Billing unit | What that means in practice |
|---|---|---|
| Zapier | Tasks | Zapier combines a plan level with a monthly task tier. Per its help center, successful action steps count as tasks, while trigger steps and Filter or Paths steps do not. Cost grows with the number of actions per run. |
| Make | Credits (based on operations) | Make defines an operation as a single module run, and modules process each bundle of data separately. For non-AI apps, one operation equals one credit. Cost grows with steps multiplied by the number of items processed. |
| n8n | Workflow executions | n8n's pricing page defines an execution as a single run of the entire workflow, regardless of how many steps it contains. Cost grows with how often workflows run, not how long they are. |
Two practical consequences follow. First, the same workflow can be cheap on one platform and expensive on another. A ten-step workflow that loops over 200 order lines consumes far more units on a per-step model than on a per-execution model. Second, you need to know what happens at the limit. Zapier's pricing page describes two outcomes when you exceed your task allowance: with pay-per-task enabled, runs continue and extra tasks are billed at an overage rate up to a cap; with it disabled, automation pauses until the next billing cycle. Make states that scenarios stop running until credits are added. Either way, a seasonal spike can produce a surprise bill or a silent outage unless someone is watching usage.
Self-hosting n8n: what the license and docs actually say
n8n is often described as "the free, open source alternative". Both words need qualifying.
Licensing
According to n8n's license documentation, n8n is released under the Sustainable Use License and the n8n Enterprise License, a model it calls fair-code. The source code is available, but it is not open source in the Open Source Initiative sense because commercial use is restricted. The license text permits use and modification for your own internal business purposes or for non-commercial or personal use.
In plain terms, based on n8n's license FAQ: automating your own company's processes on a self-hosted Community edition is allowed, and so is paying a consultant to build workflows for you. Hosting n8n as a service where your customers build their own workflows, or white-labelling it, is not allowed without a separate commercial agreement. If you plan to put n8n inside a product you sell, read the license and ask n8n directly. This is a summary, not legal advice.
Hosting and features
n8n documents several install options, including Docker, Docker Compose and npm. The self-hosted Community edition is free, but "free" refers to the license, not the total cost. You still pay for servers, and someone must handle updates, backups, security patches, monitoring and credentials.
Two further points are easy to miss:
- The Community edition does not include everything. n8n's feature list excludes SSO (SAML, LDAP), version control using Git, environments, external secrets, log streaming, projects, and sharing of workflows and credentials. These require a paid plan.
- Scaling takes real infrastructure. n8n's queue mode, which it describes as providing the best scalability, runs a main instance plus worker instances and requires Redis as a message broker and a PostgreSQL database.
Self-hosted n8n is a sensible middle option when you have technical staff, want data to stay on your own infrastructure, and run enough executions that per-unit pricing hurts. It is not a way to avoid engineering work.
Where no-code tools hit their limits
Volume and cost
Usage-based pricing is friendly at low volume and unforgiving at high volume. Polling triggers add delay as well: Zapier notes that the polling interval depends on your plan and the trigger app, although instant triggers fire immediately. When a single workflow accounts for most of your monthly usage, it is a candidate for custom code.
Complex logic
Visual builders handle "if this, then that" well. They become hard to read and test once a workflow has nested branches, loops inside loops, state carried between runs, or calculations a developer would write in twenty lines. Code steps help, but with constraints. For example, n8n's Code node documentation states that on n8n Cloud you cannot import external npm modules, while self-hosted instances can enable them.
Error handling
All three platforms offer error handling, and it is better than many people assume. Zapier documents autoreplay and custom error handlers, Make provides error handlers such as Retry, Resume and Rollback and can disable a scenario after consecutive errors, and n8n supports a dedicated error workflow that runs when an execution fails.
The gap is in guarantees. If step four of seven fails after a payment has been taken, what happens to steps one to three? If the same webhook arrives twice, do you create two invoices? No-code tools leave those questions to whoever built the workflow, and they are rarely answered until something breaks.
Security and compliance review
Every workflow passes your data, and your stored credentials for other systems, through a third party. That triggers practical questions: where is data processed, how long are run logs kept, who in your team can see them, and what contract covers it. In the UK, the ICO explains that UK GDPR Article 28 sets out what a contract between a controller and a processor must include. In the US the rules depend on your sector and state, and regulated data such as health or financial records often carries its own vendor requirements. Check with your own counsel; this is not legal advice.
Vendor dependence
A workflow built on one platform cannot simply be moved to another; in practice it has to be rebuilt. Pricing units, plan limits and connector behavior can change, and you adapt on the vendor's schedule. There is also a quieter risk: workflows tied to one employee's account, with no documentation, that stop when that person leaves.
What custom automation involves
Custom automation means software written for your process: code that listens for events, applies your business rules and calls the APIs of the systems involved. It is usually a small backend service or a module inside an application you already have, not a huge project.
A production-grade build normally includes:
- Integrations written directly against each system's API, including authentication and rate-limit handling.
- A job queue so work is processed reliably and can be retried.
- Explicit handling for duplicates, partial failures and bad data.
- Logging, monitoring and alerts that reach a person.
- Automated tests, version control and a deployment process.
- Secure storage of credentials and controlled access.
- An admin screen or report so non-technical staff can see what happened.
The trade-off is straightforward. You pay more upfront and take on maintenance, because third-party APIs change and someone has to update the code. In return you get a predictable running cost that does not scale with every step, logic of any complexity, full control over data, and no platform ceiling.
The main cost drivers are the number of systems integrated, the quality of their APIs, how many exception paths the process has, compliance requirements, and whether staff need an interface. If you plan to use an external team, our guide on how to outsource software development from the US or UK covers contracts, IP and vetting.
Decision table: no-code, self-hosted or custom?
| Factor | Hosted no-code (Zapier, Make, n8n Cloud) | Self-hosted n8n | Custom automation |
|---|---|---|---|
| Best for | Low to moderate volume, standard apps, quick wins | Higher volume, technical team, data kept in-house | Core, high-volume or complex processes |
| Time to first result | Hours to days | Days, plus server setup | Weeks or more, depending on scope |
| Cost pattern | Low start, rises with usage | Infrastructure and staff time; paid license for some features | Higher upfront, then hosting and maintenance |
| Who maintains it | Business users | Technical staff | Developers |
| Complex logic | Limited, gets hard to manage | Better, with code nodes | Unrestricted |
| Error handling | Built-in features, designed by the builder | Built-in features, designed by the builder | Designed to your requirements |
| Data control | Data passes through the vendor | Stays on your infrastructure | Stays on your infrastructure |
| Vendor dependence | High | Medium (license terms, platform format) | Low (you own the code) |
| Systems without connectors | Possible through generic HTTP steps, often awkward | Possible, including custom nodes | No constraint |
A useful rule of thumb: if a workflow failing for a day would cost you money or customers, it deserves the engineering discipline of custom code or, at minimum, a carefully run self-hosted setup.
A migration path from no-code to custom
Moving everything at once is rarely justified. A staged approach lowers risk and lets the savings from early moves fund later ones.
- Inventory what exists. List every workflow, its owner, the systems it touches, and what happens to the business if it stops. Expect to find workflows nobody remembers creating.
- Measure usage. Pull task, credit or execution counts and failure rates per workflow from the platform's history. A small number of workflows usually accounts for most of the usage.
- Pick candidates. Prioritize workflows that are high volume, business critical, handling sensitive data, or frequently failing. Leave low-volume convenience automations where they are.
- Write down the real process. The existing workflow is a working specification. Document the rules, and add the exceptions staff currently fix by hand, because those are what the custom version must handle.
- Build one workflow first. Choose a single candidate and build it properly, with a queue, retries, logging and alerts. This sets the pattern for the rest.
- Run both in parallel. Let the new system process the same events without acting on them, or on a small share of traffic, and compare results against the no-code workflow.
- Cut over and keep a fallback. Switch off the old workflow but keep it available for a short period in case you need to roll back.
A hybrid end state is normal. In an illustrative scenario, an online retailer might keep Zapier for marketing notifications and internal alerts, while order routing, inventory sync and invoicing move into a custom service. The no-code tool can still call that service through an API when a business user needs to trigger something.
For technical readers
- Prefer webhooks to polling where the source system supports them, and verify signatures on incoming requests.
- Make handlers idempotent. Store an event or idempotency key so a redelivered webhook does not create duplicate records.
- Put work on a queue. Acknowledge the event quickly, process it in a worker, retry with backoff, and route exhausted jobs to a dead-letter queue for review. Queue systems in frameworks such as Laravel or Node.js cover this well.
- Design for partial failure. For multi-step processes, record state per step so a run can resume or compensate instead of starting again.
- Treat self-hosted n8n as production software. Use PostgreSQL, plan for queue mode before you need it, pin versions, and test your backups and upgrade process.
Frequently asked questions
Is n8n free and open source?
The self-hosted Community edition is free to use for your own internal business purposes, and its source code is public. n8n describes its license as fair-code rather than open source, because the Sustainable Use License restricts commercial use such as offering n8n as a hosted service. Some features require a paid license.
Is Zapier, Make or n8n cheapest?
It depends on the shape of your workflows. Zapier bills on tasks, Make on credits tied to operations, and n8n on workflow executions. Long workflows that process many items tend to favor per-execution billing; short, infrequent ones may cost little anywhere. Model your own top workflows against each current pricing page.
When should we replace a no-code workflow with custom code?
When one or more of these is true: it drives a large share of your platform bill, failures cause real business harm, the logic has outgrown the visual builder, a security or compliance review raises concerns about third-party data handling, or a system you rely on has no usable connector.
Can no-code and custom automation work together?
Yes, and they usually should. Custom services can expose API endpoints or webhooks that a no-code tool calls, so critical logic lives in code while business users keep the flexibility to build light workflows around it.
Does custom automation need ongoing maintenance?
Yes. Third-party APIs change, credentials expire and business rules evolve. Budget for monitoring, updates and occasional fixes. The same is true of no-code workflows, although there the vendor maintains the connectors and you maintain the workflow logic.
Is self-hosting n8n safer than using a cloud automation tool?
Not automatically. Self-hosting keeps data on infrastructure you control, which helps with some data residency and review requirements, but it makes you responsible for patching, access control, backups and monitoring. A poorly maintained self-hosted instance can be less secure than a managed service.
Conclusion
No-code automation tools are the right starting point for most businesses and remain the right tool for many small workflows indefinitely. Their limits show up in specific places: usage-based cost at volume, complex logic, failure guarantees, data handling and dependence on the vendor. Custom automation answers those limits at the price of upfront development and ongoing maintenance, and self-hosted n8n sits between the two for teams with technical capacity.
The practical next step is the inventory described above: list your workflows, measure their usage and failure rates, and mark the few that are critical. If that exercise shows one or two workflows that should move to custom code, Entrant Technologies builds custom software and web applications and can scope the work with you.
