Van Retool naar Temporal: wanneer je SaaS-ops klaar is

Het is dinsdag 09:14. Je ops-lead pingt het engineering-kanaal: de Zapier-taak die factuurstatussen in de Slack van een klant post is om 03:00 gesneuveld. Ze draait 'm al twintig minuten met de hand opnieuw. Vierde handmatige recovery deze maand, de tweede vóór haar koffie binnen was, en de derde keer dit kwartaal dat je een klant excuses moest mailen voor een statusupdate die nooit aankwam.

De vraag op tafel is niet of je Retool-en-Zapier-ops-laag 'goed genoeg' is. Wel of de kosten van behouden de kosten van vervangen voorbij zijn. We zaten de afgelopen achttien maanden bij drie Nederlandse SaaS-klanten in die kamer. De methode hieronder is wat we gebruiken om die discussie in één meeting te beslechten.

Waar Retool plus Zapier nog steeds wint

Een eerlijke opening: een SaaS met €2M ARR, acht mensen, één CRM en een Stripe-webhook heeft geen Temporal nodig. De drag-and-drop UI van Retool plus de webhook-routing van Zapier dekt zo'n 80% van de interne workflows voor minder dan €500 per maand. Niet-engineers lezen de flows. Time-to-shipped meet je in middagen. Er is geen infrastructuur om te beheren.

Het probleem zijn niet de tools. Het probleem is dat geen van beide het begrip duurzaamheid kent. Een mislukte Zapier-stap blijft stil tot iemand het in Slack opmerkt. Een Retool-query die timeoutet toont een toast en verdwijnt. Geen replay, geen idempotency keys, en niks dat je volgende auditor een control zal noemen.

Die afweging is prima, tot ze het niet meer is. De methode hieronder vertelt je wanneer dat punt voorbij is.

Wat Temporal plus interne API's écht vraagt

Temporal is een durable execution engine. Workflows overleven herstarts van het proces. Retries zijn automatisch en per stap configureerbaar. Elke input, output en timer komt in een event history die je kunt replayen. Het mentale model voelt op dag één buitenaards aan en is in week drie vanzelfsprekend.

Goedkoop is het in geen enkel opzicht. Je betaalt met senior engineering-tijd om workflows te schrijven in Go, TypeScript, Python of Java; reken op twee weken voor de eerste. Je betaalt hostingkosten, zelf gehost op Kubernetes als je de operator hebt, of Temporal Cloud voor ongeveer €100 per maand voor een klein team met korte history-retentie. Je betaalt aan mentaal model bij ops-mensen die niet meer klikkend een workflow kunnen aanpassen; zij krijgen in plaats daarvan een interne admin-UI, die jij moet bouwen.

Niks daarvan is weggegooid geld, maar je hoort het allemaal niet te betalen als de score hieronder zegt: blijf zitten.

Dimensie 1: incidentfrequentie

Tel alles waarbij een mens in Zapier of Retool moest inloggen om een stap te replayen, data met de hand te patchen, of een eenmalige SQL-update te schrijven om recht te zetten wat een automatisering had moeten doen. Scoor 0 tot 3:

• 0: minder dan één handmatige recovery per maand
• 1: één tot drie per maand
• 2: één of twee per week
• 3: dagelijks, of bijna dagelijks

Heb je hier nog geen log van, begin er dan een vóór je scoort. Een Notion-tabel met twee kolommen, datum en een regel beschrijving, dertig dagen bijgehouden, is genoeg. Wil je het in SQL:

-- Minimal incident ledger you can query before scoring
CREATE TABLE ops_incidents (
  id            bigserial PRIMARY KEY,
  occurred_at   timestamptz NOT NULL,
  recovered_at  timestamptz NOT NULL,
  recovery_kind text        NOT NULL,   -- 'manual' | 'auto_retry' | 'noop'
  workflow      text        NOT NULL,
  note          text
);

