Retool vs Laravel voor een ops-dashboard: scoremethode

Het is een dinsdag in mei bij een logistieke speler vlak langs de A16 in Dordrecht. Zesentwintig mensen, twaalf vrachtwagens, vier soorten trailers, een planner met twee schermen en een telefoon geklemd tussen schouder en oor. De order intake leeft in een Excel-bestand dat via een Synology wordt gedeeld. De trailerstatus leeft in WhatsApp. De uitgaven aan de tankpas leven in een mailmap. Over zes weken komt de auditor voor een tussentijdse ISO 9001-audit, en de nieuwe compliance officer heeft net beseft dat er geen verdedigbaar overzicht is van wie wat heeft gewijzigd.

De directeur belt ons op een donderdag. Hij heeft binnen drie weken een ops-dashboard nodig. Hij heeft van Retool gehoord. Zijn neef, die een beetje codeert, heeft van Laravel gehoord. Hij wil weten welke wij zouden kiezen als we in zijn schoenen stonden.

Dit is de methode die wij gebruiken.

De drie scores die er echt toe doen

Elke beslissing over interne tools draait aan dezelfde drie knoppen. Tijd tot het eerste bruikbare scherm is de luidruchtige, maar ook de minst duurzame. De drie die jaar twee bepalen, zijn:

1. Verschuiving in het datamodel. Hoe vaak gaat het onderliggende schema bewegen in de komende achttien maanden?
2. Beheerder in jaar twee. Wie houdt het over dertien maanden draaiende, als de lanceringseuforie is uitgewerkt?
3. Audit trail. Welk bewijs accepteert een externe auditor daadwerkelijk?

Geef voor beide opties een score van 1 tot 5 per knop. Totaal van 15. Hoogste wint. Bij gelijkspel wint de optie waarvan de faalmodus het goedkoopst terug te draaien is.

Score één: verschuiving in het datamodel over achttien maanden

Retool bouwt queries die rechtstreeks naar kolomnamen verwijzen. Elk scherm, elk filter, elke export houdt een zachte pointer naar een tabelvorm vast. Hernoem trailer_id naar asset_id en je krijgt geen compile-fout, je krijgt een dinsdag waarop je de zeven plekken zoekt waar het stuk ging.

Een zelfgebouwde Laravel-admin (we gebruiken voor de meeste Filament) routeert het schema via Eloquent-models. Hernoem de kolom, draai een migratie, en de app valt luid om bij het opstarten. Luid falen is goedkoop. Stil falen kost je het vertrouwen van de auditor.

De score:

• Schema waarvan je verwacht dat het binnen de eerste maand bevriest: Retool 5, Laravel 4.
• Schema waarvan je weet dat het per kwartaal beweegt: Retool 2, Laravel 5.
• Schema dat je niet kunt voorspellen omdat het proces zelf nog wordt ontworpen: Retool 1, Laravel 5.

De Dordrechtse opdracht valt in bak drie. De compliance officer is het trailer-overdrachtsproces nog aan het opstellen. De planner wil een statusveld, maar kan de statussen nog niet benoemen.

Score twee: de persoon die het in maand dertien beheert

Interne tools sterven in jaar twee, niet in jaar één. Het lanceringsteam gaat verder. Het oorspronkelijke Notion-document verrot. Iemand blijft achter met de tool en een Slack-kanaal vol kleine verzoeken die nooit echt sluiten.

De pitch van Retool is dat de beheerder in jaar twee een ops-lead kan zijn met een SQL-gewoonte. Dat klopt wanneer de wijziging luidt: "voeg een kolom toe aan deze tabel, voeg ’m toe aan dit scherm." Het klopt niet wanneer de wijziging luidt: "we factureren nu per pallet, niet per rit, herstructureer de facturatieflow." Voor het tweede soort heb je dezelfde vaardigheden nodig als je nodig had om het in Laravel te bouwen, plus kennis van de eigenaardigheden van Retool. Het vaardigheidsplafond verdwijnt niet, het verhuist.

Stel de klant één vraag: is er een bij naam bekende persoon die deze tool in maand dertien gaat beheren, en wat is haar of zijn dagelijkse werk?

• Eigen developer of technisch medeoprichter: Laravel 5, Retool 3.
• Operations-lead die voor de lol SQL schrijft: Retool 4, Laravel 2.
• Nog niemand bij naam: Laravel 4, Retool 2. (Jij gaat ’m onderhouden. Kies de stack die je in 2028 aan een freelancer kunt overdragen.)

De Dordrechtse directeur noemt zijn planner. Ze draait queries in MySQL Workbench en schrijft in het weekend Excel-macro’s. Ze scoort een 4 aan de Retool-kant en een 2 aan de Laravel-kant.

Score drie: de audit trail die een auditor daadwerkelijk accepteert

Hier wuiven de meeste posts over interne tools het weg. Auditors willen geen "we loggen alles naar de database." Ze willen een append-only registratie die ze niet stilletjes kunnen wijzigen, gekoppeld aan een geauthenticeerde identiteit, met een tijdstempel waar de auditor op vertrouwt.

