n8n vs Make vs Zapier — które narzędzie do automatyzacji wybrać

Naszym zdaniem w większości firm to porównanie jest po prostu nieistotne — i piszemy to na początku artykułu, który jest porównaniem. O tym, czy automatyzacja zadziała, decyduje nie wybór między n8n, Make i Zapierem, tylko to, czy ktoś wcześniej opisał proces zdaniami: co go uruchamia, jakie decyzje zapadają po drodze, co jest wyjątkiem, a co regułą. Firmy, które wybierają narzędzie przed opisaniem procesu, i tak zmieniają je po pół roku — nie dlatego, że trafiły na złe narzędzie, tylko dlatego, że wybierały, nie wiedząc jeszcze, co mają zautomatyzować. Zaznaczamy uczciwie: to obserwacja z naszych rozmów, a nie wynik badania z próbą i metodą, i tak należy ją czytać.

Antywzorzec wygląda za każdym razem podobnie. Firma zaczyna od tabelki porównawczej, zakłada konto tam, gdzie najłatwiej kliknąć, składa pierwszy przepływ w tydzień i jest zadowolona. Przy trzecim okazuje się, że proces ma na przykład cztery ścieżki zamiast jednej, dwa wyjątki, o których nikt nie wspomniał, i jedną osobę, która co miesiąc robi jeden krok po swojemu, bo tak zawsze było. Narzędzie dostaje wtedy etykietę „nie nadaje się”, zaczyna się szukanie następnego, a cała praca idzie od zera. Uważamy, że to nie jest wada żadnej z trzech platform, tylko skutek odwróconej kolejności — dlatego pierwsze pytanie w naszych projektach nie brzmi „n8n czy Make”, tylko „pokaż, jak ten proces wygląda dziś, krok po kroku”.

Odradzamy wprost: nie zakładaj konta, dopóki nie potrafisz opisać procesu na jednej kartce. Automatyzacja nieopisanego procesu utrwala bałagan i dokłada do niego warstwę, której po pół roku nikt już nie rozumie — z tego stanu wychodzi się drożej niż z ręcznej roboty, bo trzeba najpierw odtworzyć logikę z węzłów. Powiemy też, czego nie wiemy. Nie mamy opublikowanego wdrożenia z rachunkiem przed i po, więc nie znajdziesz tu ani jednej liczby o tym, ile jednostek zużywa „typowy” przepływ; podalibyśmy ją zmyśloną, a zmyślona liczba w rachunku kosztów jest gorsza od jej braku, bo wygląda na dowód. Nie zweryfikowaliśmy również regionów przetwarzania danych ani list podprocesorów Make i Zapiera — dlatego w tabeli poniżej piszemy „sprawdź to u dostawcy”, zamiast udawać, że wiemy.

Jednym zdaniem: Zapier jest najprostszy i ma najszerszy katalog gotowych połączeń z popularnymi aplikacjami, Make daje wizualny edytor, w którym wygodnie buduje się rozgałęzione scenariusze z przetwarzaniem danych, a n8n jest narzędziem dla zespołów, które chcą pisać własny kod i trzymać całą maszynerię na swoim serwerze. Ta różnica ciągnie się przez wszystkie pozostałe kryteria: sposób naliczania opłat, miejsce przechowywania danych, próg wejścia i to, kto w firmie utrzyma automatyzację, kiedy przestanie działać. Wybór rzadko rozstrzyga sama lista integracji — częściej rozstrzyga to, czy jest ktoś, kto potrafi zajrzeć do logów, i czy dane przechodzące przez przepływ mogą leżeć w chmurze zewnętrznego dostawcy. Poniższa tabela ma więc naszym zdaniem sens dopiero po opisaniu procesu; wcześniej jest lekturą, a nie decyzją.

W tej tabeli świadomie nie ma ani jednej stawki i uważamy, że każde porównanie tych narzędzi powinno tak wyglądać. Cenniki całej trójki bywają zmieniane w trakcie roku — zmieniają się nazwy planów, progi jednostek, to, co wchodzi w plan podstawowy, i sposób naliczania dodatkowych wykonań. Liczba przepisana z artykułu sprzed kilku miesięcy nie jest więc pomocą, tylko cichą pułapką: decyzję podejmujesz na nieaktualnym rachunku, a potem obwiniasz narzędzie za wynik, który sam sobie policzyłeś źle. Jedyne wiarygodne źródło cen i limitów to strona dostawcy: sprawdź je u n8n, Make i Zapiera w dniu, w którym podejmujesz decyzję, i przelicz na swoim realnym wolumenie, a nie na przykładzie z cennika. To samo dotyczy list integracji — katalogi łączników rosną i zmieniają zakres, więc obecność konkretnego ERP czy systemu magazynowego potwierdzaj u źródła, a nie w zestawieniu, także w naszym.

