Waarom we Zapier en n8n niet meer inzetten: vier redenen om voor een eigen agentic stack te kiezen

Zapier kost €20 per maand voor de basis. n8n draai je zelf op een goedkope VPS. Make heeft een gratis tier. Voor één enkele workflow is no-code dus aantrekkelijk: een trigger, een paar stappen, klaar. We hebben in 2023 en 2024 ook flinke stukken in deze tools gebouwd voor klanten. In 2026 doen we dat niet meer. Niet uit principe, maar omdat de praktijk ons leerde dat het bij meer dan twee of drie workflows fragiel wordt en dat een eigen agentic stack uiteindelijk eenvoudiger uitpakt.

Hier zijn de vier punten waar het voor ons omsloeg, en wat we ervoor in de plaats zetten.

1. No-code is een stappenplan, agentic is een doel

Een Zapier-flow doet letterlijk wat je opschrijft: "Als trigger X, doe stap 1, dan stap 2, dan stap 3." Dat werkt prima zolang elke uitvoering identiek is. Maar de meeste echte werkprocessen zijn dat niet. Een lead-research-workflow moet bij de ene lead drie bronnen raadplegen en bij de andere zes. Een offerte-conceptie moet bij twijfel doorvragen. Een e-mail-classificatie moet soms naar HR, soms naar sales, en soms direct beantwoord.

In een no-code platform los je dat op met routers, filters en if-then-takken. Na vijf of zes uitzonderingen wordt de flow onleesbaar. Bij een agentic aanpak geef je het model een doel ("research deze lead en vat samen wat relevant is") en laat je het zelf bepalen welke stappen nodig zijn. Korter, robuuster, en het aanpassen van het beleid is een edit in één system-prompt in plaats van twintig kliks in een visual editor.

2. Background workers tegenover event-driven runs

Zapier-runs zijn kort: minuten, geen uren. De meeste no-code platforms zijn gebouwd voor event-driven snelle handelingen. Maar echte business-processen lopen vaak langer: een lead opvolgen over meerdere dagen, een research-traject van een paar uur, een mail-thread die wacht op een reactie.

Onze stack gebruikt Celery-workers op Railway voor precies dit soort langlopende processen. Een agent start een taak, slaat state op in een database, en kan dagen later doorgaan waar hij gebleven was. In no-code is dat mogelijk met allerlei work-arounds (delays, polling), maar het kost meer dan het oplevert. In Python met Celery is het een handvol regels code en het werkt.

3. De kostencurve loopt verkeerd

No-code rekent per task of per operation. Dat is voorspelbaar bij honderd flows per maand. Bij tienduizend flows per maand is het ineens duurder dan een dedicated worker-instance met je eigen code. Een Railway-instance met Celery-workers kost vijf tot twintig euro per maand voor de meeste MKB-volumes. Je modelkosten betaal je daar nog bovenop, maar die zijn lineair en transparant: zoveel tokens, zoveel kosten.

De prijs-paradox van no-code: het is goedkoop tot het succesvol wordt.

4. Vendor-afhankelijkheid is een strategisch issue

Als Zapier morgen een populaire integratie schrapt, of de pricing herstructureert (en dat is meermaals gebeurd), sta je in je hemd. Je flows draaien daar, je data passeert daar, en migreren naar een ander platform betekent alles opnieuw bouwen.

Code in een eigen repo, draaiend op Railway, met Claude (of een ander model) erachter: dat is portable. Als één leverancier morgen iets gekkigs doet, schakelen we naar een ander model of een andere hosting-provider zonder dat de business-logica hoeft te veranderen. Dat soort flexibiliteit krijg je niet terug door een halve dag handwerk te besparen aan de voorkant.

Wat zit er dan wel in onze stack?

Bewust simpel gehouden, omdat we hebben geleerd dat tooling-complexiteit zélf het probleem wordt:

• Python met Celery voor background workers. Goed gedocumenteerd, ouder dan de hype, en doet wat het zegt te doen.

• Railway voor hosting. Vergelijkbare prijs als Heroku tien jaar geleden, betere developer experience.

• Een Claude Agent SDK-lus of een eigen lichte agentenlus voor het werk dat een LLM doet.

• Postgres voor state. Geen exotische databases. Een gewone Postgres slikt zo'n beetje alles wat een MKB-agent nodig heeft.

• Een dunne FastAPI-laag voor webhooks en HTTP-endpoints. Niets meer dan nodig is.

  
  

Geen Zapier, geen n8n, geen Make. Niet omdat ze slecht zijn, maar omdat ze niet meer schalen met wat onze klanten nodig hebben.

Wanneer no-code wel zinvol blijft

Eerlijk wat blijven: voor sommige situaties zijn no-code tools nog steeds de juiste keuze.

• Eenmalige flows zonder business-kritisch karakter. "Stuur me een Slack-bericht als iemand mijn nieuwsbrief abonneert" hoeft niet in productiecode te leven.

• Marketing-automations die het marketingteam zelf wil beheren. Geef hen Zapier en houd ontwikkelaars vrij voor zwaardere zaken.

• Proof-of-concept binnen 24 uur. Soms moet je iets snel testen. Bouw de productie-versie wel direct daarna in code.

  
  

Het probleem ontstaat als no-code de standaard wordt voor alles wat met automatisering te maken heeft. Dan stapelen de kwetsbaarheden zich op terwijl niemand het merkt.

Direct aan de slag

1. Inventariseer welke flows je nu in no-code hebt. Niet om alles om te bouwen, maar om te zien wat erin zit. De meeste organisaties zijn verrast door het aantal.

2. Markeer per flow: business-kritisch of niet. Business-kritische flows horen niet in een tool waar jij niet bij de code kunt.

3. Begin met één business-kritische flow ombouwen. Niet alles tegelijk. Eén proces, één agent, één Celery-worker, één Railway-deploy. Een paar dagen werk voor iemand die Python kent, of een korte opdracht aan een partij die dit dagelijks doet.

4. Houd no-code voor de rest. Eerlijk zijn over wat blijft staan voorkomt principe-rigorisme dat alleen tijd kost.

   
   

Het is niet de bedoeling om vandaag al je no-code flows uit te zetten. Wel om scherp te kiezen waar ze nog passen. Een team dat tien Zapier-flows beheert heeft een ander probleem dan een team met één Zapier-flow plus een productie-agent. Bij het eerste is "iets met AI doen" een verzameling losse tools geworden. Bij het tweede is het een coherent systeem.

De overstap van no-code naar een eigen agentic stack levert vooral helderheid op. Helderheid over kosten, over fouten, over wat er gebeurt als iets niet gaat zoals verwacht. In een wereld waar AI steeds meer bedrijfsprocessen aanraakt, is die helderheid uiteindelijk belangrijker dan de drie uur die je bespaart op de eerste workflow.