n8n vs custom code (and Make): where each one breaks

Use n8n when you need to connect existing tools quickly and your team is comfortable with a technical, visual builder. Use Make when the people building automations are not developers. Use custom code when the workflow carries critical business logic, runs at high volume, needs tests and code review, or becomes part of a product your customers use. Most well-run companies end up with a mix: custom code at the core, n8n or Make around the edges.

Plenty of articles pitch one side. This one compares three options on what matters to a decision maker: pricing models as published on 6 November 2026, where each option breaks, and where your data lives.

The short version

Pricing, checked on 6 November 2026

n8n

From n8n's pricing page, with yearly billing. Prices are shown in euros; the page may display another currency depending on where you are.

An execution is one complete run of a workflow, regardless of how many steps it has or how much data it processes. Hosted plans keep data in the EU, in Frankfurt.

The Community Edition is free to self-host, but it is not open source in the OSI sense. It ships under the Sustainable Use License, which allows use "only for your own internal business purposes or for non-commercial or personal use". Some features are reserved for the Enterprise licence.

Make

Make now bills in credits rather than operations. Its pricing page states that the free plan includes 1,000 credits per month, that most actions consume one credit, and that routers and error handlers consume none. Some AI features consume more. Data transfer is capped at 5 GB per 10,000 credits. Paid plan prices (Core, Pro, Teams, Enterprise) depend on the credit volume you select on that page.

Why the billing unit matters more than the sticker price

Take a ten-step workflow (read an order, look up the customer, create the invoice, send an email and so on) that runs 3,000 times a month:

• on Make, about 30,000 credits a month, since each action uses one;
• on hosted n8n, 3,000 executions, beyond Starter and inside Pro;
• in custom code, no per-run cost at all: you pay for the build, hosting and maintenance.

This is an order of magnitude derived from each vendor's public rules, not a quote. The pattern is what matters: Make gets expensive with long workflows, hosted n8n with frequent ones, and custom code stays flat as volume climbs.

Where each option breaks

Make breaks on complexity and volume

• Iterating over hundreds of rows burns credits on every pass, so the bill follows data volume, not business value.
• Large visual scenarios become hard to read. After a while, nobody dares to touch them.
• There is no self-hosting. If policy requires data to stay on your infrastructure, Make is out.

n8n breaks on operations and governance

• Self-hosting means someone owns the server, upgrades, backups, queue workers and monitoring. Without that person, the free option becomes a liability.
• Complex workflows tend to fill up with Code nodes. You end up writing code anyway, but without tests, review or a usable diff history.
• The licence limits how you use it. Building n8n into a product you sell needs a commercial agreement.

Custom code breaks on speed and entry cost

• Wiring two SaaS tools together in code takes longer and costs more upfront than dragging two nodes onto a canvas.
• Every change goes through a developer. If the process changes weekly, that is friction.
• Poorly documented code creates vendor dependence. Rights to the code are set case by case in the contract; see our guide on who owns custom software source code.

Hosting, data protection and security

Automations move personal data between services: customers, staff, leads. Whatever the tool, ask three questions.

1. Where is data stored? Hosted n8n: Frankfurt. Make offers data zones in the US (US1, US2) and the EU (EU1, EU2), and notes that choosing an EU zone does not mean every request stays in the EU, as some AI features are processed in the US. Pick the zone when you create the organisation.
2. Who holds the credentials? Each connection stores an access token. Scope every token to the minimum it needs.
3. What gets logged? Execution history often keeps the payloads it processed. Set a retention period.

If you serve European customers, the GDPR applies wherever your company is based. Our GDPR checklist for business applications and our guide to hosting a business application in Europe cover the obligations that stay with you.

Which option for which situation

On that last case, our article on Airtable limits describes the point where a no-code database stops being enough.

The hybrid that works best

"Automation tool or code" is usually the wrong question. The most robust setup:

• a custom application holds the reference data and the business rules, tested and version-controlled;
• it exposes a documented API;
• n8n or Make connects the peripheral tools around it: email, calendar, shared spreadsheets, notifications.

A broken Make scenario then never corrupts an invoice, and business teams keep control of the simple automations they change often.

Five questions to settle it

Answer these for each workflow, not for your company as a whole. The same business can rightly run one process on Make and another in code.

1. What does an error cost? A missed Slack notification costs nothing. A wrong invoice, a double shipment or a lost lead costs money and trust. The higher the cost, the stronger the case for tested code.
2. How often will it change? Logic that changes every week belongs where the business team can edit it. Logic that changes twice a year can live in code.
3. How many runs, how many steps? Multiply them and apply each vendor's billing rule before you commit, then do it again at three times today's volume.
4. Who maintains it in two years? If the answer is a single person, the tool matters less than documenting what that person built.
5. Do customers touch it? Anything your customers see or rely on is part of your product, and deserves the same engineering standards as the rest of it.

Common mistakes

• Choosing the tool before mapping the process. Write down what should happen, who gets notified and what happens on failure.
• Silent failures. An automation that fails without an alert is worse than a manual task. Alert on every error.
• Putting pricing logic in a visual scenario. Nobody will find it the day it needs to change.
• Underestimating self-hosting. An n8n server without tested backups is a single point of failure.
• No exit plan. Export your workflows regularly. An undocumented automation leaves with its author.

What the custom part costs

There is no single price for turning automations into an application: it depends on screens, business rules, integrations and data to migrate. Our guide to custom business application cost breaks down the line items. Compare over several years: subscriptions, credits or servers plus the time spent watching and restarting workflows on one side; build, hosting and maintenance on the other.

How you pay matters as much as how much. At LPR Studio there are three options: a fixed-price build, a subscription where you pay a monthly fee instead of paying for development, or a SaaS model where the tool becomes a product we publish. We never bill by the hour. Our comparison of a software subscription vs an upfront build helps you choose.

If your automations have started to carry your business, the real question is no longer "n8n or Make" but "which part should become an application". Within 5 business days, we present a free prototype of that application on a video call, with the automations that would stay around it. It is a demonstration, neither paid for nor delivered. Our guide to the differences between a prototype, an MVP and a POC explains what you would see.