Domyślnie wybieramy n8n i nie chowamy się tu za „to zależy”. Powody są praktyczne, nie ideowe. Po pierwsze, rozliczenie za wykonanie całego przepływu nie karze nas za to, że proces ma piętnaście kroków zamiast trzech — możemy rozbić logikę na czytelne, małe fragmenty i nie oglądać się przy każdym z nich na licznik, a czytelność przepływu to jedyna rzecz, która ratuje go po roku. Po drugie, kod jest w n8n normalnym elementem pracy, a nie obejściem ograniczeń, więc integracja z API klienta nie wymaga sztuczek, które później nikt nie umie odtworzyć. Po trzecie, to jedyne narzędzie z tej trójki, które da się postawić na serwerze klienta, więc rozmowa o danych osobowych nie kończy się wyborem między wygodą a zgodnością.

Od tego domyślnego wyboru odchodzimy i robimy to często, bo n8n ma realną cenę, której nie widać na fakturze: najwyższy próg wejścia w całej trójce. Rezygnujemy z niego, gdy po stronie klienta nie ma nikogo, kto po zakończeniu wdrożenia otworzy logi i zrozumie, co widzi, a klient nie chce umowy na utrzymanie. W takiej sytuacji własna instancja nie jest oszczędnością, tylko odroczoną awarią: przepływ przestaje działać, nikt tego nie zauważa przez trzy tygodnie, a wina spada na automatyzację jako pomysł. Poniżej cztery warunki, przy których świadomie wybieramy co innego niż nasze domyślne.

• Proces ma kilka kroków, spina popularne aplikacje SaaS i klient chce rozwijać go dalej sam — wtedy Zapier, bo najniższy próg wejścia jest w tym układzie zaletą, a nie kompromisem; przepływ, którego właściciel nie potrafi sam poprawić, umiera przy pierwszej zmianie w firmie.
• Zespół klienta pracuje już w Make i zna iteratory oraz agregatory — zostajemy w Make. Odradzamy migracje robione „bo lepiej”: przepisanie działających scenariuszy wyłącznie dla spójności technologicznej to koszt bez zwrotu, a do tego kasuje wiedzę, którą ludzie zdążyli zbudować.
• Nie ma administratora ani partnera technicznego z umową na reakcję — wybieramy wariant chmurowy zamiast self-hostingu, nawet jeśli oznacza to umowę powierzenia i mniej kontroli nad danymi. Serwer bez opiekuna to ryzyko, którego nie umiemy obronić przed klientem.
• Przepływ ma powstać w tydzień i posłużyć do sprawdzenia hipotezy biznesowej — bierzemy najszybsze narzędzie, jakie zespół zna, i z góry mówimy, że to prototyp do wyrzucenia. Prototyp, którego nie wolno wyrzucić, nie jest prototypem, tylko produkcją bez testów.

Przy okazji rozbrójmy przekonanie, które najczęściej pcha firmy w stronę własnego serwera: self-hosting nie jest tańszy z definicji. Znika opłata za jednostki, ale pojawia się maszyna, aktualizacje, kopie zapasowe i ich testowe odtworzenie, monitoring oraz czyjś telefon o drugiej w nocy. Naszym zdaniem własna instancja broni się z dwóch powodów — bo dane nie mogą wyjść na zewnątrz albo bo wolumen jest na tyle duży, że rozliczanie za jednostki przestaje mieć sens — i tylko z nich. Jeśli jedynym argumentem jest „nie chcemy płacić abonamentu”, zwykle odradzamy, bo abonament zamienia się wtedy w niepoliczony czas ludzi, który i tak ktoś zapłaci.

