n8n czy Make? Wybór dla polskiej firmy
Porównania tych dwóch platform zwykle sprowadzają się do listy funkcji, a decyzję i tak podejmuje się na podstawie trzech innych rzeczy: sposobu naliczania opłat, tego gdzie leżą dane, i tego czy w firmie jest ktoś techniczny.
Make i n8n robią pozornie to samo: łączą aplikacje, przepuszczają dane i uruchamiają przepływy bez pisania całej aplikacji od zera. Różnice w katalogu gotowych integracji istnieją, ale rzadko przesądzają — bo w polskiej firmie i tak połowa systemów wymaga wywołania API ręcznie. Rozstrzyga co innego.
Model rozliczeń zmienia rachunek bardziej niż cokolwiek innego
To jest różnica, którą warto zrozumieć przed pierwszym testem.
Make nalicza za operacje. Operacja to pojedyncze wywołanie modułu. Przepływ, który pobiera sto rekordów i dla każdego wykonuje cztery kroki, zużywa około czterystu operacji przy jednym uruchomieniu.
n8n w planach chmurowych nalicza za wykonania przepływu. Ten sam przepływ — sto rekordów, cztery kroki — to jedno wykonanie. Liczba kroków w środku nie zmienia rachunku.
Konsekwencja jest bardzo praktyczna: przy przepływach, które przetwarzają dużo rekordów w pętli, Make potrafi zrobić się kosztowny szybciej, niż wynikałoby to z porównania cen planów. Przy kilkudziesięciu prostych, rzadko uruchamianych scenariuszach różnica jest bez znaczenia.
Zanim uznasz to za argument rozstrzygający, policz własny wolumen: ile uruchomień miesięcznie, ile rekordów na uruchomienie, ile kroków na rekord. Cenniki obu platform się zmieniają i warto sprawdzić aktualny, ale sam model naliczania jest stabilny od lat.
Gdzie leżą dane
n8n można postawić u siebie — na własnym serwerze albo w prywatnej chmurze. Dane przetwarzane w przepływie nie opuszczają wtedy twojej infrastruktury, co przy danych osobowych, dokumentacji kadrowej czy dokumentacji medycznej upraszcza całą rozmowę o RODO: nie ma powierzenia przetwarzania podmiotowi zewnętrznemu, bo nie ma podmiotu zewnętrznego.
Make jest wyłącznie usługą chmurową. To nie dyskwalifikuje — dostawca oferuje umowę powierzenia i wybór regionu przetwarzania w Unii — ale oznacza, że powierzenie trzeba udokumentować i uwzględnić w rejestrze czynności.
Warto tu być uczciwym: self-hosting nie jest darmowy. Ktoś musi utrzymywać serwer, pilnować aktualizacji i kopii zapasowych. Jeśli w firmie nie ma takiej osoby ani zewnętrznego wsparcia, „dane u nas” bywa iluzją bezpieczeństwa, a nie bezpieczeństwem.
Uwaga licencyjna: n8n nie jest oprogramowaniem open source w rozumieniu OSI. Kod jest dostępny na licencji ograniczającej użycie komercyjne w modelu konkurencyjnym wobec producenta. Dla firmy, która używa go do własnych procesów, nie ma to znaczenia — dla firmy, która chciałaby na tym oprzeć własną usługę sprzedawaną klientom, ma.
Polskie integracje i tak przejdą przez API
To jest część, której nie ma w żadnym porównaniu anglojęzycznym. Systemy, z których faktycznie korzystają polskie firmy — programy do fakturowania, lokalne systemy ERP, platformy sprzedażowe, operatorzy wysyłki i bramki płatnicze — rzadko mają gotowy moduł w którejkolwiek z platform. Katalogi rosną, więc warto sprawdzić przed decyzją, ale planowo zakładaj, że część połączeń zbudujesz na zwykłych wywołaniach HTTP.
To wyrównuje szanse. Oba narzędzia mają uniwersalny moduł HTTP i oba poradzą sobie z REST-owym API i uwierzytelnianiem tokenem. Różnica pojawia się przy tym, co zrobisz z odpowiedzią: n8n daje węzeł z kodem w JavaScripcie lub Pythonie, Make ma bogaty zestaw funkcji wbudowanych, ale przy bardziej złożonych przekształceniach szybciej robi się nieczytelnie.
Praktyczny wniosek: jeśli twoja lista systemów to głównie mainstreamowy SaaS (Google Workspace, Microsoft 365, popularne CRM-y), przewaga katalogu Make jest realna. Jeśli dominują systemy polskie i branżowe, katalog przestaje być argumentem.
Kiedy które
| Sytuacja | Rozsądny wybór |
|---|---|
| Nikt w firmie nie programuje, potrzeba pierwszej automatyzacji w tydzień | Make |
| Dane osobowe wrażliwe, wymóg trzymania ich we własnej infrastrukturze | n8n self-hosted |
| Duże wolumeny rekordów w pętlach | n8n |
| Kilkanaście prostych scenariuszy, mały wolumen | Make |
| Jest dział IT albo stałe wsparcie techniczne | n8n |
| Przepływy z modelami językowymi i własną logiką na wyjściu | n8n |
| Zespół nietechniczny ma sam wprowadzać zmiany | Make |
Jeśli twoja sytuacja pasuje do wierszy z obu kolumn, to nie jest problem — to znak, że wybór nie jest krytyczny i można zdecydować na podstawie tego, z czym wygodniej pracuje osoba, która będzie to utrzymywać.
Czego wybór narzędzia nie rozstrzyga
Największe koszty w projektach automatyzacji nie wynikają z platformy. Wynikają z tego, że proces nie był ustalony, że nikt nie zdefiniował, co ma się stać przy błędzie, i że po wdrożeniu nikt nie sprawdzał logów. Zły proces zautomatyzowany w n8n i zły proces zautomatyzowany w Make kosztują tyle samo — czyli więcej niż przed automatyzacją.
Dlatego przy pierwszym projekcie zwykle odradzam długie porównywanie platform. Wybierz tę, którą łatwiej obsłuży osoba odpowiedzialna, zbuduj jeden proces do końca i dopiero wtedy oceniaj. Migracja pojedynczego przepływu między tymi narzędziami to kwestia dni, a nie tygodni — koszt zmiany zdania jest niski.
Jeśli chcesz to przegadać na konkretnym przypadku, konsultacja trwa godzinę i kosztuje od 300 zł netto. Jeśli decyzja jest już podjęta i chodzi o samo wdrożenie, opisałem tam przebieg, zakres i to, co zostaje po twojej stronie: kod, konta i dostępy.