Ik ga deze "build log"-stukken af en toe schrijven — korte, eerlijke verslagen van iets dat ik recent echt gebouwd heb en de beslissingen erachter. Geen tutorials, geen thought leadership. Gewoon de echte redenering, inclusief de dingen die ik anders zou doen. Als u een Belgisch bedrijf bent en zich afvraagt hoe "senior engineering" er in de praktijk uitziet, dan is dit het dichtst bij meekijken over mijn schouder.
Dit gaat over de lead-capture flow op deze site zelf: de AI-gereedheidscheck, de gratis bronnen, de ROI-calculator, en de nieuwsbriefinschrijvingen. Ze komen allemaal op één plek terecht. Hier is hoe, en waarom ik de keuzes maakte die ik maakte.
Het doel, helder gesteld
Ik wilde drie verschillende "zachte" conversiepunten — een quiz, gated downloads, een calculator — allemaal een e-mail in een mailinglijst laten droppen, en ik wilde weten van welk punt elke inschrijver kwam. Zonder een marketingplatform erbij te halen, zonder API-sleutels naar de browser te lekken, en zonder de site trager te maken.
Dat is het. Bewust een kleine scope.
Beslissing 1: één tool, niet drie
De verleidelijke versie is om per taak een aparte tool te pakken — een quizplatform, een formulierwidget, een e-maildienst. Drie abonnementen, drie integraties, drie dingen die kapot kunnen gaan.
De site gebruikte al Brevo voor het contactformulier (transactionele e-mail). Brevo doet ook contactlijsten en automatiseringen. Dus de eerlijke zet was: gebruik wat er al is. Eén account, één API-sleutel, één integratie om over na te denken.
Dit is het soort beslissing dat niet in een demo opduikt maar wel in de factuur en de onderhoudslast achttien maanden later. Minder bewegende delen is een feature.
Beslissing 2: de credentials raken nooit de browser
Elk capture-formulier op de site post naar een kleine server-route (/api/newsletter), en die praat met Brevo. De API-sleutel leeft alleen server-side — hij zit nooit in de client-bundle.
Dit klinkt vanzelfsprekend, maar de gangbare kortere weg is de e-mailprovider rechtstreeks vanuit de browser aanroepen met een "publieke" sleutel. Dat werkt tot het niet meer werkt: publieke sleutels worden gescraped en misbruikt. Een dunne server-route is een paar extra regels en verwijdert het hele probleem.
De route valideert de invoer met een schema, en belt dan Brevo. Als Brevo niet geconfigureerd is, geeft hij een nette fout en toont het formulier een vriendelijke boodschap — geen stack traces, geen halfgebroken toestand.
Beslissing 3: gracieuze degradatie boven slimme fallbacks
Hier is een kleine waar ik blij mee ben. De nieuwsbriefroute heeft twee dingen nodig: een API-sleutel en een doel-lijst-ID. Als een van beide ontbreekt, geeft de route een "niet geconfigureerd"-antwoord en toont de UI zijn normale foutstatus.
Geen nepdata die doet alsof het werkt. Geen stil succes dat de e-mail verliest. Als het niet aangesloten is, zegt het dat. Wanneer de echte lijst-ID in de omgeving gezet wordt, begint het gewoon te werken — geen codewijziging.
Die eerlijkheid telt meer dan het klinkt. De ergste faalwijze voor een inschrijfformulier is er een die eruitziet alsof het werkte en het adres stilletjes laat vallen. Ik heb liever dat het zichtbaar faalt dan dat het stilletjes liegt.
Beslissing 4: tag de bron, zodat de data de moeite waard is
Elke capture geeft een source door — quiz, roi-calculator, lead-magnet:ai-policy, footer, enzovoort — opgeslagen als een attribuut op het contact in Brevo.
Het is één extra veld. Maar het verandert "we kregen wat inschrijvingen" in "de quiz converteert, de footer niet, schrijf meer zoals de quiz." Instrumentatie die je bij het bouwen toevoegt kost vrijwel niets; instrumentatie die je later probeert toe te voegen betekent dat je de data die je wenste al kwijt bent.
Beslissing 5: houd de wiskunde eerlijk en gescheiden
De ROI-calculator had een black box kunnen zijn die een indrukwekkend cijfer uitspuwt. In plaats daarvan leeft de berekening in een kleine, pure functie — geen UI, geen framework — en is ze bewust conservatief: ze houdt rekening met werkweken, beperkt hoeveel van een taak AI realistisch kan overnemen, en verrekent een ruwe bouw- en draaikost. Ze zegt zelfs, op de pagina, "illustratief, geen offerte."
Twee redenen. Ten eerste is een cijfer dat je kunt verdedigen meer waard dan een cijfer dat alleen maar groot is. Ten tweede is pure logica testbaar en makkelijk te wijzigen — als ik de aannames wil bijstellen, raak ik één bestand aan, niet een kluwen componentcode. Het scheiden van "wat het berekent" en "hoe het eruitziet" is een van die gewoontes die elke keer loont.
Wat ik zou herzien
Een paar eerlijke noten. De capture-flow voegt het contact momenteel rechtstreeks toe; voor een striktere GDPR-houding zou ik de nieuwsbrief waarschijnlijk naar een double-opt-in (bevestigingsmail) verplaatsen voor de lancering — Brevo ondersteunt het, het is een kleine wijziging, en voor een EU-publiek is het de schonere standaard. En de quizstatus leeft alleen in de browser; als ik mensen hun volledige resultaatuitsplitsing wilde mailen, zou ik de antwoorden doorgeven aan de transactionele e-mail. Beide zijn bewuste "later, als het zijn plek verdient"-keuzes, geen dingen die ik vergat.
Waarom ik u dit toon
Omdat de kloof die WDC vult precies dit is: veel mensen zullen u adviseren over AI en digitale projecten, maar veel minder zullen erbij gaan zitten en het ding degelijk bouwen — met de credentials juist behandeld, de faalwijzen doordacht, en de data geïnstrumenteerd zodat je werkelijk iets leert.
Geen van de bovenstaande beslissingen is flashy. Dat is het punt. Goede engineering voor een echt bedrijf is meestal een reeks kleine, saaie, correcte keuzes die optellen tot iets dat je kunt vertrouwen en later zonder angst kunt wijzigen.
Ik schrijf deze build logs en een korte, praktische nieuwsbrief voor Belgische bedrijven — echte engineering, de EU AI-wet, en AI-integratie, in begrijpelijke taal. Schrijf u hieronder in als u de volgende wilt.
En als u een project heeft waarbij u het liever in één keer goed gebouwd wilt dan eindeloos geadviseerd, dan is dat wat WDC doet — begin met een gesprek.