Zapier, Make of maatwerk? Een besliskader voor bedrijfsautomatisering

De keuze tussen Zapier, Make en maatwerk wordt vaak te simpel voorgesteld. Aan de ene kant staat dan no-code als snel, goedkoop en geschikt voor eenvoudige automatiseringen; aan de andere kant maatwerk als professioneel, flexibel en bedoeld voor serieus werk. Die tegenstelling klopt in de praktijk niet goed.

Moderne automatiseringsplatforms bieden functies voor retries, foutafhandeling en throttling, en hebben tegelijk eigen limieten, prijsmodellen, afhankelijkheden en privacy-impact. Maatwerk geeft meer vrijheid en controle, maar betekent ook dat je zelf verantwoordelijk wordt voor architectuur, monitoring, onderhoud en herstel. De bruikbare vraag is daarom niet welke categorie beter is, maar welke oplossing voor dit specifieke proces voldoende controle, herstelbaarheid en voorspelbaarheid biedt tegen een passende totale beheerlast.

Eerst het proces, daarna het platform

Voordat je tools vergelijkt, moet duidelijk zijn wat je wilt automatiseren. Een proces dat nog voortdurend verandert, is geen goede basis voor een technische keuze. De eerste vragen gaan daarom over welke systemen betrokken zijn, welke data tussen die systemen beweegt, welke stappen voorspelbaar zijn, welke uitzonderingen bestaan, wat er gebeurt als een stap mislukt, hoe belangrijk het proces is voor omzet, voorraad, geld of klantbelofte, of iemand handmatig moet kunnen ingrijpen, en welke persoonsgegevens er worden verwerkt. Pas daarna wordt de vergelijking zinvol. Wil je eerst bepalen welk proces überhaupt geschikt is, dan is welke bedrijfsprocessen je wel en niet moet automatiseren het vertrekpunt.

No-code is niet hetzelfde als onbetrouwbaar

Platforms als Zapier en Make bieden een omgeving waarin bestaande systemen via kant-en-klare connectors, webhooks en workflowstappen aan elkaar worden gekoppeld. Voor een flow waarin een websiteformulier een CRM-contact aanmaakt en een interne melding verstuurt, is zo'n platform aantrekkelijk omdat veel technische infrastructuur al aanwezig is: connectorbeheer, basis-orchestration, bepaalde retrymechanismen, logging en workflowconfiguratie hoef je niet zelf te bouwen.

Het is te makkelijk om te stellen dat no-code alleen geschikt is voor hobbyprojecten. Make ondersteunt concepten als incomplete executions, error handlers en automatische retries voor bepaalde fouttypen. Zapier documenteert webhooklimieten, throttling en task- en workflowlimieten. Dat betekent niet dat iedere flow daarmee betrouwbaar is, maar wel dat de vergelijking oneerlijk wordt wanneer maatwerk alle professionele eigenschappen krijgt toegeschreven en no-code als speelgoedlaag wordt behandeld.

No-code is vooral sterk wanneer het proces goed aansluit op bestaande SaaS-systemen en connectors: twee bekende systemen, beperkte datamapping, gematigd volume, voorspelbare stappen, weinig complexe businesslogica, fouten die handmatig te herstellen zijn en geen extreem kritieke transacties. Een formulier dat naar het CRM gaat met een interne notificatie, of een nieuwe lead die een taak aanmaakt en een team informeert, past daar goed in.

Complex wordt het wanneer een workflow geleidelijk uitdijt. Wat begint als drie stappen groeit naar een keten van filters, lookups, transformaties, condities, routers, API-calls, fallbacks, retries en meldingen — en met meerdere systemen, uitzonderingen en terugkoppelingen erbij wordt dat technisch en operationeel lastig. De uitdaging zit dan niet in het aantal zichtbare stappen maar in de onderliggende verantwoordelijkheden: waar staat de brondata, welke stap mag schrijven, welke fout mag opnieuw worden geprobeerd, welke actie mag niet dubbel plaatsvinden, welke velden moeten worden getransformeerd en wat moet er gebeuren na een gedeeltelijke fout. Op dat punt is de platforminterface zelf een belangrijk onderdeel van je softwarearchitectuur geworden.

