Make vs n8n: co wybrać przy 5-10 automatyzacjach (i kiedy nauka samemu się nie opłaca)

Zapytania typu „make automatyzacja kurs” i „n8n automatyzacja praca” pokazują jedno: ludzie nie wahają się między narzędziami, tylko między dwiema drogami. Nauczyć się samemu i budować automatyzacje po godzinach, albo zlecić to komuś, kto robi to zawodowo. To jest właściwe pytanie i od niego zacznę, zamiast od porównania funkcji, które i tak za pół roku będą inne.

Z perspektywy wdrożeniowej widziałem obie ścieżki wielokrotnie. Widziałem firmy, które w miesiąc postawiły sensowny scenariusz w Make i działa on bez problemu od roku. Widziałem też scenariusze w n8n zbudowane przez jedną osobę, która potem odeszła z firmy, i nikt inny nie potrafił ich ruszyć, gdy dostawca CRM zmienił strukturę odpowiedzi API. Oba narzędzia są dobre. Pytanie brzmi, do czego i dla kogo.

Make i n8n – różnica, która realnie ma znaczenie

Make (dawniej Integromat) to narzędzie no-code w chmurze, płatne za liczbę operacji wykonanych w miesiącu. Im więcej kroków w scenariuszu i im częściej się on odpala, tym wyższy rachunek. To model wygodny na start, bo nie trzeba nic instalować, ale przy 5-10 automatyzacjach działających codziennie łatwo wpaść w wyższy próg cenowy, jeśli scenariusze nie są zoptymalizowane pod liczbę kroków.

n8n daje wybór: wersja cloud działa podobnie do Make, czyli płacisz abonament i nie martwisz się infrastrukturą. Wersja self-hosted oznacza, że stawiasz n8n na własnym serwerze (VPS) i płacisz tylko za hosting, rzędu kilkudziesięciu-kilkuset złotych miesięcznie, niezależnie od liczby operacji. To brzmi jak oczywista oszczędność, ale ktoś musi ten serwer utrzymać: aktualizacje, backupy, monitoring, reagowanie gdy usługa padnie w nocy. W małej firmie zwykle nikt nie ma na to czasu, więc self-host n8n bez planu utrzymania to często oszczędność pozorna.

Techniczny próg wejścia też jest różny. Make ma bardziej dopieszczony interfejs wizualny i więcej gotowych integracji „z pudełka”, więc osoba bez doświadczenia programistycznego szybciej dojdzie do działającego scenariusza. n8n daje więcej swobody (można wstawić kod JavaScript w środku flow, obsłużyć bardziej nietypowe API), ale wymaga też więcej rozumienia, jak działają zapytania HTTP, JSON, autoryzacja. To narzędzie bliższe programiście-amatorowi niż osobie wyłącznie biznesowej.

Kiedy nauka samemu naprawdę się opłaca

Jeśli masz jeden, może dwa procesy do zautomatyzowania i są one proste, powtarzalne, oparte na popularnych, dobrze udokumentowanych narzędziach (Gmail, Arkusze Google, Slack, prosty CRM), nauka samodzielna ma sens. Polskojęzycznych kursów Make przybyło w ostatnich latach na tyle, że pierwszy działający scenariusz da się zbudować w kilka-kilkanaście godzin nauki, rozłożonych na tydzień-dwa. Community wokół Make jest większe i bardziej przystępne dla osób nietechnicznych niż community n8n, które skupia głównie ludzi z zapleczem programistycznym.

Typowy dobry kandydat do samodzielnej automatyzacji: przenoszenie danych z formularza do arkusza i wysyłka powiadomienia na Slacka, prosty scenariusz powiadamiający o nowym leadzie, automatyczne wysyłanie przypomnień mailowych. Tu ryzyko, że coś się zepsuje w nieprzewidywalny sposób, jest niskie, a nawet jeśli scenariusz padnie, konsekwencje biznesowe są ograniczone. To dobre miejsce, żeby się uczyć na żywym organizmie, bo koszt błędu jest niski.

Kiedy samodzielna nauka kończy się zepsutym scenariuszem

Problem zaczyna się, gdy proces jest ważny biznesowo i opiera się na integracji z systemem, który nie ma stabilnego, dobrze udokumentowanego API. Klasyczny przykład: automatyzacja obiegu faktur między systemem księgowym, skrzynką mailową i CRM-em. Wygląda prosto na etapie budowy, ale w praktyce trzeba obsłużyć wyjątki: fakturę w złym formacie, duplikat, brak jednego pola, zmianę struktury odpowiedzi API po aktualizacji dostawcy. Samodzielnie zbudowany scenariusz zwykle obsługuje ścieżkę „happy path”, czyli sytuację idealną. Wystarczy jedna nietypowa faktura i cały proces się zatrzymuje albo, gorzej, przepuszcza błędne dane dalej.

Druga pułapka to zmiana w API zewnętrznego narzędzia. Dostawcy CRM-ów, platform e-commerce czy bramek płatniczych zmieniają swoje interfejsy bez pytania użytkowników no-code o zdanie. Osoba, która uczyła się Make czy n8n przez dwa tygodnie kursu, zwykle nie ma nawyku obsługi błędów, retry logiki, alertów o awarii. Scenariusz działa do pierwszej zmiany, a potem po prostu milczy, bo nikt nie dostał informacji, że coś przestało działać. W księgowości czy obsłudze zamówień to nie jest kosmetyczny problem, tylko realna strata pieniędzy albo czasu na ręczne odtwarzanie danych wstecz.

