Het Zapier-jaar

Bijna elke MKB-klant die we overnemen heeft hetzelfde probleem. Iemand bouwde drie jaar geleden in Zapier of Make een mooie flow: formulier in, ActiveCampaign uit, Slack-bericht erbij, klaar. Dat werkte. Toen kwam er een klantfunnel bij. Een lead-scoring. Een WhatsApp-flow voor support. Een refund-proces. En nu is er een doos van 47 zaps waarvan niemand precies weet wie wat triggert.

Iemand vertrekt, niemand kan de helft uitleggen, en zo begint elk gesprek over automation met spaghetti opruimen voordat we iets kunnen toevoegen.

Wat platforms goed kunnen

Drag-and-drop platforms zoals Zapier, Make en n8n zijn fantastisch voor één ding: een bekende, gebroken integratie tussen twee SaaS- tools die je niet zelf kunt fixen, met low-volume traffic.

Voorbeelden waar dit prima past:

  • Formulier doorzetten naar je CRM.
  • Stripe-betaling triggert een welkomst-email.
  • Slack-bericht bij een nieuwe enterprise-lead.

Tot een paar honderd events per dag, met een handvol stappen, blijft dit beheersbaar.

Wanneer platforms breken

Drie symptomen geven aan dat je over de grens gaat:

Conditionele logica met meer dan twee branches. Als je flow "if-this-and-that-but-only-when" wordt, ben je een functie aan het schrijven in een grafische interface. Dat lukt, en het is brak. Een half scherm kun je niet meer overzien, code wel.

State delen tussen flows. Als flow A iets opslaat dat flow B later moet lezen, heb je een database nodig. De meeste platforms hebben "data stores" toegevoegd, maar zonder ACID-garanties en met beperkte query-mogelijkheden.

High-volume of latency-gevoelig. Boven de 10.000 events per dag of als je sub-secondige reactie wilt, ga je tegen rate-limits en queueing-vertraging aanlopen.

Wanneer code de juiste keuze is

Code geeft je drie dingen die platforms niet kunnen geven: versiebeheer, testbaarheid en transparante kosten. Een Next.js-route met een ingestion-pipeline naar Postgres kost je 50 regels TypeScript en levert een infrastructuur die over vijf jaar nog werkt.

Wanneer wij voor klanten code-eerst kiezen:

  1. Lead-routing met scoring. Verschillende sales-flows op basis van bedrijfsgrootte, branche en gedrag. Vier of meer branches.
  2. E-commerce orchestratie. Voorraad, prijzen, productfeeds tussen meerdere kanalen. Te veel state om in een tool te beheren.
  3. Datawarehouse-feed. Alles wat naar BigQuery, Snowflake of Postgres moet voor analytics moet je zelf controleren.
  4. Klantgerichte automation. Zodra de klant ziet wat de automation doet (bijvoorbeeld een onboarding-flow), wil je code zodat je foutgedrag begrijpt en kunt fixen.

Hybride werkt het beste

In bijna al onze trajecten eindigen we hybride. Een coderegel-laag voor de logica die scherp moet zijn (lead routing, scoring, deduplicatie), een platform-laag voor SaaS-koppelingen die we niet zelf willen schrijven (CRM-API's, e-mail-providers).

Het platform doet "trigger-actie" werk waar de actie iets is dat veel SaaS-tools al ondersteunen. De code laag doet "denken" werk: state, beslissingen, validatie.

Hoe je morgen begint te ontwarren

  1. Inventariseer. Een ochtend besteden om elke actieve flow op papier te krijgen. Trigger, stappen, output, eigenaar.
  2. Identificeer de top 3 risico's. Welke flows raken als ze breken meer dan tien klanten of meer dan duizend euro per week?
  3. Zet die top 3 in code. Server-side, geversioneerd, met logs die je kunt doorzoeken.
  4. Behoud de rest in het platform. Maar maak per kwartaal een audit en kill flows die niemand meer aanzet.

Wat dit oplevert

Klanten die we hierin hebben begeleid melden drie dingen consequent terug. Eén, ze begrijpen wat hun automation doet, met of zonder de oorspronkelijke bouwer in dienst. Twee, gemiddelde reactietijd op leads daalt omdat queueing verdwijnt. Drie, de operationele kost gaat omlaag omdat ze van enterprise-tier op platforms terug naar starter-tier kunnen.

Niet sexy, wel duurzaam.