Dane leżą tam, gdzie stoi silnik automatyzacji. W Make i Zapierze to zawsze infrastruktura dostawcy: treść wiadomości, załączniki, dane klientów i faktury przechodzą przez jego serwery i bywają tam przechowywane w logach wykonań. W n8n uruchomionym na własnym serwerze te same dane nie opuszczają twojej infrastruktury — nadal jednak ktoś musi ten serwer aktualizować, szyfrować kopie i pilnować dostępów. To nie jest różnica ideologiczna, tylko formalna: przy chmurze zewnętrznej potrzebujesz umowy powierzenia przetwarzania, wpisu w rejestrze czynności, wiedzy o podprocesorach i o tym, czy dane trafiają poza Europejski Obszar Gospodarczy. Przy self-hostingu te obowiązki nie znikają — przechodzą w całości na ciebie. Uważamy, że to pytanie trzeba zadać na pierwszym spotkaniu, a nie po demie: zmiana narzędzia po tym, jak zespół zbudował dziesięć przepływów, kosztuje wielokrotnie więcej niż jedno niewygodne pytanie na starcie. Poniższe sytuacje zwykle przechylają decyzję w stronę własnej instancji:

• przez przepływ przechodzą dane osobowe szczególnej kategorii, dokumentacja medyczna albo akta spraw
• obowiązuje cię tajemnica zawodowa lub umowa z klientem ograniczająca podwykonawców przetwarzania
• automatyzacja dotyka systemu, który i tak stoi w twojej serwerowni i nie ma publicznego API
• wolumen jest na tyle duży, że rozliczanie za pojedyncze jednostki przestaje mieć sens ekonomiczny
• chcesz uruchomić model językowy lokalnie i nie wysyłać treści do zewnętrznego API

Trzeba tu rozbroić drugi mit: że self-hosting sam z siebie załatwia RODO. Nie załatwia. Zgodność to nie jest właściwość serwera, tylko zestaw obowiązków — analiza ryzyka, kontrola dostępów, retencja logów, plan reakcji na incydent — a przeniesienie danych do własnej szafy przenosi te obowiązki na ciebie, zamiast je usuwać. Powiemy więcej i będzie to niepopularne: nieaktualizowana instancja z danymi osobowymi na serwerze w firmie jest naszym zdaniem gorszym rozwiązaniem niż chmura zewnętrznego dostawcy z podpisaną umową powierzenia, bo w chmurze podatności łata ktoś zawodowo, a w takiej szafie nie łata ich nikt. Dlatego self-hosting proponujemy tylko wtedy, gdy razem z nim proponujemy również opiekę nad nim.

Osobny powód, by zadać pytanie o dane wcześnie, to faktury. Od 1 lutego 2026 KSeF obowiązuje przedsiębiorców, których sprzedaż z VAT przekroczyła w 2025 roku 200 mln zł, a od 1 kwietnia 2026 pozostałych, w tym MSP (Ministerstwo Finansów, ksef.podatki.gov.pl). Do 31 grudnia 2026 trwa okres przejściowy: można wystawiać faktury poza systemem, dopóki miesięczna sprzedaż z takich faktur nie przekroczy 10 000 zł brutto — po przekroczeniu progu wystawiasz w KSeF, poczynając od faktury, która go przekroczyła (Ministerstwo Finansów). Od 1 stycznia 2027 obowiązek obejmie także najmniejszych podatników wykluczonych cyfrowo, czyli wystawiających faktury do 450 zł przy sprzedaży miesięcznej do 10 000 zł (Ministerstwo Finansów). Jeśli automatyzacja ma dotykać faktur, przez przepływ zaczną przechodzić dokumenty księgowe, a pytanie o to, czyje serwery je widzą, przestaje być akademickie.

Koszt policzysz dopiero wtedy, gdy przeliczysz swój proces na jednostki rozliczeniowe każdego narzędzia — bo każde liczy co innego. Weź umowny przykład: przepływ z wyzwalaczem i dziesięcioma krokami, uruchamiany tysiąc razy w miesiącu. W n8n to tysiąc wykonań przepływu, bo liczy się uruchomienie, a nie to, co dzieje się w środku. W Make to około dziesięciu tysięcy operacji, bo każdy moduł, który się wykonał, liczy się osobno — a jeśli w środku jest iterator przechodzący po pozycjach zamówienia, mnożnik rośnie dalej. W Zapierze to około dziesięciu tysięcy zadań, bo liczą się wykonane akcje. Ten przykład nie mówi nic o stawkach, tylko o mechanice: ten sam proces daje trzy różne krzywe kosztu i to one, a nie cena jednostki, decydują przy skalowaniu.

