▸ // spis treści
W styczniu napisałem, że twórcy kursów nagle przestali mówić o n8n, bo muszą mieć co sprzedawać. Dostałem za to trochę wiadomości w stylu "no właśnie, narzędzie się skończyło".
W maju 2026 SAP zainwestował w n8n przy wycenie 5,2 miliarda dolarów. To podwojenie z 2,5 miliarda z października 2025. Do tego ponad 1400 klientów enterprise, 1,7 miliona aktywnych budowniczych miesięcznie i ponad 100 milionów ARR.
Więc jak to jest: narzędzie umarło czy właśnie zostało wycenione na tyle, co średniej wielkości bank?
Coś tu nie gra. I to "coś" jest warte więcej niż samo narzędzie.
Z tego artykułu dowiesz się:
- dlaczego n8n zniknęło z contentu, ale nie z rynku,
- co to znaczy, że narzędzie przeszło z fazy "modne" do fazy "nudne",
- dlaczego wysoki próg wejścia jest Twoją fosą, a nie przeszkodą,
- co odpowiedzieć klientowi, który mówi "przecież Claude napisze mi to za darmo",
- gdzie dokładnie przebiega granica między tym, co zostaje w n8n, a tym, co ucieka do Pythona,
- ile realnie kosztuje wdrożenie takiego systemu.
To nie rynek zniknął. Zniknął content
Sprzeczność rozbraja się w jednym zdaniu: n8n nie wypadło z mody. Wypadło z contentu.
To dwie zupełnie różne rzeczy, które twórcy internetowi notorycznie mylą — bo widzą tylko jedną z nich. Jeśli Twoim światem jest feed na LinkedInie, to narzędzie, o którym nikt nie nagrywa, po prostu nie istnieje.
A tymczasem stało się coś innego. Narzędzie przeszło z fazy "modne wśród twórców na YouTube" do fazy "nudna infrastruktura, o której się nie mówi, bo po prostu działa".
Nikt nie nagrywa filmów o serwerze pocztowym. To nie znaczy, że poczta przestała chodzić.
Dlaczego contentowo umarło — mechanika, nie spisek
To nie jest teoria spiskowa. To zwykła arytmetyka uwagi.
Claude Code, Antigravity, Codex — zerowy próg wejścia, wynik po pięciu minutach, świetnie wygląda w miniaturce. Piszesz zdanie, dostajesz działającą rzecz. Idealny materiał na film.
n8n? Klikasz bloczek po bloczku. Musisz rozumieć API, autoryzację, format danych, to co zwraca webhook i to, czego nie zwraca. Zanim cokolwiek się wydarzy, mija czterdzieści minut konfiguracji.
n8n jest nudne, bo jest trudniejsze i próg wejścia jest wysoki. To jest cały problem.
Nuda nie robi zasięgów. Twórca żyje z zasięgów. Koniec zagadki — nie trzeba szukać drugiego dna.
Aha-moment: fosa przebrana za wadę
I tu dochodzimy do rzeczy, którą zrozumiałem dopiero po pół roku pracy z jednym i drugim narzędziem:
Łatwość narzędzia jest odwrotnie proporcjonalna do jego wartości rynkowej.
Przeczytaj to jeszcze raz, bo to jest cały artykuł w jednym zdaniu.
Claude Code ma próg wejścia bliski zeru. Dlatego nikt Ci za to nie zapłaci — klient zrobi to sam, w piętnaście minut, w przeglądarce. Nie sprzedasz usługi, która polega na napisaniu jednego zdania do czatu.
n8n wymaga wiedzy o API, o integracjach, o tym jak naprawdę wygląda proces u klienta. I dlatego jest z tego biznes.
To, co twórcy sprzedają jako wadę — "trudne, nudne, przestarzałe" — jest w rzeczywistości fosą. Każda osoba, która zniechęciła się do n8n i poszła nagrywać o agentach, właśnie zwiększyła wartość Twojej pracy.
Cisza wokół narzędzia to nie sygnał, że narzędzie umarło. To sygnał, że konkurencja odeszła.
"Po co mam Ci płacić, skoro Claude napisze mi to w pięć minut?"
To pytanie dostaję najczęściej i jest całkowicie uczciwe. Odpowiadam na nie zawsze tak samo.
Claude napisze skrypt w pięć minut i w teorii to będzie działało. Tylko że dostaniesz coś, nad czym nie masz żadnej kontroli. Będzie skrypt w Pythonie, który będzie się uruchamiał w magicznym pudełku i coś się będzie działo. Nie masz pojęcia, czy ten skrypt wysypie się jutro, czy pojutrze.
I teraz uwaga, bo tu jest niuans, który psuje prostą narrację: ja sam generuję skrypty dokładnie w ten sposób. Co więcej — całe workflowy do n8n też potrafię wygenerować Claude'em i bardzo fajnie to działa.
Różnica jest w tym, co dzieje się potem. Ja siadam i to wszystko weryfikuję. Konfiguruję. Spinam z narzędziami. Sprawdzam, czy każda integracja faktycznie odpowiada tym, czym powinna. Claude nie zrobi szybkich testów na żywym systemie klienta i nie zrobi tego sam.
Wersja podstawowa wyjdzie i zadziała. Wersja stabilna, którą można rzucić na produkcję — tej bym z automatu nie oddał. Przy prostych rzeczach czasem się uda. Przy skomplikowanych trzeba użyć odpowiednich narzędzi i wiedzieć, gdzie to się rozwali.
Klient nie płaci za wygenerowanie kodu. Płaci za to, że ktoś wie, co z tym kodem zrobić dalej.
Czego Claude nie wie o Twoim sklepie
Ogólniki o "wiedzy domenowej" niewiele znaczą, więc konkret ze sklepu.
W małym e-commerce zamówienie zwykle nie ma opisanej ścieżki logistycznej w systemie. W programie widać dwa stany: jest zamówienie, zamówienie wysłane. A cała magia dzieje się poza systemem — ktoś sprawdza u producenta, czy towar w ogóle jest na stanie, i dopiero wtedy go zamawia.
Claude nie ma do tego dostępu. Nie dlatego, że jest za słaby — dlatego, że tej informacji nie ma nigdzie w danych, które mu podasz.
Gorzej: właściciel sklepu, nawet gdyby bardzo chciał to zrobić sam, zwykle nie potrafi fachowo opisać tego przepływu tak, żeby model zrozumiał, jak to ma działać. Zna swój proces, ale zna go jako nawyk, nie jako specyfikację. Stworzy coś, co będzie działać — tylko nie będzie idealne, a różnica wyjdzie przy trzydziestym zamówieniu.
Moja przewaga nie polega na tym, że lepiej piszę prompty. Polega na tym, że posiedzę, porozmawiam z pracownikami i z właścicielem, i wyciągnę z nich to, czego nie ma w żadnej bazie danych. Dopiero potem wiem, gdzie się wpiąć — i wiem też, gdzie to się potrafi rozsypać, bo widziałem już podobne systemy.
Najsilniejszy zarzut: "przecież n8n samo stało się platformą agentową"
Uczciwie — jest kontra i jest mocna.
Ponad 80% workflowów budowanych dziś na n8n zawiera w środku agenta AI. Ktoś powie: to znaczy, że n8n nie jest ofiarą hype'u na agentów, tylko jego największym beneficjentem. Podział "nudne n8n kontra modni agenci" się sypie.
Przyznaję rację — częściowo. n8n rzeczywiście wchłonęło agentów zamiast z nimi przegrać.
Tylko że to nie podważa tezy. To ją wzmacnia. Narzędzie przetrwało zmianę całej epoki technologicznej, wchłonęło nową rzecz, urosło do 5,2 miliarda — i mimo to przestało być tematem filmów.
Rozjazd między modą a przydatnością zrobił się jeszcze większy, nie mniejszy. Właśnie o tym mówię.
Dorzucę jeszcze jedno, o czym się nie mówi: te agenty w workflowach są najczęstszym źródłem problemów. Trzeba naprawdę sporo przyłożyć do konfiguracji, żeby działały stabilnie. Pisałem o tym osobno w tekście o tym, dlaczego nie ufam agentom AI.
Co się w tym naprawdę sprzedaje
Skoro twierdzę, że na tym są pieniądze, to wypada powiedzieć, na czym konkretnie.
Siedzę głównie przy dwóch rzeczach: obsłudze maili i obsłudze zamówień.
Po stronie maili to hurtowe przetwarzanie: analiza treści, segregowanie, grupowanie, odsyłanie do konkretnych działów. Efekt jest taki, że nikt nie wykonuje pracy asystentki, która ręcznie rozdziela skrzynkę.
Po stronie zamówień robi się ciekawiej. Grupowanie zamówień na magazyny: przychodzi kilka zamówień do jednego sklepu, okazuje się, że czegoś brakuje — system automatycznie oznacza, co trzeba domówić, robi analizy, pokazuje prawdopodobieństwo zamówienia produktów. Do tego cała masa statystyk, których PrestaShop ani żadne standardowe narzędzie po prostu nie ma.
To są rzeczy nudne. Nudne w konkretnym znaczeniu: wymagają powtarzalnej pracy. I dokładnie dlatego ktoś za nie płaci.
Ile? Najprostszy workflow to jakieś pięć godzin — nie samego klikania, tylko razem z przetestowaniem i wdrożeniem. To wychodzi rząd wielkości tysiąca złotych. Bardziej zaawansowane systemy potrafią zająć czterdzieści godzin i więcej, ale wtedy nie mówimy już o pojedynczym workflow, tylko o systemie wykonującym kilkanaście funkcji.
Aktualna stawka godzinowa jest u mnie na stronie, więc nie ma tu żadnej tajemnicy. Tajemnicą jest raczej to, że klienci nie kwestionują tych liczb, kiedy widzą, ile godzin miesięcznie odzyskują.
Gdzie przebiega granica
Najważniejsza reguła, jakiej się nauczyłem, nie dotyczy narzędzia. Dotyczy wolumenu.
Do importów i eksportów produktów n8n bym nie używał. Tam przetwarzasz dużo rekordów i szybko — i tam dużo lepiej sprawdzi się zwykły skrypt. Ale do obsługi zamówień sprawdza się idealnie, bo zamówień jest radykalnie mniej niż produktów w sklepie.
To jest cała tajemnica. Nie "n8n jest dobre" albo "n8n jest złe", tylko: ile rekordów przez to przeleci.
Da się mieć na n8n dużą przepustowość, jeśli serwer jest odpowiednio mocny. Tylko wtedy i tak lepiej napisać porządny skrypt — bo płacisz RAM-em za wygodę, której już nie potrzebujesz.
Gdzie n8n naprawdę przestaje wystarczać
Żeby nie wyszło, że bronię narzędzia bezkrytycznie — bo nie bronię.
Około 10–15% moich workflowów ucieka z n8n do Pythona. Zawsze te same: najbardziej zasobożerne.
Konkret. Sklep, 30 tysięcy produktów, aktualizacja cen. W n8n leciało to pętlą, produkt po produkcie, każdy obrót z narzutem całego silnika. Wziąłem JSON tego workflow, wrzuciłem do Claude Code, wyszedł skrypt w Pythonie. Zweryfikowałem go, zmienne wyciągnąłem do osobnego pliku konfiguracyjnego i wrzuciłem w cron. Koniec problemu.
Różnica jest arytmetyczna, nie ideologiczna. Skrypt, który ma tylko połączyć się z bazą i przeklikać rekordy, zużyje mniej pamięci i poleci szybciej niż ten sam proces, który najpierw musi postawić całe środowisko n8n na Dockerze.
Drugi przypadek, tym razem porażka. Baza pytań do quizów wiedzy. Poległem na tabelach danych w n8n — a Claude Code zrobił to lepiej, i to właśnie dzięki niedeterminizmowi, który normalnie uważam za wadę. Zadanie było twórcze, nie powtarzalne. Źle dobrałem narzędzie do projektu.
To nie są porażki n8n. To naturalny koniec cyklu: n8n świetnie nadaje się do zaprojektowania i uruchomienia procesu, a gdy proces zaczyna dusić serwer, przenosisz go tam, gdzie jest tańszy. Opisywałem to szerzej w tekście o n8n jako Imperium Rzymskim.
Pozostałe 85% zostaje w n8n. I to jest ta część, która płaci rachunki.
Dlaczego to nie jest "wygodny szkicownik"
Ktoś w tym miejscu powie: skoro produkcja ucieka do Pythona, to n8n jest tylko narzędziem do prototypowania. Nazwij rzecz po imieniu.
Nie zgadzam się i mam na to prosty argument: łatwość rozwoju, nie łatwość napisania.
W n8n każde zadanie jest rozdzielone na pojedynczy klocek. Każdy node odpowiada za jedną rzecz. Kiedy chcesz coś zmienić po trzech miesiącach, przechodzisz strzałkami i widzisz, jak dane płyną przez system. Poprawiasz jeden bloczek.
W skrypcie wygenerowanym przez model masz kod. Jeśli nie rozumiesz Pythona — albo czegokolwiek, co to wygenerowało — nie jesteś w stanie tego w żaden sposób kontrolować ani poprawiać. Zostaje Ci mówienie: "Claude, napraw mi to i to". I zaczyna się iteracja, w której może popsuć się coś innego.
Do tego dochodzi rzecz, którą łatwo przeoczyć: gotowe integracje. Notion, MySQL, Supabase, Telegram, WhatsApp — poskładane stabilnie, jak klocki. A jeśli czegoś nie ma standardowo, są community nodes. Wtyczka do IMAP, do obsługi poczty na serwerach, jest genialna — robi dosłownie wszystko, łącznie z oznaczaniem wiadomości.
n8n jest kluczowy nie dlatego, że jest najszybszy. Jest kluczowy dlatego, że po pół roku nadal wiesz, co się w nim dzieje.
Kto to utrzymuje, gdy padnie za pół roku
Pytanie, które zadaje mało kto, a powinien zadawać każdy.
U mnie odpowiedź jest prosta: n8n instalujemy u klienta na serwerze, konfigurujemy, spinamy — i ja te systemy dalej obsługuję i rozwijam. Rzadko kiedy zostawiam system samopas, robiąc workflow i wysyłając go mailem.
Pracuję z klientami długotrwale i systematycznie. To nie jest model "wdrożenie i do widzenia" — i właśnie dlatego wiem, w którym momencie skrypt trzeba przepisać na Pythona. Bo widzę, jak ten system zachowuje się po pół roku, a nie tylko w dniu odbioru.
Jeśli kupujesz automatyzację od kogoś, kto znika po wdrożeniu, kupujesz demo z odroczonym terminem awarii.
Klient nie kupuje n8n
Zostaje jeszcze jedna rzecz, najważniejsza, a najczęściej pomijana.
Jeśli ktoś chce zarabiać na n8n, to ma problem w samych założeniach — bo chce zarabiać na n8n, zamiast rozwiązywać problemy biznesowe.
Klient nie kupuje n8n. On nie wie, że coś takiego istnieje, i szczerze mówiąc nie chce wiedzieć. Kupuje to, że maile segregują się same. Że zamówienie trafia do producenta bez jego udziału. Że w poniedziałek rano raport jest w skrzynce.
Czy pod spodem stoi n8n, Make czy skrypt w Pythonie — to Twoja sprawa, nie jego. Dokładnie tak samo, jak nie interesuje Cię marka wiertarki, którą hydraulik wywiercił dziurę w ścianie.
I żeby było jasne: alternatywy istnieją i działają. Make działa prawidłowo. Stary dobry Zapier też. Ja wybrałem n8n z jednego powodu — jest darmowy, mogę postawić go lokalnie na własnym komputerze i nie mam żadnych limitów w jego wykorzystaniu. To decyzja o kosztach i kontroli, nie deklaracja wiary.
Dlatego "guru", którzy sprzedawali n8n jako produkt, musieli się przesiąść, gdy rynek kursów się nasycił. Pisałem o tym w tekście o guru automatyzacji. Ci, którzy sprzedawali rozwiązane procesy, nie musieli zmieniać niczego. Bo procesy w firmach się nie zmieniły — nadal ktoś przepisuje dane z maila do arkusza.
Podsumowanie
- Cisza w internecie to nie sygnał rynkowy. n8n zniknęło z YouTube'a i jednocześnie podwoiło wycenę do 5,2 mld. Te dwie rzeczy nie są sprzeczne — dotyczą dwóch różnych rynków.
- Wysoki próg wejścia jest Twoim aktywem. Za rzeczy, które klient zrobi sam w pięć minut, nikt nie płaci. Za rzeczy wymagające wiedzy o API i o procesie — płaci.
- Wartość jest po wygenerowaniu kodu, nie w nim. Model napisze skrypt. Weryfikacja, spięcie z narzędziami i testy na żywym systemie to osobna robota — i to ona jest usługą.
- Granicę wyznacza wolumen, nie moda. Dziesiątki rekordów na przebieg: n8n. Tysiące: skrypt. Ucieczka do Pythona dotyczy 10–15% przypadków i dzieje się wtedy, gdy workflow dusi serwer.
- Licz łatwość rozwoju, nie łatwość startu. Prototyp w pięć minut jest bez wartości, jeśli po trzech miesiącach nikt nie wie, jak go poprawić.
- Sprzedawaj efekt, nie narzędzie. Kto buduje ofertę wokół nazwy technologii, będzie ją przebudowywał przy każdej modzie. Kto buduje wokół procesu klienta — nie musi.
Nudne, trudne, niemodne. I nadal płaci rachunki.
Zatrudnij roboty, uwolnij ludzi.
P.S. Jest jedno realne ryzyko, o którym warto pamiętać, a które po inwestycji SAP zrobiło się bardziej prawdopodobne: n8n nie jest open source, tylko fair-code (Sustainable Use License). Komercyjne odsprzedawanie jest ograniczone licencyjnie. Trzymam u siebie zamrożoną wersję lokalnie na Dockerze — działa i będzie działać, bo mam zapisaną dokładnie tę wersję, której używam, i nic nie zmusza mnie do aktualizacji. Plan mam prosty: jeśli przykręcą śrubę self-hostingowi, pożegnam się z narzędziem i przeniosę się na jedną z alternatyw. Nowych projektów bym już na tym nie stawiał, gdyby limity się zaostrzyły. To nie powód do paniki — to powód, żeby mieć plan B spisany, zanim będzie potrzebny.