SELECT date_trunc('week', recovered_at)               AS week,
       count(*) FILTER (WHERE recovery_kind = 'manual') AS manual
FROM   ops_incidents
WHERE  recovered_at > now() - interval '90 days'
GROUP  BY 1
ORDER  BY 1 DESC;

De meeste teams die denken op '1' te zitten, ontdekken na een echte telling van dertig dagen dat ze op '2' staan. Dat zien we elke keer.

Dimensie 2: on-call bezetting

Hoeveel van je engineers worden volgens een rooster meegetrokken in ops-recovery? Scoor 0 tot 3:

• 0: niemand staat on-call voor ops-fouten
• 1: één engineer vangt ad-hoc pages op, geen formele rotatie
• 2: een rotatie van twee personen, betaald uit het engineering-budget
• 3: een rotatie van drie of meer personen met runbooks

Zodra je op een 2 zit, heb je je engineers stilletjes verbouwd tot ops-herstellers. Hun werk is verschoven van product bouwen naar integraties babysitten. Die kost duikt zelden op in een regel op de begroting, en precies daarom blijft hij jarenlang ongerepareerd.

De reden om naar durable execution te gaan is niet je ops-mensen vervangen door machines. Het is om te stoppen met de dinsdagochtend van je senior engineers verbranden aan het opnieuw draaien van Zaps die zichzelf hadden moeten replayen.

Dimensie 3: wat je volgende auditor accepteert

Dit is de dimensie waarop Nederlandse SaaS-oprichters worden verrast. De eerste SOC 2 Type II-audit, de eerste ISO 27001-surveillance, of een serieuze DPA-review onder de EU NIS2-richtlijn voor in-scope SaaS vragen allemaal bewijs dat je operationele workflows:

• geautoriseerd zijn: een bekend principal triggerde de actie
• gelogd zijn met wie-deed-wat-wanneer, onveranderlijk
• te reviewen zijn over het auditvenster, meestal twaalf maanden
• herstelbaar zijn op een gedocumenteerde manier na een failure

Zapier levert audit logs vanaf het Team-plan, maar de gebruikersattributie is zwak: een regel die zegt 'Zapier ran this Zap' overtuigt geen auditor die wil zien welke mens in jouw organisatie de run autoriseerde. De audit logs van Retool zijn sterker, maar geen van beide producten geeft je de event-immutability op workflow-niveau die de event history van Temporal standaard biedt.

Scoor 0 tot 3:

• 0: geen audit aan de horizon voor de komende vierentwintig maanden
• 1: er wordt over twaalf tot vierentwintig maanden een audit verwacht
• 2: er wordt binnen twaalf maanden een audit verwacht
• 3: je zit nu midden in een auditvenster, en de auditor heeft de ops-controls al aangestipt

De samengestelde score

Tel de drie dimensies op tot een score van negen, en lees de band af:

• 0 tot 2: blijven. Je Retool-plus-Zapier-stack doet zijn werk. Raak hem zes maanden niet aan.
• 3 tot 5: instrumenteren. Voeg een echt incident-ledger toe, structured logging op elke Zap en Retool-query, en geplande audit-log exports naar S3 of gelijkwaardig. Nog niet migreren.
• 6 tot 7: plan de overstap. Kies één workflow die je als bewijsstuk op Temporal herbouwt. Migreer de volgende twee in het kwartaal erna.
• 8 tot 9: je bent al laat. Het feit dat je dit scoort betekent dat je team brandt. Begin deze week.

De val waar de meeste teams in stappen is de band van 3 tot 5. Het voelt als een 'we moeten migreren'-score, maar een halve migratie naar Temporal terwijl je incident-ledger nog op gevoel draait, levert meestal een brozer systeem op dan wat je had. Eerst instrumenteren. Migreren pas als de data het rechtvaardigt.

Het instrumentatie-gat dat de meeste teams overslaan