Najczęstszy błąd w tym rachunku to porównywanie stawek zamiast liczby jednostek — i uważamy, że odpowiada on za większość rozczarowań pierwszą dużą fakturą. Stawki między narzędziami różnią się zauważalnie, ale liczba jednostek zużytych przez ten sam proces potrafi różnić się o rząd wielkości, bo jedno narzędzie liczy uruchomienie, a drugie każdy krok w środku. Dlatego odradzamy podejmowanie decyzji na podstawie zestawień „cena za tysiąc jednostek”: to porównywanie liczb, które nie znaczą tego samego. Zużycie jednostek podbijają najczęściej te same rzeczy:

• iteratory i pętle po pozycjach — jedno zamówienie z dwudziestoma liniami to dwadzieścia przebiegów fragmentu przepływu
• odpytywanie zamiast webhooków — przepływ budzi się co kilka minut, także wtedy, gdy nie ma nic nowego
• filtry ustawione za późno — dane odrzucasz dopiero po tym, jak kilka kroków już się wykonało i policzyło
• ponawianie po błędach — nieudane przebiegi zwykle również zużywają jednostki
• budowanie i testowanie — każdy przebieg testowy w trakcie prac liczy się tak samo jak produkcyjny

Przy n8n uruchomionym u siebie rachunek nie znika, tylko zmienia adresata. Zamiast faktury od dostawcy pojawia się serwer albo maszyna w chmurze, aktualizacje, kopie zapasowe, monitoring i czyjś czas, kiedy o drugiej w nocy przestaje działać integracja z magazynem. Uczciwe porównanie zestawia więc trzy pozycje: opłatę za narzędzie, koszt utrzymania i koszt godzin ludzi, którzy dziś klikają to ręcznie. Ta trzecia pozycja jest jedyną, którą policzysz sam i od razu: wystarczy zmierzyć, ile minut zajmuje jedno przejście procesu i ile razy w miesiącu ktoś je wykonuje. Naszym zdaniem to od niej należy zaczynać, bo jest jedyną liczbą w całym rachunku, której nikt ci nie zmieni z kwartału na kwartał. I znów: konkretnych stawek szukaj u dostawcy w dniu decyzji — każda przepisana tutaj zdezaktualizowałaby się szybciej niż ten akapit.

Te, których nie widać przy dziesięciu przepływach. Narzędzie, które na starcie wygląda tanio, potrafi zaskoczyć przy stu — i nie chodzi wyłącznie o arytmetykę jednostek. Przy stu przepływach pojawia się rzeczywistość, której przy dziesięciu nie ma: ktoś musi codziennie przeglądać błędy, ktoś musi wiedzieć, który przepływ dotyka której bazy, tokeny wygasają w różnych momentach, a zmiana w jednym miejscu ma nieoczywiste skutki w trzech innych. Uważamy, że to jest prawdziwy próg skalowania automatyzacji — próg opieki, nie próg cennika — i że firmy mylą te dwie rzeczy, bo tylko jedna z nich jest widoczna na fakturze. Liczby „dziesięć” i „sto” są tu ilustracją mechaniki, a nie zmierzoną granicą; własnych danych o tym progu nie mamy i nie udajemy, że mamy.

• przebiegi testowe i nieudane wykonania — zużywają jednostki dokładnie tak samo jak produkcyjne
• drugie środowisko do prób, jeśli nie chcesz sprawdzać zmian na żywym procesie
• czas na regularny przegląd błędów — przy dużej liczbie przepływów to osobne zadanie, a nie coś „przy okazji”
• wymiana tokenów i kluczy, rozłożona nierównomiernie w czasie i rzadko przez kogokolwiek zapisana
• wiedza zamknięta w głowie autora przepływu, która wychodzi z firmy razem z nim

Druga pozycja ukryta w rachunku to migracja i powiemy o niej bez owijania: przeniesienie automatyzacji z jednej platformy na drugą to praktycznie napisanie wszystkiego od nowa. Nie ma tu pliku do zaimportowania — wyzwalacze, mapowania, obsługa błędów i sposób reprezentacji danych są w każdym narzędziu inne, więc przenosi się wyłącznie wiedza o procesie, a ta i tak siedzi w głowach ludzi. Dlatego odradzamy strategię „weźmy najprostsze, potem się przeniesiemy”: kończy się zwykle tak, że firma płaci dwa razy za tę samą logikę, a drugi raz drożej, bo pierwotny autor już nie pracuje i trzeba najpierw odtworzyć, co właściwie robił ten przepływ.