Maatwerk: meer controle, meer verantwoordelijkheid

Bij maatwerk bouw je de integratielogica in je eigen applicatie of backend. Dat geeft vrijheid over het datamodel, error handling, retries, idempotency, observability, queues, recovery, autorisatie, testbaarheid en de aansluiting op je eigen domeinlogica. Die vrijheid is waardevol zodra het proces uniek of bedrijfskritisch wordt.

Maatwerk is alleen niet automatisch betrouwbaarder. Een slecht ontworpen eigen integratie kan minder betrouwbaar zijn dan een goed ingerichte workflow op een bestaand platform. Betrouwbaarheid komt uit ontwerp, verificatie en operations, niet uit het label maatwerk.

Wanneer wordt maatwerk dan wel sterker? Bij unieke businesslogica met meerdere uitzonderingen, complexe statustransities, eigen prijs- of orderlogica, gespecialiseerde datatransformaties of domeinregels die slecht in generieke workflowblokken passen. Bij processen waarin vijf of zes systemen samenkomen, waar state management en foutafhandeling snel ingewikkeld worden en het belangrijk wordt zelf scherp te bepalen welke stap wat bezit. Bij hoge volumes, waar platformlimieten, taskcredits en throttling zwaarder gaan wegen en je meer controle wilt over batching, queueing, concurrency, caching en infrastructuur — die je dan wel zelf moet ontwerpen en onderhouden.

Complexe recovery is een vierde reden. Bij een bedrijfskritische workflow wil je niet alleen weten of de happy path werkt, maar ook welke stap is mislukt, wat al definitief is uitgevoerd, of veilig opnieuw proberen mogelijk is, hoe een medewerker kan herstellen, hoe een event opnieuw wordt afgespeeld en hoe je voorkomt dat een mutatie dubbel plaatsvindt. En tenslotte kan er een eigen gebruikersinterface nodig zijn: een adminomgeving, reviewqueue, recoverydashboard, statusoverzicht, handmatige goedkeuring of configuratie van regels. Dan schuift de oplossing richting een eigen bedrijfsapplicatie, en wordt de vergelijking in maatwerksoftware of standaardsoftware relevanter dan de keuze tussen twee automatiseringsplatforms. Het stappenplan voor een webapplicatie beschrijft hoe zo'n traject dan verloopt.

De vergelijking op een rij

Geen van beide kolommen is per definitie beter; de vraag is welke eigenschappen het proces werkelijk nodig heeft.

Kritikaliteit is de belangrijkste scheidslijn

Een notificatieworkflow en een financiële workflow stellen fundamenteel andere eisen. Gaat het om een nieuwe lead die een interne melding oplevert, dan is de impact beperkt wanneer die melding één keer niet aankomt en iemand dat eenvoudig herstelt. No-code is daar vaak zeer rationeel.

Bij een middelmatige kritikaliteit — een websiteformulier dat naar het CRM gaat, een taak aanmaakt en een bevestigingsmail verstuurt — wil je al beter nadenken over deduplicatie, retries en de zichtbaarheid van fouten. Ook dan kan no-code goed passen, mits de operationele controls voldoende zijn.

Wordt het een betaling die leidt tot een factuur, een voorraadmutatie en een orderstatus, dan hebben dubbele of ontbrekende verwerkingen directe zakelijke gevolgen. Eisen rond idempotency, audit trail, reconciliation, recovery en observability worden dan doorslaggevend. Dat kan maatwerk rechtvaardigen, maar alleen wanneer die eigenschappen daadwerkelijk beter worden ontworpen dan het platform ze biedt.

Volume, privacy en afhankelijkheid