Voor ISO 9001 in een Nederlandse logistieke context betekent dat meestal: wie heeft de trailerstatus gewijzigd, wanneer, van wat naar wat, en welk document onderbouwt de wijziging. De auditor pakt steekproefsgewijs twintig rijen. Als er ook maar één van niet te reconstrueren is, gaat de bevinding in het rapport en het certificaat op een watch list.

Het ingebouwde audit log van Retool (op het Team-plan en hoger, zie de Retool audit log docs) registreert wie welke query draaide. Het registreert standaard niet de voor- en nawaarden van de rij die die query raakte. Dat kun je opzetten met een Supabase-trigger die naar een aparte audit_events-tabel schrijft, en dat doen we ook, maar dan vraagt de auditor wie er uit audit_events mag verwijderen. Met Supabase service-role keys die rondzwerven in Retool-resources, is "iedereen met Retool-adminrechten" het eerlijke antwoord.

Een Laravel-build met een fatsoenlijke audit-tabel (voor de saaie 80% leunen we op owen-it/laravel-auditing) laat je de audit-writes achter een interface zetten die de applicatie niet kan omzeilen, en de tabel zelf achter een Postgres-rol die de applicatiegebruiker niet bezit. De auditor leest dat als tamper-resistant. Retool leest als tamper-evident, met moeite.

Beide opties draaien in onze wereld op Postgres, dus het verschil zit niet in de database. Het zit in wat elke laag boven de database je daadwerkelijk schriftelijk laat garanderen.

De score:

• Lichte audit-behoefte, intern gebruik, geen certificering: Retool 4, Laravel 4.
• ISO 9001, AEO, of een vergelijkbare tussentijdse audit: Retool 2, Laravel 5.
• Gereguleerde finance, zorg, of iets waar een bevinding je vergunning kost: Retool 1, Laravel 5.

De scores toegepast op de Dordrechtse opdracht

Drie weken. Greenfield-proces. Een planner die vloeiend SQL spreekt. ISO 9001-tussentijdse audit.

                       Retool + Supabase   Laravel + Filament
Verschuiving datamodel         1                   5
Beheerder jaar twee            4                   2
Audit trail                    2                   5
-----------------------------------------------------------
Totaal                         7                  12

Laravel wint met twaalf tegen zeven. De deadline van drie weken is het stuk waar de directeur zich tegen verzet, en terecht. Dus splitsen we de opdracht.

Week één: modelleer de entiteiten samen met de planner op een whiteboard, leg de statussen vast, schrijf de migratie. Nog geen schermen. Week twee: bouw in Filament de vier schermen die de planner elk uur gebruikt, koppel de audit-tabel, vul deze vanuit de Excel. Week drie: usability-rondes met de planner en één chauffeur, deploy naar een kleine VPS, geef de planner een runbook in handen.

De schermen die ze niet elk uur gebruikt (tankpas-reconciliatie, maandelijkse KPI-export, klantgerichte pdf’s) krijgen een tweede sprint na de audit. We hebben ze op dag eenentwintig niet nodig. Dat hardop tegen de directeur zeggen op dag één, dat is het stuk dat je het schema oplevert.

Het geval waarin Retool wint

Dezelfde methode wijst de andere kant op bij een andere opdracht. Een marketingbureau waarmee we vorig jaar werkten had een dashboard nodig voor campagne-tracking. Het schema was stabiel (campagnes, kanalen, uitgaven, resultaten). De beheerder in jaar twee was het hoofd paid media, die in SQL leefde. Er was geen externe audit. Retool scoorde 13, een Laravel-build scoorde 9. We leverden Retool op in negen dagen en het bureau heeft sindsdien bijna niets veranderd.

De methode is niet "Laravel wint altijd voor ops, Retool wint altijd voor marketing." Het is "scoor de drie knoppen eerlijk en laat de getallen vallen." De saaie stack wint vaak het saaie probleem, en dat is prima. Het interessante werk zit stroomopwaarts, in de vraag wat de tool zou moeten onthouden.

Het kleinste wat je vandaag kunt doen

Open een leeg vel. Schrijf de namen op van de vijf entiteiten waar je ops-team het meest over ruziet. Schrijf naast elk of je de statussen kunt opsommen. Schrijf naast elke status wie hem voorwaarts en achterwaarts mag verzetten. Lukt het je niet om dat vel binnen een uur af te krijgen, dan redt geen enkele tool je. Lukt het wel, dan is de keuze tussen Retool en een zelfgebouwde admin nu een echt gesprek, geen vendor-pitch.

Toen we het ops-dashboard voor de Dordrechtse klant bouwden, liepen we ertegenaan dat het "status"-veld van de planner eigenlijk drie verschillende dingen tegelijk codeerde: trailerlocatie, papierwerk-status en chauffeursbeschikbaarheid. Dat hebben we uiteindelijk in drie kolommen gesplitst voordat we een regel Laravel schreven, en de audit-tabel werd een stuk makkelijker te verdedigen. Wil je hulp om dezelfde score op je eigen backlog los te laten? Dat is het soort procesautomatisering dat we doen.