Nie potrafimy podać, ile taka migracja kosztuje w godzinach, bo nie mamy własnego, opisanego przypadku, a cudzych liczb nie przepisujemy. Podamy więc regułę, którą stosujemy sami: zanim proces trafi do narzędzia, opisujemy go w dokumencie niezależnym od narzędzia — wyzwalacz, warunki, mapowania pól, obsługa wyjątków, właściciel. Ten dokument jest jedyną częścią pracy, która przeżywa zmianę platformy, i naszym zdaniem to on, a nie sam przepływ, jest właściwym produktem wdrożenia. Klient, który ma taki opis, może zmienić narzędzie w kilka tygodni; klient, który ma tylko działający scenariusz, zaczyna od zera.

Rozbrojenia wymaga jeszcze jedno przekonanie: że no-code jest tańsze od kodu. Jest tańsze na starcie i to akurat łatwo sprawdzić — pierwszy działający przepływ powstaje w godziny, a nie w tygodnie. Nie wynika z tego jednak, że jest tańsze w utrzymaniu: scenariusz z kilkudziesięcioma węzłami, bez testów, historii zmian i środowiska testowego, bywa droższy w opiece niż mała usługa w Node.js, którą można cofnąć jednym ruchem. Uważamy, że linia podziału nie przebiega między „no-code” a „kodem”, tylko między procesem, który wolno zepsuć na godzinę, a procesem, którego zepsuć nie wolno — i to ona powinna decydować, gdzie sięgasz po które narzędzie.

Żadne z tych narzędzi nie wystarczy, gdy logika procesu przestaje mieścić się na jednym ekranie. Wszystkie trzy pozwalają wstawić własny kod, ale w różnym stopniu: n8n traktuje kod jak normalny element przepływu i pozwala wołać własne API bez obchodzenia ograniczeń, Make stawia na funkcje w mapowaniu, moduł HTTP i własne aplikacje, a Zapier daje krok z kodem w ograniczonym środowisku — dobry przy przekształcaniu danych, słaby przy budowaniu logiki biznesowej. Granica przebiega tam, gdzie zaczynasz potrzebować rzeczy oczywistych dla programisty: testów, historii zmian, przeglądu kodu, środowiska testowego i możliwości cofnięcia wdrożenia jednym ruchem. Uważamy, że tę granicę przekracza się prawie zawsze nieświadomie — nikt nie podejmuje decyzji „od dziś budujemy system”, po prostu dokłada dwudziesty węzeł. Sygnały, że proces przerósł narzędzie no-code, są dość powtarzalne:

• scenariusz ma kilkadziesiąt węzłów i nikt poza autorem nie potrafi go przeczytać
• zmiana w jednym miejscu regularnie psuje coś w drugim, a nie ma testów, które to wychwycą
• potrzebujesz transakcyjności: albo wykonują się wszystkie kroki, albo żaden
• przetwarzasz dane wsadowo w tysiącach rekordów, a nie zdarzeniami po jednym
• proces ma być produktem dla klientów, z własnym interfejsem i umową na dostępność

W takich przypadkach tańsza w utrzymaniu bywa zwykła usługa napisana w Node.js albo TypeScripcie, z repozytorium, testami i wdrożeniem na Vercelu — a narzędzie no-code zostaje tam, gdzie jest najmocniejsze: przy szybkim spinaniu gotowych aplikacji. Częsty i sensowny układ to podział ról: no-code obsługuje brzegi procesu, czyli formularze, powiadomienia i przerzucanie danych między aplikacjami, a własny kod trzyma tę część logiki, na której naprawdę zależy księgowości albo magazynowi. Odradzamy natomiast przepisywanie na kod całego procesu tylko dlatego, że jeden jego fragment przerósł narzędzie — najdroższe wdrożenia, jakie widzieliśmy w ofertach, to takie, w których ktoś zamienił sprawnie działające spinanie aplikacji na własny system, bo tak wygodniej było go wycenić.

