Telefon w poniedziałek rano: “Faktury nie poszły do księgowości przez weekend, klienci dzwonią”. Wchodzimy do panelu n8n, który ktoś postawił rok temu. Jeden node świeci na czerwono - dostawca zmienił format odpowiedzi w API. Nikt nie wie, kto ostatnio ruszał ten przepływ, nie ma historii zmian, a logika rozlazła się na czterdzieści klikanych bloczków połączonych strzałkami jak schemat metra. Naprawa zajmuje pół dnia, bo najpierw trzeba zrozumieć, co ten potwór w ogóle robi.
To nie jest wyjątek. To normalny koniec życia automatyzacji zbudowanej “na klik”. n8n świetnie wygląda na demie i na konferencji. Potem trafia na produkcję, dostaje prawdziwe dane, prawdziwy ruch i prawdziwe wyjątki - i okazuje się, że kupiliśmy sobie dług techniczny, którego nikt nie umie spłacić. Dlatego automatyzacje dla klientów piszemy w kodzie.
Demo kłamie, produkcja mówi prawdę
Każda prezentacja n8n wygląda tak samo: trzy ładne kafelki, strzałka, “i gotowe”. Wow. Tyle że produkcja nie składa się z trzech kafelków. Składa się z pytań typu “a co, jeśli klient nie ma NIP-u”, “a co, jeśli API odpowie po dwudziestu sekundach”, “a co, jeśli ten sam webhook przyjdzie dwa razy”. Każde takie pytanie to kolejny node, kolejny warunek, kolejna strzałka. Po pół roku masz tablicę, na którą boisz się patrzeć.
Klikany przepływ jest znośny na dziesięć kroków. Przy pięćdziesięciu robi się z tego plątanina, w której nikt - łącznie z autorem - nie ma pewności, co się stanie przy nietypowych danych. Logika warunkowa, pętle, obsługa błędów, dziesiątki wyjątków - to wszystko w nodach wygląda jak makaron. Kod ten sam warunek zapisuje w jednej czytelnej linijce, którą da się przeczytać, skomentować i przetestować. I zrozumieć za rok.
Pięć rzeczy, których n8n Ci nie da
Sensownej historii zmian
Workflow w n8n to konfiguracja zaszyta w bazie narzędzia. Ktoś coś przeklika, zapisze i tyle. Nie ma czytelnej historii, nie ma podglądu “co dokładnie się zmieniło”, nie ma autora. Eksport do JSON-a, którym czasem się to ratuje, jest nieczytelny dla człowieka i bezużyteczny przy realnym przeglądzie zmian. Gdy coś się zepsuje po edycji, zostaje zgadywanie.
Kod trzymamy w naszym repozytorium. Każda zmiana to osobny wpis z opisem i autorem. Widać, że trzy tygodnie temu zmienił się sposób liczenia rabatu i kto za tym stoi. Coś poszło źle po wdrożeniu - cofamy się do poprzedniej działającej wersji w minutę. To nie luksus, to podstawowa higiena przy czymś, od czego zależą pieniądze.
Testów, które łapią błąd przed klientem
Automatyzację w kodzie testujemy, zanim dotknie prawdziwych danych. Piszemy test: “dla zamówienia bez adresu dostawy zgłoś błąd, nie wysyłaj pustej etykiety”. Ten test pilnuje przy każdej kolejnej zmianie, żeby nowa poprawka nie zepsuła tego, co działało.
W n8n “test” to najczęściej puszczenie przepływu na produkcji i patrzenie, czy nie wybuchło. Przy procesie obsługującym setki zamówień dziennie to nie odwaga, to hazard - tyle że stawką są dane klienta.
Uczciwej obsługi błędów
Tu n8n potrafi naprawdę zaboleć. Obsługa błędów kończy się tam, gdzie kończą się opcje w panelu. Najczęściej sprowadza się do “spróbuj jeszcze raz”, a kiedy to nie pomoże, zadanie po prostu znika. Gdy zewnętrzne API ma dłuższą przerwę, dane wyparowują w ciszy, a Ty dowiadujesz się o tym z telefonu od klienta trzy dni później.
Kod daje pełną kontrolę: kolejka, która nie gubi zadań przy awarii, ponawianie z rozsądnym odstępem, log z konkretną przyczyną, powiadomienie na właściwy kanał. Gdy dostawca płatności wstaje po przerwie, zaległe zadania dochodzą same.
Przewidywalnych kosztów
n8n lubi rozliczać się od liczby wykonań, a samodzielny hosting też nie jest darmowy - to serwer plus utrzymanie instancji, aktualizacje i pilnowanie, żeby sama platforma nie padła. Przy stu uruchomieniach miesięcznie nie czuć nic. Przy stu tysiącach rachunek zaczyna boleć: im więcej automatyzacja pracuje, tym więcej oddajesz. Płacisz za to, że coś w ogóle działa.
Automatyzacja w kodzie chodzi na zwykłym serwerze albo w funkcji uruchamianej na żądanie. Koszt zależy od realnego zużycia, nie od cennika za “operację”. Przy większym wolumenie różnica robi się odczuwalna co miesiąc.
Licencji zamiast pułapki na platformie
To dla nas punkt, na którym dyskusja się kończy. Automatyzacja w n8n żyje w czyimś koncie, na czyimś serwerze, w głowie kogoś, kto ją klikał. Odejście freelancera, utrata dostępu do instancji, zmiana hasła - i zostajesz z JSON-em, którego nikt nie chce ruszyć. Awaria o trzeciej w nocy, zmiana API, audyt - to Twoja sprawa, bo workflow nie jest produktem, tylko sklejką w narzędziu cudzej firmy.
U nas automatyzacja to oprogramowanie na licencji. Kod jest naszą własnością: budujemy go, wersjonujemy, testujemy i utrzymujemy my. Klient płaci licencję i dostaje działający proces, aktualizacje przy zmianach po stronie integracji oraz wsparcie, gdy coś się sypnie. Nie musisz zatrudniać kogoś do ogarniania nodów ani martwić się, czy ktoś przypadkiem usunął połowę przepływu w panelu.
n8n na klik vs automatyzacja w kodzie
| Aspekt | n8n / Make (na klik) | Automatyzacja w kodzie |
|---|---|---|
| Demo | Robi wrażenie | Nudne |
| Złożona logika | Makaron z nodów | Jeden warunek, jedna linijka |
| Historia zmian | Brak lub nieczytelny JSON | Pełna, z autorem i opisem |
| Testy | Na produkcji, na żywca | Automatyczne, przed wdrożeniem |
| Błędy | ”Spróbuj ponownie”, potem cisza | Kolejki, ponawianie, własne logi |
| Koszt przy skali | Rośnie z każdym wykonaniem | Zależny od realnego zużycia |
| Zależność | Od platformy i kto ma dostęp | Licencja + utrzymanie po naszej stronie |
Kiedy n8n faktycznie ma sens
Żeby było uczciwie: n8n nie jest bezużyteczny i sami po niego sięgamy. Tyle że do roli, do której się nadaje, a nie do tej, w której wszyscy go upychają. Świetnie służy do prototypu, który ma w godzinę sprawdzić pomysł, zanim ktokolwiek wyda na niego pieniądze. Albo do błahego przepływu, który nigdy nie urośnie - “nowy wpis w formularzu wpada na Slacka”. Stawianie pod to repozytorium i testów byłoby przerostem formy nad treścią.
Granica jest prosta. Jeśli ten przepływ może się zepsuć i nikt tego nie zauważy - n8n wystarczy. Jeśli jego awarię zauważą klienci, księgowość albo magazyn - czas na kod. Problem w tym, że firmy notorycznie mylą jedno z drugim i orientują się dopiero w poniedziałek rano, z czerwonym nodem i dzwoniącym telefonem.
Jak robimy to my
Automatyzacje budujemy jak normalne oprogramowanie. Logika siedzi w naszym repozytorium, zmiany przechodzą przez przegląd, ważne ścieżki mają testy. Zadania, które mogą się nie udać za pierwszym razem, lecą przez kolejkę z ponawianiem. Mamy logi, które mówią, co i dlaczego się stało, oraz powiadomienia, gdy coś naprawdę wymaga człowieka. Integracje robimy przez API i kontrakty, które nie sypią się przy pierwszej zmianie po stronie dostawcy.
Klient nie przejmuje kodu ani obowiązku pilnowania infrastruktury - dostaje licencję na rozwiązanie, które działa i które rozwijamy pod jego proces. Efekt jest taki, że automatyzacja chodzi po cichu, a gdy trzeba ją zmienić, nie zaczynamy od rozszyfrowywania, co autor miał na myśli. Tak samo podchodzimy do reszty - sklepy budujemy na MedusaJS, a strony stawiamy lekko i statycznie, zamiast obwieszać je wtyczkami.
Na koniec
n8n jest narzędziem do prototypu i błahych przepływów - i tylko w tej roli warto go traktować poważnie. Gdy automatyzacja zaczyna obsługiwać faktury, magazyn i kontakt z klientem, klikanie nodów zamienia się w dług techniczny: bez historii zmian, bez testów, z dziurawą obsługą błędów, rosnącym rachunkiem i logiką uwiązaną do cudzej platformy. Licencja na kod, który ktoś utrzymuje za Ciebie, to nie moda. To różnica między automatyzacją, która po prostu działa, a taką, która budzi Cię telefonem.
Masz proces, który zżera czas zespołu, albo workflow w n8n, który lubi padać w najgorszym momencie? Napisz do nas - powiemy szczerze, co warto zostawić na klik, a co lepiej przepisać na kod, zanim zrobi się z tego kolejny poniedziałek.
Chcesz omówić temat z artykułu? Napisz do nas.
Napisz do nas