No-codeplatforms rekenen doorgaans met usage-gerelateerde modellen, waarin tasks, operations, credits, webhooklimieten en API-calls meetellen. Bij hogere volumes kunnen die kosten oplopen. Daaruit volgt echter niet dat maatwerk bij volume goedkoper is, want eigen software brengt ontwikkeling, hosting, queue-infrastructuur, monitoring, onderhoud, incidentafhandeling en API-updates met zich mee. De juiste vergelijking is de total cost of ownership, niet de maandprijs van het platform.

Een automatiseringsplatform wordt bovendien onderdeel van je dataketen. Loopt de route van website via het platform naar CRM en e-mailprovider, dan is dat platform een extra verwerkingslaag. Je moet dan beoordelen welke persoonsgegevens er doorheen gaan, welke subprocessors betrokken zijn, waar data wordt verwerkt of opgeslagen, hoe lang logs en executiondata bewaard blijven en welke contractuele afspraken gelden. Zapier publiceert bijvoorbeeld een subprocessorregister, wat laat zien dat de platformkeuze ook een leveranciers- en privacykeuze is. Maatwerk geeft meer vrijheid in de technische keten, maar lost privacy niet vanzelf op.

Vendor lock-in bestaat aan beide kanten. Bij no-code zijn workflowdefinities en connectors platformgebonden en wordt de pricing extern bepaald. Bij maatwerk verschuift de afhankelijkheid naar je eigen code, de gekozen infrastructuur, ontwikkelkennis, dependencies en documentatiekwaliteit. De relevante vraag is of je de oplossing op lange termijn kunt begrijpen, onderhouden en migreren wanneer dat nodig wordt.

Dat raakt ook het onderhoud. Externe API's veranderen: er komen nieuwe versies, endpoints verdwijnen, authenticatie wijzigt, webhookevents veranderen en rate limits worden aangepast. Bij een no-codeplatform kan de connectorleverancier een deel van dat onderhoud opvangen; bij maatwerk ligt die verantwoordelijkheid bij het eigen team of de ontwikkelpartner. Dat is niet per definitie slechter, maar het hoort wel in de afweging.

Observability en recovery wegen zwaarder dan de happy path

Een workflow is pas goed beheerbaar wanneer je kunt zien wat er gebeurt. Bestaat er execution history, kun je input en output per stap bekijken, kun je fouten filteren, mislukte uitvoeringen opnieuw starten, alerts instellen en een fout terugleiden naar één concreet record? No-codeplatforms bieden daar hun eigen interface en logging voor. Maatwerk kan diepere observability bieden, maar alleen wanneer je die zelf bouwt — een eigen integratie zonder logging is niet beter dan een goed beheerde platformflow.

Recovery is in de praktijk belangrijker dan het gelukkige pad. Loopt een nieuwe webshoporder via een CRM-update en de boekhouding naar een notificatie, en slagen de eerste twee stappen terwijl de derde faalt, dan moet duidelijk zijn welke stappen al definitief zijn, welke opnieuw mag, welke data de bron van waarheid is en of een medewerker moet ingrijpen. Dat probleem bestaat bij no-code én bij maatwerk; de keuze hangt af van hoeveel controle je nodig hebt over dat herstelproces. Wat een API-koppeling betrouwbaar maakt werkt die eisen technisch uit.

Hybride is vaak de rationele uitkomst

De keuze hoeft niet binair te zijn. Een hybride architectuur laat kritieke order- en financiële logica in een maatwerk backend draaien, terwijl interne notificaties en niet-kritieke administratieve workflows via Zapier of Make lopen. Of: een maatwerk configurator met een eigen database en kernstate, met daarnaast no-code voor CRM-notificaties, Slack-berichten en interne follow-up. Zo blijft bedrijfskritische logica onder eigen controle zonder dat er onnodig maatwerk wordt gebouwd voor eenvoudige ondersteunende flows.

