Case 07
Een aanbevelingslink, geen tweede keer uitgevonden
De consultancy-kant van pAinapple had geen manier om te zien wie een nieuwe klant had aangebracht. Microlearning had dat probleem al opgelost. In plaats van een nieuw systeem te bedenken, hergebruikten we exact dat patroon.
Nieuw onderdeel
/aanbevelen/[code] landingspagina
Hergebruikt patroon
Microlearnings ReferralToken / ReferredByMlSubscriberId
Nieuw ontworpen
Niets aan het datamodel
Gebouwd als
Twee losse PR's, backend en frontend, dezelfde ochtend
Situatie
Waar dit begon
Microlearning kent al jaren een aanbevelingslink: iedere abonnee heeft een eigen ReferralToken, en wie zich via die link aanmeldt, komt terecht als ReferredByMlSubscriberId bij de bestaande abonnee. Simpel, en het werkt.
De consultancy-kant van pAinapple had dat niet. Xander en David verwijzen af en toe iemand door, maar er was geen manier om een binnengekomen aanvraag terug te leggen bij wie hem had aangebracht. Elke aanbeveling verdween in hetzelfde contactformulier als ieder ander bericht.
Beslissing
Wat we besloten, en waarom niet anders
We hebben geen nieuw aanbevelingssysteem ontworpen. Microlearnings patroon paste bijna letterlijk: een tabel met code per verwijzer in plaats van een token per abonnee, een GET-route die de code opzoekt, een cookie zet en doorstuurt naar de site (exact de vorm van microlearnings eigen GET /api/v1/ml/r/{token}), en een nullable kolom op de bestaande formulieren om de verwijzer vast te leggen op het moment dat iemand echt iets instuurt.
Het enige verschil: microlearning kent zelfregistratie (iedere abonnee krijgt automatisch een token), hier is de lijst met verwijzers vooraf ingevuld met Xander en David zelf. Geen uitnodigingsflow nodig voor twee mensen.
Aan de voorkant gold hetzelfde: de /aanbevelen/[code] landingspagina toont eerst een echte pagina met OG-tags (nodig voor een fatsoenlijke voorvertoning als de link wordt gedeeld) en stuurt daarna door naar de backend-route, precies zoals microlearnings eigen uitnodiging/[token]-pagina dat al deed. Ook dat patroon is overgenomen, niet opnieuw bedacht.
Verloop
Wat er gebeurde, in volgorde
28 augustus 2026, 06:46
Backend eerst: de tabel en de route
PR #567 voegt SiteFormsReferrer toe (naam, unieke code), gevuld met Xander en David. SiteFormsQuickscan krijgt een nullable ReferrerId, en een nieuw SiteFormsContact-model legt vast wat /contact voorheen alleen mailde. De route GET /api/v1/site_forms/r/{code} zet een cookie van 30 dagen en stuurt door naar /, in dezelfde vorm als ml_referral_landing.
28 augustus 2026, 06:49
Frontend ernaast, met een aanname gedocumenteerd
PR #568 begon vrijwel gelijktijdig, voordat de backend-PR al open stond. De verwijzercodes en het pad naar de capture-route stonden daardoor als aanname in site/lib/referral.ts, met een expliciete notitie erbij: dit is het ene bestand om aan te passen zodra de backend-PR er is en iets anders blijkt.
28 augustus 2026, 07:06 en 07:09
Beide PR's dezelfde ochtend samengevoegd
Geen aanpassing nodig geweest: de aanname in referral.ts kwam overeen met wat de backend-PR daadwerkelijk opleverde. Binnen een half uur na de eerste commit stonden beide PR's op main.
Een patroon dat al bewezen werkt, is het opnieuw toepassen waard, ook als het net iets anders moet: minder velden, geen zelfregistratie, een andere naam voor dezelfde kolom.
Het scheelde niet alleen bouwtijd. Een tweede, net iets ander aanbevelingssysteem naast het eerste was ook een tweede plek geweest om te onderhouden, uit te leggen en te laten verwateren. Nu is er één vorm van hetzelfde idee, twee keer toegepast: eenmaal met tokens per abonnee, eenmaal met een vaste lijst codes voor twee mensen.
Dat de twee PR's parallel liepen zonder dat de aanname in de frontend-PR fout bleek, is geen toeval: beide namen hetzelfde bestaande patroon als uitgangspunt, in plaats van ieder een eigen oplossing te verzinnen die daarna nog op elkaar afgestemd moest worden.
Volgende stap
Zo'n verhaal, maar dan uw eigen
Herkenbaar? Een goed patroon dat al ergens in uw bedrijf werkt, hoeft bij het volgende probleem niet opnieuw uitgevonden te worden. Vaak is het rechtstreeks te hergebruiken.