n8n vs Make vs Zapier dla polskiej małej firmy (co naprawdę liczy się przy wyborze, nie tylko cena)

Zanim ktokolwiek odpowie na pytanie z tytułu, warto zapytać inaczej: nie "które narzędzie jest lepsze", tylko "które narzędzie ogarnie mój konkretny stos i mój konkretny wolumen za rok, a nie tylko dziś". Widziałem firmy, które wybrały Zapiera, bo miał najładniejszy interfejs, a po trzech miesiącach okazało się, że nie ma sensownej integracji z ich systemem księgowym i cała automatyzacja stoi na prowizorycznych webhookach. I widziałem firmy, które postawiły serwer pod n8n do prostego przypadku, który spokojnie ogarnąłby Zapier za ułamek kosztu wdrożenia. Oba błędy biorą się z tego samego: porównywania narzędzi po liczbie integracji w katalogu marketingowym, a nie po tym, czy działają z systemami, które faktycznie stoją w polskiej firmie.

Trzy różne filozofie, nie trzy warianty tego samego

Zapier to narzędzie no-code w najczystszej postaci: łączysz appkę z appką, klikasz, gotowe. Świetne, jeśli używasz popularnych na Zachodzie narzędzi SaaS: Slack, Google Workspace, HubSpot, Shopify. Problem zaczyna się, gdy trzeba połączyć coś z Fakturownią, wFirmą czy Subiektem GT. Tam gotowej integracji często po prostu nie ma, a robienie wszystkiego przez webhooki i "Code by Zapier" zabija sens narzędzia, które miało być no-code.

Make (dawniej Integromat) jest bardziej elastyczny: wizualny edytor scenariuszy, moduł HTTP, obsługa JSON-a bez pisania kodu, routery i filtry, które pozwalają budować logikę bliską programistycznej. To sprawia, że Make częściej daje radę z polskimi API, nawet jeśli oficjalnego konektora nie ma, bo można podpiąć się bezpośrednio pod REST API danego systemu. Cena rośnie skokowo z liczbą operacji, gdzie operacja to praktycznie każdy krok w scenariuszu, nie każdy scenariusz jako całość.

n8n to zupełnie inna kategoria: open source, można postawić na własnym serwerze (self-hosted) albo skorzystać z wersji chmurowej. Ma węzły do popularnych systemów, ale jego prawdziwa siła to węzeł HTTP Request i możliwość pisania własnego kodu JavaScript wewnątrz workflow, gdy gotowego konektora brakuje. To narzędzie dla kogoś, kto traktuje automatyzację poważnie i jest gotów zainwestować trochę więcej czasu na starcie w zamian za pełną kontrolę nad danymi i logiką.

Jak liczą, ile płacisz i gdzie jest pułapka

Model rozliczeń to miejsce, w którym firmy najczęściej się mylą przy wyborze, bo porównują ceny wejściowe, a nie to, jak rachunek rośnie wraz z realnym użyciem.

Zapier: taski

Zapier liczy taski, czyli pojedyncze wykonane akcje. Jeden Zap z pięcioma krokami przy jednym uruchomieniu zużywa kilka tasków, nie jeden. Przy prostych automatyzacjach (nowy lead z formularza trafia do CRM) to nieduży problem. Przy bardziej złożonych flow, gdzie jedno zdarzenie uruchamia dziesięć kroków, limit tasków w tańszych planach potrafi się skończyć znacznie szybciej, niż firma się spodziewa. To pułapka, na którą trafia zwykle po dwóch, trzech miesiącach używania, gdy przychodzi powiadomienie o przekroczeniu limitu w połowie miesiąca rozliczeniowego.

Make: operacje

Make liczy operacje na poziomie kroku scenariusza, podobnie jak Zapier taski, ale scenariusze w Make zwykle da się zbudować bardziej oszczędnie dzięki routerom i agregatorom, które pozwalają obsłużyć wiele rekordów w jednym przebiegu zamiast mnożyć osobne uruchomienia. W praktyce przy podobnym zakresie pracy Make często wychodzi taniej niż Zapier na tym samym wolumenie, ale wymaga trochę więcej myślenia przy projektowaniu scenariusza, żeby nie mnożyć operacji bez potrzeby.

n8n: serwer albo egzekucje w chmurze

Wersja self-hosted n8n jest darmowa w sensie licencji: płacisz za serwer (VPS), na którym stoi, i za czas kogoś, kto to skonfiguruje i utrzyma. Nie ma limitu operacji, bo rozliczenie nie jest oparte na wykonaniach, tylko na infrastrukturze, którą kontrolujesz. Wersja chmurowa n8n rozlicza się od liczby egzekucji workflow, co jest bliższe modelowi Make, ale wciąż zwykle daje więcej "za operację" niż konkurencja, bo pojedyncza egzekucja workflow liczy się jako całość, niezależnie od liczby kroków wewnątrz.

Realny wniosek z wdrożeń: przy niskim wolumenie (kilkadziesiąt, kilkaset zdarzeń miesięcznie) różnica w kosztach między trzema narzędziami jest kosmetyczna i nie powinna decydować. Przy kilku tysiącach operacji miesięcznie zaczyna się liczyć konkretnie, a self-hosted n8n zwykle wygrywa kosztowo, bo koszt serwera nie rośnie liniowo z liczbą wykonań tak jak abonament SaaS.

KSeF i polskie systemy: tu naprawdę się rozstrzyga sprawa

Dla polskiej firmy to jest moment, w którym katalog integracji przestaje mieć znaczenie, a zaczyna się liczyć, czy narzędzie da się w ogóle podłączyć do tego, co realnie stoi w księgowości i magazynie.

