[ W skrócie ]
- Make wygrywa startem: setki gotowych integracji i niski próg wejścia. n8n wygrywa kontrolą: self-hosting, własny kod i przewidywalne koszty przy dużych wolumenach.
- Cenowa pułapka Make ujawnia się przy skali — płacisz za operacje, więc workflow przetwarzający tysiące rekordów potrafi zaskoczyć fakturą.
- n8n wymaga kogoś technicznego po Twojej stronie albo partnera, który go utrzyma — samoobsługowy jest tylko na papierze.
- Dla scenariuszy z AI (LLM, RAG, agenci) n8n daje dziś więcej klocków i mniej ograniczeń.
Dwa różne charaktery
Make (dawniej Integromat) to platforma SaaS: wizualny edytor, ogromna biblioteka gotowych połączeń, płatność za wykonane operacje. Filozofia: „kliknij i działa”.
n8n to narzędzie open source: możesz używać chmury producenta albo postawić je na własnym serwerze. Filozofia: „masz pełną kontrolę — i pełną odpowiedzialność”.
Oba zrobią klasykę automatyzacji: formularz → CRM, mail → zadanie, sklep → faktura. Różnice zaczynają się tam, gdzie kończy się demo.
Koszty: nie cennik, tylko rachunek przy skali
Cenniki obu narzędzi wyglądają niewinnie. Rachunek robi się ciekawy, gdy podstawisz swoje wolumeny:
| Kryterium | Make | n8n |
|---|---|---|
| model rozliczeń | za operacje w scenariuszu | za wykonania workflow (chmura) albo koszt serwera (self-host) |
| 10 tys. prostych zadań/mies. | umiarkowany koszt | porównywalnie albo taniej |
| 100 tys.+ operacji/mies. | koszt rośnie liniowo i boleśnie | self-host: praktycznie płaski koszt infrastruktury |
| nieprzewidywalne piki | drożej w miesiące pikowe | bez znaczenia przy self-hostingu |
Elastyczność: gotowe klocki vs własny kod
Make ma więcej gotowych integracji i lepsze „ostatnie 5 procent” przy popularnych narzędziach SaaS — jeśli Twój stack to standardowe aplikacje biznesowe, przewaga jest odczuwalna.
n8n odpowiada dwiema rzeczami: węzłem Code (pełny JavaScript, gdy klocka brakuje) i HTTP Request bez sztucznych limitów. W praktyce: w n8n nie zdarzyło nam się utknąć — najwyżej trzeba było napisać kilkanaście linii kodu.
Dla scenariuszy AI różnica jest większa: n8n ma natywne węzły dla modeli językowych, pamięci konwersacji i prostych agentów, a społeczność szybko dowozi nowe. W Make zrobisz to samo, ale częściej przez surowe wywołania API.
Utrzymanie: kto się tym zajmie?
To pytanie rozstrzyga więcej wyborów niż cennik:
- Make: aktualizacje, dostępność i bezpieczeństwo są problemem dostawcy. Płacisz za święty spokój.
- n8n self-host: aktualizacje, kopie zapasowe, monitoring i dostęp — Twoje. Jeśli nie masz osoby technicznej, potrzebujesz partnera (tak, robimy to dla klientów — ale mówimy o tym wprost, a nie drobnym drukiem).
Czego ten wybór NIE rozstrzyga
Warto powiedzieć wprost: narzędzie odpowiada za mniejszą część powodzenia projektu, niż sugeruje ilość dyskusji, które budzi.
Ani Make, ani n8n nie rozwiąże za Was trzech rzeczy, które decydują o tym, czy automatyzacja przetrwa rok: opisu procesu (co ma się dziać i w jakich przypadkach), obsługi wyjątków (co, gdy dane są niepełne) i właściciela (kto zauważy, że przepływ przestał działać). Te trzy elementy wyglądają tak samo w obu narzędziach — i w obu tak samo boli ich brak.
Migracja: jak trudno zmienić zdanie
Pytanie, które warto zadać przed wyborem, a nie po roku: co, jeśli się pomylimy?
Odpowiedź jest umiarkowanie optymistyczna. Przepływy nie są przenośne między narzędziami — trzeba je zbudować od nowa. Przenosi się natomiast to, co kosztowało najwięcej: opis procesu, reguły decyzyjne i mapa integracji. Odtworzenie działającego przepływu w drugim narzędziu to zwykle dni, nie tygodnie, o ile ta dokumentacja istnieje.
Wniosek praktyczny: opisujcie procesy poza narzędziem. Wtedy wybór przestaje być decyzją na zawsze i można go podjąć szybciej.
Nasza reguła wyboru
Jeżeli dopiero zaczynasz i chcesz sprawdzić, czy proces w ogóle wart jest automatyzacji — narzędzie jest wtórne: oba pozwolą zbudować pilota. Wybór na lata robi się przy skalowaniu, i wtedy warto go zrobić świadomie, z liczbami na stole.
