Make vs n8n vs a custom integration: five switching thresholds

Make vs n8n is a question that usually gets asked too early. Before you pick a tool, you are settling something bigger: where your business logic lives — in a scenario clicked together inside somebody else’s interface, or in code you own and can test. Both answers can be right, and for a long stretch they are interchangeable. They stop being interchangeable the moment a broken flow starts costing money and nobody in the company can say what it does.

Make vs n8n — what these tools are once you strip out the marketing

Make and n8n are tools for building data flows between applications without writing code: you pick a trigger event, add further steps, and map fields between systems. Make runs only in the vendor’s cloud. n8n is open source software — you can run it yourself, in Docker for example, or use the n8n cloud with servers in Germany. That is the only structural difference that genuinely shifts where responsibility sits; the rest comes down to the interface and the set of ready-made connectors.

Both belong to the iPaaS class. iPaaS (Integration Platform as a Service) is a model in which a cloud vendor hosts the integration platform and answers for updates, availability and security, while the customer builds flows on top of it without maintaining middleware of their own. Alongside iPaaS sit point-to-point connections and the ESB data bus; choosing between those architectures is covered in a separate piece on system integration inside a company. The same class includes Zapier, Microsoft Power Automate, Node-RED and Pipedream; in Polish e-commerce the ready-made integrator role is filled by BaseLinker, Apilo and Sellasist, which a company operating in Poland is likely to already run.

Five switching thresholds after which a no-code scenario stops paying off

A no-code scenario stops paying off when you cross any one of the five thresholds below — not when the tool stops working. Each can be checked inside your company in a single afternoon, with no developer involved.

1. The scenario no longer fits in one person’s head. How to check: ask someone who did not build it to describe, in five minutes, what the flow does and what happens when the seventh step returns an error. If they cannot, you have software without documentation and without tests, just in a different format.
2. Data passes through the flow that you would not put on screen in a meeting room. How to check: write down the fields that actually travel through the scenario, not the ones that were meant to. Personal data, HR documents, payment details and whole customer records turn the conversation from a technical one into a formal one.
3. Somebody is waiting on the result. How to check: establish whether the processing can run in batches, or whether a user is sitting in front of a screen watching a spinner. No-code scenarios run in the vendor’s queue, so the delay is variable and outside your control — disqualifying for interactive processes, irrelevant for a nightly import.
4. You need to reconstruct what happened three months ago. How to check: try to answer today who last changed a scenario, what exactly they changed, and what the state looked like beforehand. If your industry, a corporate client or an auditor requires a change trail and a processing history, you need version control, not an undo button.
5. Cost grows faster than the volume handled. How to check: count the steps per document and multiply by the document count at peak season, not the monthly average. This is not about the price list, which changes several times a year, but about direction: billing per operation rewards simple flows and punishes elaborate ones.

There is also a constraint no tool can do anything about: some older systems on the Polish market have no public, supported interface. At that point “Make vs n8n” is a meaningless question, because the problem is not the platform but the absence of a door on the other side. What is left then is the set of routes for connecting a system without an API, and every one of them moves the maintenance obligation onto you.

What n8n on your own server actually costs

Self-hosting does not remove the cost — it moves it off the vendor’s invoice onto your infrastructure and your team’s time. It is the line item most often left out of tool comparisons, and the one that most often overturns the calculation after a year.

A company that stands the tool up in-house takes on five duties:

• Updates. New versions ship regularly, and putting them off ends in jumping several versions at once and flows that stop working.
• Backups. What counts is not taking the backup but a tested restore — including the encrypted credentials for every connected system.
• Availability. Someone has to know the tool went down at eight on a Saturday evening, and have the access rights to bring it back up.
• Security. An integration tool holds OAuth 2.0 tokens, API keys and passwords to company systems. It is one of the most sensitive pieces of your infrastructure, not an ordinary internal app.
• A person who understands it. Without one, all of the above is theoretical.

Those hours get priced exactly like any other effort in a project — by the same mechanism that determines mobile app development cost or any other build priced by scope. Until you count them, “cloud versus our own server” is a comparison of one column against an empty one.

Where your data physically travels

Your data passes through the tool vendor’s infrastructure and through every third-party connector used in the scenario — including when both integrated systems sit in the same country as your office. With personal data, that is a question for the data processing agreement and the documentation of the specific plan, not for a comparison article.

Check three things in the vendor’s documents before you build the first flow: which region data is processed in, who appears as a subprocessor, and how long scenario execution history is retained together with the content of the records passed through. That last item surprises people most — flow logs can contain whole customer records. This material is information, not legal advice; confirm your company’s obligations with whoever is responsible for data protection.

The hybrid split almost nobody proposes

The best answer is usually not one tool for the whole company but a split: no-code for simple flows, custom code for the one critical process. Slack notifications, copying leads from a form into the CRM, recurring reports and file transfers over SFTP can happily stay in Make or n8n — they are simple, batch-friendly and cheap to rebuild after a failure.

Treat the process your revenue rests on separately. Most often that is inventory synchronisation between the shop, the warehouse and the marketplaces, the order flow, or issuing sales documents. That single flow is worth a custom integration with tests, a queue and logs, even if the rest of the company runs on scenarios. Whichever route you take, every integration needs logs, monitoring, a dead-letter queue, a retry procedure and an owner inside the company — the minimum set covered in more depth under system integration inside a company.

Criterion by criterion: no-code scenario or custom integration

The table does not name a winner, because there isn’t one. It shows which column you are choosing for a specific process — which is why the decision is made per flow, not once for the whole company.

The questions to answer before you pick a tool

Before you compare the Make and n8n interfaces, answer questions about your own company. The answers settle the choice faster than any feature ranking, and they double as ready material for the document you use to write a software project brief.

If the answers show that at least one process has crossed a switching threshold, treat it as a separate project with a scope, not as one more scenario to bolt on. Describe that process and get in touch with us — that is enough to start the conversation with what has to happen between the systems, instead of with the name of a tool.