Paweł Lipowczan ·
n8n or Make? Choosing for a company in Poland
Comparisons of these two platforms usually come down to a feature list, yet the decision is made on three other things: how usage is charged, where the data lives, and whether anyone in the company is technical.
Make and n8n seem to do the same thing: they connect applications, pass data between them and run workflows without writing a whole application from scratch. The differences in their catalogues of ready-made integrations exist, but they rarely settle anything, because in a Polish company half the systems need their API called by hand anyway. Something else decides.
How they charge changes the bill more than anything else
This is the difference worth understanding before your first test.
Make charges for operations. An operation is a single call to a module. A workflow that fetches a hundred records and runs four steps for each uses about four hundred operations in a single run.
n8n’s cloud plans charge for workflow executions. The same workflow (a hundred records, four steps) is one execution. The number of steps inside doesn’t change the bill.
The consequence is very practical. For workflows that process many records in a loop, Make can become expensive faster than a comparison of plan prices would suggest. For a few dozen simple scenarios that run rarely, the difference doesn’t matter.
Before you treat this as the deciding argument, work out your own volume: how many runs a month, how many records per run, how many steps per record. Both platforms change their price lists, so check the current one, but the charging model itself has been stable for years.
Where the data lives
n8n can run on your own infrastructure: your own server or a private cloud. The data processed in a workflow then never leaves your infrastructure. With personal data, HR records or medical records, that simplifies the whole GDPR conversation: there is no processing entrusted to an outside party, because there is no outside party.
Make is a cloud service only. That doesn’t rule it out, since the provider offers a data processing agreement and a choice of processing region in the EU. It does mean the processing has to be documented and entered in your record of processing activities.
It is worth being honest here: hosting it yourself isn’t free. Someone has to maintain the server and look after updates and backups. If the company has no such person and no outside support, “our data stays with us” can be an illusion of security rather than security.
A note on the licence: n8n isn’t open source in the OSI sense. The code is available under a licence that restricts commercial use in competition with the vendor. For a company using it for its own processes, that makes no difference. For a company that wants to build a service on it and sell that to its clients, it does.
Polish integrations will go through the API anyway
This is the part no English-language comparison covers. The systems Polish companies actually use (invoicing software, local ERP systems, sales platforms, couriers and payment gateways) rarely have a ready-made module on either platform. The catalogues keep growing, so check before you decide, but plan on building some connections with plain HTTP calls.
That levels the field. Both tools have a general-purpose HTTP module, and both handle a REST API with token authentication. The difference shows in what you do with the response: n8n gives you a code node in JavaScript or Python, while Make has a rich set of built-in functions that become hard to read sooner once the transformations get complex.
The practical conclusion: if your list of systems is mostly mainstream SaaS (Google Workspace, Microsoft 365, the popular CRMs), Make’s catalogue is a real advantage. If Polish and industry-specific systems dominate, the catalogue stops being an argument.
Which one, when
| Situation | Sensible choice |
|---|---|
| Nobody in the company writes code, and the first automation is needed within a week | Make |
| Sensitive personal data that must stay on your own infrastructure | n8n, self-hosted |
| Large volumes of records processed in loops | n8n |
| A dozen or so simple scenarios, low volume | Make |
| There is an IT department or ongoing technical support | n8n |
| Workflows with language models and your own logic on the output | n8n |
| A non-technical team is meant to make changes itself | Make |
If your situation matches rows in both columns, that isn’t a problem. It means the choice isn’t critical, and you can decide on what the person who will maintain it finds more comfortable to work with.
What the choice of tool doesn’t decide
The biggest costs in automation projects don’t come from the platform. They come from a process that was never settled, from nobody defining what should happen when something fails, and from nobody checking the logs after launch. A bad process automated in n8n and a bad process automated in Make cost the same, which is more than before the automation.
That is why, for a first project, I usually advise against a long comparison of platforms. Choose the one the person responsible will find easier to run, build one process all the way through, and only then judge. Moving a single workflow between these tools takes days, not weeks, so changing your mind costs little.
If you want to talk it through on a specific case, a consultation takes an hour and costs €75 net. If the decision is made and it is about the implementation itself, I describe there how it runs, its scope, and what stays on your side: the code, the accounts and the access.
All prices are net of VAT. VAT is charged under EU rules, and a company in another EU country is invoiced under the reverse charge.