n8n vs Make: Which Automation Platform Should You Build On?

Most comparisons of these two platforms are written by people who have committed to one of them. This one is written from the position of having shipped production workflows on both, and having migrated clients off each in different directions when the fit was wrong.

The honest answer is that the platform matters far less than most buyers expect, and the thing that actually determines whether an automation survives its first year is something neither vendor advertises. We will get to that. First, the structural difference that everything else follows from.

The pricing model is the real difference

n8n and Make look similar in a demo. Both give you a canvas, a library of app connectors, and a way to chain steps together. The divergence is in how they count what you use, and it changes which one is affordable at scale.

Make bills by operation. Every module that runs consumes one operation. A workflow with twelve modules that processes a hundred records burns through operations at a rate proportional to the complexity of the workflow multiplied by the volume of data.

n8n bills by execution. One workflow run is one execution, whether that workflow contains three nodes or sixty.

This sounds like an accounting detail. It is the single largest cost driver in the decision. A workflow that loops over line items in an order, or iterates through rows in a spreadsheet, or fans out across a list of contacts, behaves completely differently under the two models. On Make, the cost scales with the work being done inside the workflow. On n8n, it does not.

The practical consequence: high-volume, many-step workflows get expensive on Make in a way that is difficult to predict from a pilot. A workflow that costs very little while you are testing it with ten records can become the largest line item in your automation budget once it is running against your real order volume. We have been called in to fix exactly this more than once, and the fix is usually a migration rather than an optimisation.

Where n8n is the right call

You need to self-host. This is the decisive one. n8n can run on your own infrastructure, which means the data flowing through your workflows never leaves servers you control. For anyone handling patient data, financial records, or operating under a data residency requirement, this is not a preference but a compliance precondition. Make is software as a service, with no self-hosted option.

Your logic is genuinely complex. n8n's Code node lets you drop into JavaScript or Python at any point in the flow. When a transformation is awkward to express as a chain of visual modules, you write eight lines instead of assembling fifteen boxes. Workflows that involve real branching, recursion, or data reshaping stay legible on n8n and become sprawling on Make.

Volume is high or unpredictable. Per the pricing logic above, if you cannot forecast how many records a workflow will touch, execution-based billing protects you from a surprise.

You want the workflow definition in version control. n8n workflows are JSON. They can be exported, diffed, reviewed, and restored. If an automation is load-bearing for your operations, being able to see what changed and when is worth a great deal.

Where Make is the right call

Someone non-technical will maintain it. This is Make's genuine advantage and it is underrated. The visual canvas communicates intent well. A operations manager who did not build the workflow can open it, follow the path, and understand what it does. n8n's canvas is more compact and assumes more; handing it to someone who does not write code is a harder handover.

The integration you need is first-party there. Make's connector catalogue is broad and the connectors tend to be deep, exposing more of each app's API surface out of the box. If your stack is mainstream and your workflow is a straightforward chain between well-known SaaS products, Make will get you there faster with less custom work.

The workflow is simple and the volume is modest. Where the operations model does not hurt you, Make's ergonomics are pleasant and the time-to-first-working-automation is short.

You do not want to run infrastructure. Self-hosting n8n means someone owns the server, the upgrades, and the backups. Make removes that question entirely. If nobody on your team wants that responsibility and compliance does not force your hand, that is a legitimate reason to choose it.

When the answer is neither

There is a point where both platforms become the wrong tool, and recognising it early saves a rebuild. We reach for custom code when:

• The workflow is the product. If the automation is what your customers are paying for, rather than something that supports your operations, it needs the testing, error handling, and deployment discipline of real software.
• The integration target is hostile. Legacy systems, on-premise databases, and older ERPs frequently have no usable API. Getting data out means direct database reads, file drops, or screen-level integration. Both platforms struggle here, and we handle it as a legacy system automation project instead.
• Latency matters. Visual platforms add overhead per step. If a response has to come back in under a second, that budget disappears quickly.
• The logic has outgrown the canvas. When a workflow needs a scroll bar in both directions to see it, the visual representation has stopped helping and started hiding things.

In practice most of what we build for clients is a mix. A visual platform orchestrates the flow and handles the connectors, and the two or three genuinely difficult steps are custom services the workflow calls out to. This is usually cheaper and far more maintainable than forcing either extreme.

The lock-in question nobody asks early enough

Here is what actually determines whether an automation survives: who can change it, and what happens when the person who built it is unavailable.

Neither platform offers meaningful portability. A Make scenario cannot be imported into n8n, and the reverse is equally untrue. The connectors, the expression syntax, and the data structures are all platform-specific. Choosing one is a commitment, and the cost of reversing it is a rebuild rather than a migration.

That makes two questions more important than any feature comparison:

Do you own the account? If an agency built your automations inside their workspace, you do not have a system, you have a dependency. Every automation we build lives in the client's own account, on the client's own credentials. They give us access and we work inside their environment. When the engagement ends, nothing has to move, because nothing was ever ours.

Is it documented in a form a stranger can read? A workflow canvas shows what happens but rarely why. The decision to retry three times before escalating, the reason a particular field is mapped the way it is, the edge case that a filter exists to catch: none of that is visible in the boxes. Automations die when the reasoning is lost.

How we actually decide

When we scope a build, the platform question resolves in roughly this order:

1. Is there a data residency or compliance constraint? If yes, self-hosted n8n, and the decision is made.
2. Who maintains this in a year? If the answer is a non-technical person on the client's team, that weighs heavily toward Make.
3. What does the volume look like at twelve months, not today? Model the operations cost at realistic scale, not pilot scale.
4. How much of the logic is genuinely awkward? If several steps need real code, n8n keeps it in one place.
5. What already exists? If a team is productive on a platform, the cost of moving is rarely justified by the feature difference alone.

Notice that four of these five have nothing to do with the platforms' feature lists. That is deliberate. The features converge every year. The constraints do not.

What this means for your build

If you are choosing between these two for a first automation, the risk is not that you pick wrong. Both are capable, and a workflow that works on one would generally work on the other. The risk is that you build something nobody can maintain, in an account you do not control, with the reasoning undocumented.

Get those three things right and the platform choice becomes reversible. Get them wrong and it will not matter which one you picked.

If you want a second opinion on a specific workflow, whether that is choosing a platform before you start or working out why an existing automation has become expensive, we look at these as part of company automation scoping. You can tell us what you are trying to automate and we will tell you honestly which of the three routes fits, including when the answer is that you do not need us.