Make (Integromat) of maatwerk? Visuele scenario's versus eigen code: snelheid, controle, foutafhandeling en wie het over een jaar nog begrijpt.
Make bouwt visuele scenario's die meer stappen en vertakkingen aankunnen dan de meeste kliktools. Dat is ook het risico: een krachtig scenario dat niemand meer durft aan te passen. Maatwerk zet dezelfde logica in code, met toetsen en duidelijk eigenaarschap. Voor rijke, standaardstromen wint Make; voor processen die de dienst zelf vormen, wint maatwerk.
Make tekent automatiseringen als een kaart: modules, lijnen, vertakkingen. Leesbaar voor wie hem net bouwde. Die visuele vrijheid is zijn sterkte en zijn valkuil tegelijk: scenario's groeien van drie naar dertig modules en niemand die ze nog durft aan te raken. Maatwerk zet dezelfde logica in code, met toetsen die bewijzen dat een wijziging niets stukmaakt.
Vergelijk ze op houdbaarheid, niet op mogelijkheden. Make kán vrijwel alles wat een eigen koppeling kan, tot een grens na; de vraag is wie het bouwwerk over een jaar nog begrijpt, wat er gebeurt als een module stilvalt en of je een wijziging kunt toetsen zonder te gokken. De tabel zet die vragen op een rij, naast de criteria waarop een visueel scenario wint.
Voor stromen met inhoudelijke rijkdom (bestanden splitsen, tabellen samenvoegen, vertakkingen per type) is Make aantrekkelijker dan eenvoudigere kliktools, en sneller dan bouwen. Wie de scenario's zelf beheert, ze regelmatig aanpast en ze klein genoeg houdt, heeft er een krachtig gereedschap aan. Ook als een team visueel denkt en code vermijdt, wint een kaart van een coderepository: niemand hoeft een review te lezen om te snappen wat er gebeurt.
Als het scenario uitgroeit tot de onzichtbare motor van je dienst, verandert de vraag. Dan wil je dat een wijziging geautomatiseerd getoetst wordt voordat hij live gaat, dat een fout een traceerbaar spoor achterlaat en dat twee mensen het bouwwerk kunnen overdragen zonder archeologie. Scenario's die door filters, iterators en uitzonderingen groeien, worden op een gegeven moment code in vermomming. Maar dan zonder de voordelen van code: geen versiebeheer, geen toetsen, geen duidelijke eigenaar. Op dat punt is herschrijven in maatwerk vaak rustiger dan doorschaven.
Ja, en de grens tussen beide is helder te trekken: het rijke randwerk blijft in Make, het kernproces met regels en data verhuist naar eigen code. Bij zo'n overstap herschrijven we het scenario als workflow, leggen we de bestaande logica vast in toetsen en laten we beide een periode naast elkaar draaien tot de uitkomsten kloppen. Wat zo'n overstap vraagt, hangt af van de omvang van het scenario. We zetten er vooraf een schatting op nacalculatie naast, met een heldere en schriftelijke offerte die je aan je bestuur kunt voorleggen.
Omdat het groeit. Eerst drie modules, dan een filter, dan een uitzondering voor één klant; binnen een jaar is het een kaart die alleen de bouwer nog kan uitleggen. En die bouwer is inmiddels elders. Code met versiebeheer en toetsen begeleidt die groei bewuster: elke wijziging is terug te lezen, te vergelijken en terug te draaien.
Beperkt. Je kunt een scenario handmatig naspelen met voorbeeldgegevens, maar een geautomatiseerde toets die elke vertakking bewijst, hoort niet in het gereedschap. Bij maatwerk is dat normaal: de regels staan in toetsen, en elke wijziging draait die toetsen opnieuw. Voor scenario's met lage inzet is dat verlies acceptabel; voor het kernproces is het een risico.
Als de stroom inhoudelijk rijk maar regelarm is en het team hem zelf wil beheren. Bestanden verwerken, gegevens tussen twee bekende pakketten hervormen, een overzicht voeden: dat soort klussen staat in een visueel scenario sneller dan in code, zeker als er wekelijks iets schuift. De houdbaarheidseis is wél dat iemand het scenario kent en klein houdt.
Door per scenario te benoemen wat er kapotgaat als het stilvalt. Staat daar een klant of een betaling achter, dan hoort er monitoring, logging en een terugval bij. En die drie zijn in een eigen koppeling natuurlijker in te bouwen. Blijft de uitkomst beperkt tot een gemiste melding, dan is de tool prima. Die inschatting maken we samen, aan de hand van je processen.
EIGHTY8