Scoorde je 3 tot 5, dan is het antwoord nog geen migratie. Het antwoord is zes weken instrumenteren zodat je opnieuw kunt scoren met echte cijfers. Drie concrete artefacten om op te leveren vóór er ook maar één migratie-regel wordt geschreven:

• Een incident-ledger met één rij per handmatige recovery. De SQL hierboven is genoeg. Vul de afgelopen dertig dagen aan uit je Slack-history.
• Een structured-log export uit Zapier (Team-plan) en Retool naar waar je audit-log-store dan ook draait. CloudWatch, BigQuery, een Postgres-tabel; de bestemming maakt minder uit dan het contract.
• Eén dashboard met het wekelijkse aantal handmatige recoveries, time-to-recovery, en welke workflow de failure veroorzaakte. Bouw 'm in Retool zelf; daar is Retool voor.

De meeste teams die dit doen, ontdekken zes weken later dat hun score twee punten omhoog is gegaan. Of de migratie wordt evident juist, of evident nog-niet. Allebei besparen je een kwartaal nattevingerwerk.

Een vorm van twee weken voor de eerste migratie

De schoonste eerste migratie is de workflow met de hoogste frequentie en de kleinste blast radius. Niet je facturatiepipeline. Iets als 'nieuwe signup belandt in het CRM en krijgt een free trial'. Volume genoeg om de durable-execution-spier op te bouwen, lage stakes genoeg dat een bug op dinsdag niemand iets hoeft terug te betalen.

Week één: schrijf de workflow in Temporal en laat Zapier er parallel naast lopen. Vergelijk drie dagen lang de outputs in een tabel naast elkaar. Week twee: zet via een feature flag de switch om. Laat Zapier nog een week sluimeren als fallback. Daarna archiveren.

// activities.ts is the boring side: idempotent calls to your APIs.
// workflow.ts is the durable side: Temporal owns retries and state.

import { proxyActivities } from '@temporalio/workflow';
import type * as activities from './activities';

const { createCrmContact, provisionTrial, sendWelcomeMail } =
  proxyActivities<typeof activities>({
    startToCloseTimeout: '1 minute',
    retry: { maximumAttempts: 5, initialInterval: '2s' },
  });

export async function onboardSignup(email: string, plan: 'free' | 'pro') {
  const contactId = await createCrmContact(email);
  const tenantId  = await provisionTrial(email, plan);
  await sendWelcomeMail(email, tenantId);
  return { contactId, tenantId };
}

De regels die ertoe doen zijn startToCloseTimeout en retry. Die paar bytes configuratie maken het verschil tussen een integratie die om 03:00 stilletjes faalt, en een die zichzelf vijf keer opnieuw probeert met exponential backoff en alleen een mens belt als hij het echt opgeeft.

De meest gemaakte fout in week één is de activities over-engineeren. Hou ze dom: één HTTP-call, één DB-write, één return-waarde per stuk. De duurzaamheid woont in Temporal, niet in je activity-code. Weersta de neiging twee API-calls in één activity te proppen omdat ze 'bij elkaar horen'. Dat doen ze niet, en die bundeling is wat recoveries later pijn doet.

De lijn die we met drie klanten hebben gelopen

Toen we de customer-onboarding workflow bouwden voor een Nederlandse SaaS-klant rond €8M ARR, was het Temporal-schrijfwerk niet het probleem (acht dagen). Het probleem was dat hun Retool audit log de sample-test van de auditor niet overleefde. We verhuisden hun ops-oppervlak naar een Temporal-gedragen procesautomatisering-stack en schreven elke statusovergang naar een Postgres-eventtabel die de auditor direct kon bevragen.

Het kleinste wat je vandaag kunt doen: open je Zapier-task-history, tel de mislukte taken van de afgelopen dertig dagen, en schrijf het getal op een geeltje. Is het er meer dan acht, dan is je ops-laag nu al duurder dan je denkt.