Podobnie wygląda to przy sztucznej inteligencji. Jeśli przez przepływ mają przechodzić polskie teksty, których nie chcesz wysyłać do zewnętrznego API, alternatywą jest model uruchomiony lokalnie. Bielik to otwarty polski duży model językowy fundacji SpeakLeash, trenowany na zasobach Akademickiego Centrum Komputerowego Cyfronet AGH — na superkomputerach Athena i Helios, w ramach grantów PLGrid (SpeakLeash, ACK Cyfronet AGH). Rodzina obejmuje warianty od 1,5 do 11 miliardów parametrów: Bielik 11B v3 z sierpnia 2025 jest wielojęzyczny i obsługuje ponad 20 języków, Bielik 4.5B v3 z maja 2025 to wariant kompaktowy i polskojęzyczny, a od stycznia 2026 dostępny jest też Bielik Guard — klasyfikator bezpieczeństwa dla polszczyzny w wariantach 0,1B i 0,5B (SpeakLeash). Całość wydano na licencji Apache 2.0, więc wolno jej używać także komercyjnie. Nie podamy tu ani wymagań sprzętowych, ani wyników jakościowych, bo ich nie zmierzyliśmy na własnych danych — a deklaracja bez pomiaru jest sprzedażą, nie ekspertyzą. Odradzamy również decydowanie o modelu lokalnym na podstawie cudzych zestawień: to, jak model wypadnie w twoim zadaniu, rozstrzyga test na twoich dokumentach i nic innego.

Utrzyma ją osoba, którą wskażesz z imienia jeszcze przed uruchomieniem — automatyzacja bez opiekuna psuje się po cichu i zwykle wychodzi to na jaw dopiero przy reklamacji klienta. Przepływy przestają działać rzadko dlatego, że ktoś je zepsuł; zwykle zmienia się coś na zewnątrz: dostawca aktualizuje API, wygasa token, kontrahent zmienia format pliku, a system magazynowy zaczyna odpowiadać wolniej, niż wynosi limit czasu. Wszystkie trzy narzędzia pokazują błędy w swoim panelu, ale panel trzeba otworzyć. Stosujemy tu zasadę bez wyjątków: wdrożenie procesu krytycznego bez wskazanego opiekuna po stronie klienta albo bez umowy na utrzymanie po prostu nie rusza — nie z zasad handlowych, tylko dlatego, że taki projekt kończy się awarią, o której obie strony dowiadują się od klienta końcowego.

Najczęstszy antywzorzec utrzymania to powiadomienia o błędach, które trafiają wyłącznie do panelu narzędzia albo na skrzynkę techniczną, do której nikt nie zagląda. Formalnie monitoring istnieje, praktycznie nie istnieje nikt, kto na niego patrzy — a to gorsze niż jego brak, bo daje złudzenie kontroli. Dlatego uważamy, że powiadomienie ma trafiać tam, gdzie ludzie i tak są w godzinach pracy, i ma być na tyle konkretne, żeby dało się z niego zrozumieć, który proces stanął. Poniżej minimum, które ustalamy przed uruchomieniem:

• właściciel procesu po stronie biznesu — wie, jak proces ma wyglądać, i rozstrzyga, czy zmiana jest błędem, czy nową regułą
• powiadomienia o błędach kierowane tam, gdzie ludzie naprawdę patrzą: na e-mail albo kanał zespołu, nie tylko do panelu narzędzia
• opis przepływu poza narzędziem: co go uruchamia, jakich systemów dotyka, kto ma dostęp i co robić, gdy stanie
• porządek w dostępach: konta serwisowe zamiast prywatnych, zapisany termin wymiany kluczy i tokenów
• plan awaryjny na ręczne wykonanie procesu przez dzień lub dwa oraz sposób nadgonienia zaległości

Przy self-hostingu dochodzi do tego warstwa serwerowa: aktualizacje, kopie zapasowe i ich testowe odtworzenie, monitoring dostępności, certyfikaty. To nie jest argument przeciw n8n na własnej maszynie — sami wybieramy go domyślnie — tylko argument za policzeniem tego czasu przed decyzją, bo policzony wygląda inaczej niż wyobrażony. W firmie bez zespołu technicznego rozsądnie wygląda układ mieszany: narzędzie chmurowe obsługuje procesy proste i mało wrażliwe, a własna instancja powstaje tam, gdzie wymaga tego charakter danych i gdzie ktoś ma ją pod stałą opieką — własny administrator albo partner techniczny z umową na reakcję.

