Is n8n or Make better for a small business?
Make is the better default for most small businesses. There is no infrastructure to run, the connector library is larger, and the visual editor is followable by non-developers. It is priced per operation, so cost rises with volume.
n8n wins in three specific situations: high execution volume where per-operation pricing becomes painful, a requirement to self-host for data residency or compliance, and logic complex enough that you want real code inside nodes. The crossover is driven almost entirely by how many operations your workflows consume per month — not by how many workflows you have.
Both vendors revise their plans regularly. This page describes the shape of each pricing model and how to reason about the crossover, which is stable. The specific tier prices are not, so check the vendors' current pages before committing. Any figures below are illustrative of the method, not quotes.
The pricing models are the whole story
Almost every "which platform" argument is really a pricing argument wearing a technical costume. The features overlap heavily. The cost curves do not.
Make charges per operation. An operation is roughly one module doing one thing once. A workflow with eight steps that runs 500 times a month consumes about 4,000 operations. Your bill scales directly with how much work you do. At low volume this is excellent — you pay very little. At high volume it compounds, and the compounding is invisible until the invoice arrives.
n8n Cloud charges per execution — one whole workflow run, regardless of how many steps are in it. A 40-step workflow and a 3-step workflow cost the same. This inverts the incentive: complex workflows become cheap rather than expensive.
Self-hosted n8n charges nothing per anything. You pay for a server, typically a small cloud instance at $10 to $40 a month, and run unlimited executions on it. The cost is fixed and the constraint becomes CPU rather than billing.
So the question is not "which is better." It is: at your volume and step count, which curve is cheaper, and is the difference big enough to justify running a server?
How to estimate your operation count
Do this before you talk to anyone. It takes ten minutes and it decides the answer.
- List your intended workflows. Say five.
- For each, count the steps. Every module that does something — fetch, filter, transform, create, notify. A typical lead-routing flow is six to ten.
- Estimate runs per month. How many leads, orders, invoices, messages.
- Multiply and sum. Steps × runs, added across all workflows.
Worked example: lead routing at 8 steps × 300 runs = 2,400. Invoice processing at 12 steps × 400 = 4,800. Onboarding at 15 steps × 40 = 600. Reporting at 20 steps × 22 = 440. Email triage at 6 steps × 2,000 = 12,000. Total: about 20,240 operations a month.
Notice what dominates. Email triage is the simplest workflow on the list and consumes 60% of the budget, purely because it runs constantly. High-frequency, low-complexity workflows are what push you off Make's cheaper tiers — not the big impressive ones.
Under roughly 10,000 operations a month, Make is almost always the cheaper and easier answer. Above roughly 100,000, self-hosted n8n is usually decisively cheaper. Between the two, model it properly — the answer depends on your step counts, and on whether anyone on your side can look after a server.
Choose Make when
- Nobody wants to run infrastructure. This is the single biggest factor for most small businesses, and it is a legitimate reason on its own. Self-hosting means patching, backups, monitoring and an upgrade path. If nobody owns that, do not choose it.
- You need broad connector coverage. Make's library is larger and its connectors tend to cover more of each API's surface. Fewer things need custom HTTP calls.
- Non-technical people need to read the workflows. The visual canvas is genuinely followable by an operations manager, which matters for handover.
- Volume is moderate and predictable. Under about 10,000 operations a month, the cost is small enough not to be a decision factor.
- You want error handling without building it. Make's error-handling routes and rollback behaviour are mature and well documented.
Choose n8n when
- Volume is high. Above roughly 100,000 operations a month, self-hosting saves real money — often thousands a year. This is the clearest case.
- Data cannot leave your infrastructure. Healthcare, finance, or any EU data-residency requirement. Self-hosted n8n keeps everything inside your own environment, which is sometimes not a preference but a condition.
- Your logic wants real code. n8n's code nodes are first-class. If your transformations involve genuine programming rather than field mapping, this is far more comfortable.
- You want version control. Workflows are JSON and can live in Git, with proper review and rollback. For teams with engineering discipline this is a significant advantage.
- You already run infrastructure. If you have a Kubernetes cluster or a managed container platform and someone who looks after it, the marginal cost of one more service is close to zero.
The honest counterweight: self-hosting is a commitment. It is not hard, but it is not nothing, and the cost saving evaporates if it consumes an afternoon a month of someone expensive. n8n Cloud exists precisely for teams that want the execution-based pricing without the server, and it is often the right middle path.
Where Zapier and Power Automate fit
Zapier is the easiest to start with and the most expensive to scale. Its connector library is the largest in the market and its interface is the most forgiving. For genuinely simple automations — a trigger and two actions — it is the fastest route and you should just use it. For multi-branch logic it becomes awkward and costly, and most businesses that outgrow it move to Make.
Power Automate makes sense when you are deep in Microsoft 365 and the licence is already paid for. Its integration with SharePoint, Teams, Outlook and Dataverse is better than anything else can offer. Outside the Microsoft estate its connectors are weaker, and the developer experience is less pleasant. If your business runs on Microsoft and the licensing is sunk, check this first.
Plain code deserves mention. If a job is heavy data processing on a schedule with no need for a visual interface, a Python script on a cron job is cheaper to run, faster, and easier to version than any of the above. Visual platforms earn their cost when non-developers need to see and modify the logic — not universally.
Switching later
Workflows do not port between platforms. There is no export from Make that imports into n8n; the concepts are similar but the implementation is not. Switching means rebuilding, at roughly 40 to 60% of the original build cost — cheaper than the first time because the logic and edge cases are already known and documented.
This is why the platform choice is worth ten minutes of modelling at the start. It is not irreversible, but it is not free either.
Two things reduce the cost of being wrong: keep business logic documented separately from the tool that implements it, and avoid depending on any one platform's exotic features when a plain approach would do.
We hold no reseller agreements, take no affiliate commission, and do not resell licences on any platform. You buy your own subscriptions directly. That is deliberate — it is the only way a platform recommendation means anything. If you want the cost model run properly for your volumes, that is part of a strategy sprint.
Want the model run on your numbers?
Tell us your workflows and volumes and we will show you the three-year cost on each platform.