Trzecia rzecz, o której mało kto myśli na etapie nauki: co się stanie, gdy osoba, która zbudowała scenariusz, odejdzie z firmy albo zmieni stanowisko. Scenariusze budowane „na kolanie”, bez dokumentacji i bez ustandaryzowanej struktury, są praktycznie nieczytelne dla kogoś innego. W agencyjnym modelu wdrożenia dokumentacja i struktura są standardem, bo automatyzacja ma żyć dłużej niż projekt.

Ile realnie kosztuje utrzymanie Make i n8n przy 5-10 automatyzacjach

Przy jednej-dwóch automatyzacjach różnica kosztowa między narzędziami jest kosmetyczna. Przy 5-10 procesach działających jednocześnie w firmie robi się poważnie, i to nie tylko w wymiarze abonamentu.

W praktyce najdroższym elementem nie jest abonament, tylko czas. Jeśli osoba odpowiedzialna za automatyzacje w firmie poświęca kilka godzin tygodniowo na „gaszenie pożarów” (scenariusz się zawiesił, trzeba ręcznie poprawić dane, trzeba dostosować flow do zmiany w API), to jest realny koszt, tylko niewidoczny na fakturze od Make czy n8n. Przy 5-10 automatyzacjach ten czas potrafi urosnąć do pełnego etatu, szczególnie jeśli procesy dotyczą finansów czy obsługi klienta, gdzie błąd trzeba naprawić od razu, a nie „kiedy będzie czas”.

Kurs samodzielny czy wdrożenie z agencją – jak to rozstrzygnąć

Nie ma tu jednej słusznej odpowiedzi dla każdej firmy, ale jest sensowny sposób podjęcia decyzji. Zadaj sobie trzy pytania. Po pierwsze: ile procesów chcę zautomatyzować w ciągu najbliższego roku, jedno-dwa, czy realnie sześć-dziesięć. Po drugie: czy błąd w tym procesie kosztuje firmę realne pieniądze (np. źle wystawiona faktura, zgubione zamówienie klienta) czy tylko chwilę niedogodności. Po trzecie: czy w firmie jest osoba, która ma czas i predyspozycje, żeby zostać nieformalnym „opiekunem automatyzacji” na stałe, czy to będzie kolejny projekt odłożony po dwóch tygodniach entuzjazmu.

Jeśli odpowiedzi brzmią: jeden-dwa proste procesy, niski koszt błędu, jest osoba chętna do nauki, to kurs Make jest dobrą inwestycją, zwrot przyjdzie szybko. Jeśli odpowiedzi brzmią: kilka do kilkunastu procesów, część dotyczy finansów lub klientów, nikt w zespole nie ma czasu zostać „adminem automatyzacji”, to samodzielna nauka będzie kosztować więcej niż wdłożenie zewnętrzne, tylko koszt rozłoży się na miesiące frustracji zamiast na jedną fakturę.

W księgowości i finansach ten drugi scenariusz jest regułą, a nie wyjątkiem. Obieg faktur, uzgadnianie płatności, raportowanie do systemu księgowego to procesy, w których każdy niezauważony błąd rośnie z czasem. Dlatego przy tego typu wdrożeniach zwykle rekomendujemy podejście agencyjne od początku, patrz automatyzacja faktur albo szerzej automatyzacja biura rachunkowego, gdzie stawka błędu jest zbyt wysoka na naukę metodą prób i błędów. Podobnie wygląda to w obsłudze klienta, gdzie automatyzacja odpowiedzi czy routingu zgłoszeń musi obsłużyć wyjątki, a nie tylko sytuację modelową, o czym więcej przy automatyzacji obsługi klienta.

Model mieszany też ma sens i często proponujemy go klientom: agencja buduje pierwsze, najbardziej krytyczne automatyzacje z dokumentacją i procedurą reagowania na błędy, a zespół klienta uczy się na prostszych, mniej ryzykownych scenariuszach obok. To pozwala uniknąć sytuacji, w której cała wiedza o automatyzacji siedzi w głowie jednej osoby, a jednocześnie nie trzeba zlecać na zewnątrz absolutnie wszystkiego.

Co robimy inaczej we wdrożeniu agencyjnym

Różnica między scenariuszem z kursu a wdrożeniem produkcyjnym rzadko widać na pierwszy rzut oka, dopóki coś nie pójdzie nie tak. W praktyce chodzi o trzy rzeczy: obsługę wyjątków (co się dzieje, gdy dane wejściowe są niepełne albo błędne), monitoring i alerty (ktoś dostaje powiadomienie, zanim klient zauważy problem) oraz dokumentację, dzięki której inna osoba może przejąć proces bez odtwarzania logiki od zera. Automat robi zwykle 80% pracy bez udziału człowieka, ale przy nietypowym przypadku decyzję i tak zostawiamy człowiekowi, bo próba zautomatyzowania każdego wyjątku kosztuje więcej niż jest warta.

To jest też powód, dla którego nie polecamy wybierania narzędzia na sztywno przed analizą procesu. Czasem Make wystarczy w zupełności i przepłacanie za agencyjne wdrożenie prostego scenariusza nie ma sensu. Czasem n8n self-hosted jest jedynym sensownym wyborem, bo firma ma wymagania dotyczące przechowywania danych na własnym serwerze. Dobór narzędzia to konsekwencja analizy procesu, nie punkt wyjścia.