Zapier i Make nie mają natywnych, gotowych konektorów do KSeF, Fakturowni w pełnym zakresie, wFirmy czy Subiekta GT na poziomie "przeciągnij i podłącz". W praktyce integracja z tymi systemami odbywa się przez ich API (tam gdzie API w ogóle istnieje i jest udokumentowane) za pomocą modułu HTTP. Make radzi sobie z tym lepiej niż Zapier, bo jego moduł HTTP jest bardziej elastyczny i łatwiej obsłużyć w nim autoryzację, paginację czy specyficzne formaty XML, których KSeF używa. n8n idzie o krok dalej, bo pozwala dopisać własną logikę w kodzie tam, gdzie standardowy request nie wystarcza, na przykład przy podpisywaniu i wysyłce struktur FA(3) do KSeF czy przy obsłudze tokenów sesji.

BaseLinker ma osobną kategorię, bo jako polskie narzędzie do e-commerce sam oferuje rozbudowane API i webhooki, więc każde z trzech narzędzi da radę się z nim zintegrować. Różnica pojawia się dopiero przy skali: przy kilkuset zamówieniach dziennie z BaseLinkera trzeba pilnować limitów operacji w Make lub tasków w Zapierze znacznie bardziej niż w n8n. Firmy z większym wolumenem sprzedaży online, które łączą BaseLinker z fakturowaniem i magazynem, częściej i tak lądują przy dedykowanym wdrożeniu opisanym szerzej przy automatyzacji e-commerce, bo pojedynczy scenariusz w narzędziu no-code przestaje wystarczać.

Dla biur rachunkowych i firm, które automatyzują obieg faktur i przygotowanie do KSeF, sytuacja jest podobna: gotowe konektory rzadko pokrywają cały proces, więc trzeba budować logikę własnoręcznie. To temat, który rozwijamy osobno przy automatyzacji faktur i przy automatyzacji biura rachunkowego, bo tam liczy się nie tylko narzędzie, ale też sposób obsługi wyjątków, gdy faktura ma błędny NIP albo system KSeF chwilowo odrzuca przesyłkę.

RODO i to, gdzie fizycznie leżą dane

To punkt, który firmy pomijają na starcie, a potem wraca przy audycie albo przy pytaniu klienta o umowę powierzenia danych. Zapier historycznie przetwarza dane głównie na infrastrukturze w USA, choć oferuje mechanizmy zgodności z RODO na poziomie umownym. Make ma serwery także w Europie i pozwala wybrać region UE dla organizacji, co dla wielu polskich firm (zwłaszcza tych przetwarzających dane osobowe klientów, nie tylko dane firmowe) jest istotnym argumentem. n8n w wersji self-hosted daje pełną kontrolę: stawiasz serwer w Polsce albo w dowolnym centrum danych w UE i dane fizycznie nigdzie stamtąd nie wychodzą, poza samym workflow, który sam projektujesz.

Dla firmy, która automatyzuje wysyłkę newsletterów, ta różnica bywa nieistotna. Dla firmy, która automatyzuje obieg danych medycznych, kadrowych albo finansowych klientów, wybór regionu hostingu i dostawcy narzędzia powinien być jednym z pierwszych pytań, nie ostatnim.

Próg, przy którym trzeba się przesiąść

Firmy rzadko wybierają narzędzie raz na zawsze i to jest zdrowe podejście. Zapier na start, żeby szybko zautomatyzować pojedynczy proces bez angażowania nikogo technicznego, jest sensownym wyborem. Problem pojawia się, gdy nikt nie pilnuje momentu, w którym ten proces przestaje być pojedynczy i zaczyna obejmować pięć systemów naraz. Wtedy koszt utrzymania rozjeżdżających się automatyzacji w kilku narzędziach robi się wyższy niż koszt jednego uporządkowanego wdrożenia w n8n.

Sygnały, że warto rozważyć zmianę narzędzia, są dość konkretne: powiadomienia o przekraczaniu limitu operacji częściej niż raz na kwartał, coraz więcej "obejść" budowanych ręcznie przez webhooki, bo standardowy moduł czegoś nie ogarnia, albo pytanie od klienta czy audytora o to, gdzie fizycznie przetwarzane są dane. Każdy z tych trzech sygnałów osobno jeszcze nie znaczy, że trzeba migrować. Dwa naraz zwykle znaczą, że tak.

Co bym wybrał, gdybym musiał zdecydować dziś

Dla mikrofirmy z jednym prostym procesem (nowy klient z formularza trafia do arkusza i CRM, powiadomienie na Slacka) nie ma sensu przepłacać czasem na konfigurację n8n. Zapier albo Make załatwi sprawę w godzinę. Dla firmy, która ma już KSeF na horyzoncie, korzysta z polskiego ERP albo systemu do fakturowania i planuje rozwijać automatyzację przez najbliższe dwa lata, stawiałbym na n8n od razu, nawet jeśli pierwszy proces jest prosty. Koszt wejścia jest wyższy, ale unika się kosztownej migracji za rok, kiedy narzędzie no-code się zapcha.

Jest jeszcze trzecia droga, o której firmy rzadziej myślą: podejście hybrydowe. Proste, jednorazowe integracje z popularnymi zagranicznymi SaaS-ami zostają w Make, bo tam gotowe konektory są wygodniejsze. Cała logika dotycząca polskich systemów, faktur i KSeF przechodzi do n8n, gdzie pełna kontrola nad danymi i kodem naprawdę się przydaje. To nie jest rozwiązanie idealne (dwa narzędzia to dwa miejsca do monitorowania), ale bywa rozsądnym kompromisem, zanim firma urośnie na tyle, żeby w pełni skonsolidować się na jednej platformie.