Wybieraj od procesu, nie od narzędzia — kolejność pytań jest tu ważniejsza niż sama odpowiedź i to jest główna teza tego tekstu. Najpierw ustal, co ma się dziać, jakie dane przez to przechodzą i ile razy w miesiącu, a dopiero potem sprawdź, które z trzech narzędzi obsłuży to najtaniej i najbezpieczniej. Poniższa kolejność sprawdza się zarówno przy pierwszym wdrożeniu, jak i przy migracji z narzędzia, które przestało wystarczać.

1. 01Opisz proces zdaniamiWypisz kroki tak, jak wykonuje je dziś człowiek: co uruchamia pracę, jakie decyzje zapadają po drodze, gdzie kończy się dokument. Jeśli procesu nie da się opisać, automatyzacja tylko utrwali bałagan — i to jedyny moment, w którym radzimy przerwać projekt zamiast go zaczynać.
2. 02Policz wolumen i jednostkiZapisz, ile razy w miesiącu proces się uruchamia i ile kroków ma w środku. Przelicz to na wykonania (n8n), operacje (Make) i zadania (Zapier) — dopiero te trzy liczby zestawiaj z aktualnymi cennikami dostawców. Porównywanie stawek przed policzeniem jednostek to porównywanie wielkości, które nie znaczą tego samego.
3. 03Sprawdź, jakie dane przechodząDane osobowe, faktury, dokumentacja objęta tajemnicą zawodową? Jeśli tak, najpierw rozstrzygnij kwestię miejsca przetwarzania i umowy powierzenia, a dopiero potem porównuj wygodę interfejsu. Odwrotna kolejność kończy się przebudową po dziesiątym przepływie.
4. 04Zweryfikuj integracje na liście, nie w reklamieSprawdź w dokumentacji dostawcy, czy istnieje gotowy łącznik do twojego ERP, CRM i systemu magazynowego, a jeśli nie — czy mają API i webhooki. Brak webhooka oznacza odpytywanie, a odpytywanie kosztuje jednostki niezależnie od tego, czy cokolwiek się wydarzyło.
5. 05Zbuduj jeden przepływ end-to-endZanim kupisz plan roczny, uruchom produkcyjnie jeden najprostszy proces i obserwuj go przez miesiąc. Realne zużycie jednostek prawie zawsze różni się od szacunku zrobionego na kartce, a plan roczny podpisany przed tym miesiącem to zakład, nie decyzja.
6. 06Zaplanuj utrzymanieUstal z góry, kto reaguje, gdy integracja przestanie działać, gdzie trafiają powiadomienia o błędach i jak wygląda plan awaryjny. Automatyzacja bez opiekuna przestaje działać po cichu — a im lepiej działała wcześniej, tym później ktokolwiek to zauważy.

Skrót, który stosujemy: domyślnie n8n — bo rozliczenie za wykonanie nie karze za długie przepływy, kod jest w nim normalnym elementem pracy, a dane da się zatrzymać u klienta. Zapier, gdy proces ma kilka kroków, spina popularne aplikacje SaaS i klient ma go rozwijać sam. Make, gdy scenariusz się rozgałęzia, dużo w nim przetwarzania danych i plików, a zespół zna już iteratory i agregatory albo jest gotów się ich nauczyć. Od domyślnego wyboru odchodzimy przede wszystkim wtedy, gdy nie ma komu zaopiekować się instancją — wtedy wygodę stawiamy wyżej niż kontrolę nad danymi, bo niepilnowany serwer nie daje żadnej z tych rzeczy. W wielu firmach kończy się na dwóch narzędziach naraz i to również jest poprawna odpowiedź, o ile ktoś wie, które procesy gdzie mieszkają i kto odpowiada za każde z nich.

Jeśli miałbyś zapamiętać z tego tekstu jedno zdanie, niech to nie będzie zdanie o narzędziach. Przepływ jest wart tyle, ile opis procesu, który za nim stoi — narzędzie wymienisz w kilka tygodni, opisu procesu nikt nie napisze za ciebie. Dlatego pierwsze pieniądze w automatyzacji wydawaj na zrozumienie własnej roboty, a dopiero drugie na konto w którejkolwiek z tych trzech platform.