AI verandert dat besliskader niet fundamenteel. Het is vooral nuttig wanneer een stap ongestructureerde input bevat: een e-mail classificeren, velden uit documenten halen, een klantdossier samenvatten of een conceptantwoord maken. Een veilige hybride vorm laat AI interpreteren, deterministische software valideren, waar nodig een mens goedkeuren en het systeem daarna een gecontroleerde actie uitvoeren. AI hoort niet de eindbeslisser te zijn bij geldberekeningen, factuurnummering, harde autorisatie, formele validatieregels of onveranderlijke statustransities. De vraag is dus niet of het platform AI heeft, maar welke stap werkelijk baat heeft bij probabilistische interpretatie.

Drie scenario's, drie uitkomsten

Een eenvoudige leadflow — websiteformulier naar CRM met een interne melding — kent bekende SaaS-systemen, beperkte mapping, laag risico en handmatig herstelbare fouten. Dat is een sterke no-codekandidaat.

Een uitgebreider klantproces, waarin een formulier leidt tot een CRM-record, een projecttaak, een document, een e-mail en een terugkoppeling naar een portaal, kent meerdere objecten, meer statuslogica, belangrijker foutafhandeling en mogelijk privacygevoelige data. No-code of hybride kan nog steeds passen, mits de operationele eisen expliciet worden beoordeeld.

Een bedrijfskritische orderflow van webshop via betaalprovider, ERP, voorraad en facturatie naar fulfillment kent meerdere systems of record, financiële data, de noodzaak van idempotency, gedeeltelijke fouten, reconciliation, audit en recovery. Dat is een sterke kandidaat om maatwerk of een zeer gecontroleerde hybride architectuur serieus te overwegen — niet omdat maatwerk beter is, maar omdat de behoefte aan controle veel groter is.

Een praktisch besliskader

Beantwoord per proces acht vragen. Zijn de stappen vooral standaard en lineair, of bestaan er veel branches, uitzonderingen, statussen en validatieregels? Hoe unieker de logica, hoe interessanter maatwerk wordt. Wat gebeurt er als de flow niet draait, dubbel draait of verkeerde data verwerkt — hoe hoger die impact, hoe zwaarder recovery en observability wegen. Hoeveel executions zijn er, en wat betekent dat voor platformtasks, rate limits, infrastructuur en kosten?

Zijn er goede standaardconnectors beschikbaar, of moet je alsnog veel met custom HTTP-stappen werken? Wordt bijna alles custom, dan neemt het voordeel van no-code af. Kun je eenvoudig zien wat er is mislukt, veilig opnieuw uitvoeren, en is er een admin- of recoveryinterface nodig? Welke persoonsgegevens gaan door de keten, en is een extra platformverwerker acceptabel? Wie beheert credentials, API-versies, connectorwijzigingen en incidenten? En vergelijk tenslotte niet het platformabonnement met de bouwkosten, maar de implementatie plus platform- en API-gebruik, hosting, monitoring, onderhoud, incidentbeheer en toekomstige wijzigingen.

Kies op operationele verantwoordelijkheid

De echte keuze tussen Zapier, Make en maatwerk draait minder om professioneel versus eenvoudig dan om waar de verantwoordelijkheid komt te liggen. No-code verschuift een deel van de infrastructuur en operationele tooling naar een leverancier. Maatwerk geeft meer controle en legt meer verantwoordelijkheid bij jezelf of je ontwikkelpartner.

Maak die keuze daarom op businesslogica, kritikaliteit, volume, recovery, observability, privacy, afhankelijkheden en totale beheerkosten — niet op welke oplossing het professioneelst klinkt. Het maatwerkdeel daarvan valt onder koppelingen en automatisering.

Bronnen

Dit artikel is gebaseerd op het onderzoeksdossier over bedrijfsautomatisering, API-koppelingen en systeemintegraties. Voor de vergelijking zijn met name officiële documentatie van de genoemde automatiseringsplatforms en privacybronnen gebruikt.

• Zapier — Webhooks rate limits
• Zapier — subprocessors
• Make — retry error handler
• European Commission — GDPR principles
• EDPB — processors and subprocessors