Zeven platforms naast een baan en een pieper

Het is de vraag die op verjaardagen steevast na de thuisbatterij komt: "Maar wanneer dóé je dat dan allemaal?" Een fulltime baan bij de veiligheidsregio, een brandweerpieper die op de gekste momenten afgaat, een bureau, en daarnaast zeven draaiende platforms. Het eerlijke antwoord is minder heroïsch dan mensen hopen — en dat is precies het punt.

Eerst maar even ontkrachten

Wat het antwoord niet is: nachten doorhalen, een geheime kalender met 25 uur per dag, of het soort "hustle" waar op LinkedIn zonsopgangen bij worden gefotografeerd. Ik werk 's avonds een paar uur als het uitkomt, en soms weken nauwelijks. Er is geen team dat overdag doorbouwt en er is geen investeerder die ongeduldig wordt. Er is alleen een simpele voorwaarde waar alles uit volgt: alles wat ik bouw, moet kunnen overleven dat ik er wekenlang niet naar omkijk.

Die voorwaarde is geen keuze uit luiheid, maar uit realisme. Mijn agenda is niet van mij alleen. Als de pieper gaat tijdens het bouwen van een feature, dan ligt die feature er om 23:00 uur nog precies zo bij — half af, met de cursor knipperend in een functie waarvan ik de bedoeling moet terugverzinnen. Wie zeven diensten draait die dat niet aankunnen, heeft geen zeven producten maar zeven tikkende tijdbommen. Dus is elk platform — 112Radar, GrootIncident, SlimHuys, NetwerkBouwer, KorpsApp, HulpdienstVoertuigen en CloudVikings eronder — gebouwd volgens vier regels die stuk voor stuk stomvervelend klinken. Dat hoort zo. Spannende infrastructuur is een hobby voor mensen met tijd.

Regel 1: één stack, overal dezelfde

Al mijn platforms delen dezelfde technische fundering: dezelfde taal, hetzelfde soort database, dezelfde deploy-route, dezelfde serverinrichting op eigen hardware. Dat is geen technologisch statement — er zijn modernere keuzes denkbaar, en op borrels met developers verlies ik het gesprek over frameworks gegarandeerd. Het is een cognitief statement. Als ik na drie weken niet aan SlimHuys te hebben gezeten inlog, weet ik binnen een minuut waar alles staat, omdat het er staat waar het bij 112Radar óók staat.

Elke afwijkende technologiekeuze is een extra taal die je moet blijven spreken. Met een team van tien kun je je dat veroorloven; met een team van één op de late avond niet. Saai gereedschap dat ik blind beheers, wint het bij mij altijd van beter gereedschap dat aandacht vraagt — want aandacht is precies het schaarse goed.

Regel 2: monitoring die zwijgt tot het menens is

Bij de brandweer gaat de pieper alleen als er echt iets is. Niemand wordt gealarmeerd voor "misschien straks brand" — en dat is precies waarom iedereen komt áls hij gaat. Mijn monitoring is op hetzelfde principe ingericht: stilte is de norm, een melding is een inzet. Elke check die weleens vals alarmeert, wordt gerepareerd of verwijderd, want een alert waarvan je hebt geleerd dat je hem mag negeren is erger dan geen alert.

In de praktijk betekent dat: alles wat zichzelf kan herstellen, herstelt zichzelf en meldt hooguit achteraf. Een hangende verwerking wordt herstart, een volgelopen wachtrij ruimt zichzelf op, certificaten verlengen automatisch. Wat overblijft aan meldingen is het soort waar ik daadwerkelijk mijn laptop voor open. Dat zijn er in een gemiddelde maand — en dit is geen bescheidenheid maar boekhouding — misschien twee.

De 03:00-toets

Elk stuk infrastructuur krijgt bij het bouwen dezelfde vraag: wat gebeurt er als dit stuk kapotgaat om drie uur 's nachts terwijl ik op een uitruk sta? Als het antwoord is "dan merkt de gebruiker het pas na uren en fixt het zichzelf of wacht het rustig op mij", mag het live. Als het antwoord is "dan moet ik er meteen bij", is het ontwerp niet af.

Regel 3: bouw producten die tegen verwaarlozing kunnen

Er is een reden dat mijn platforms vrijwel allemaal datamachines zijn: P2000-meldingen die binnenstromen, EPEX-prijzen die dagelijks verschijnen, voertuiggegevens die veranderen. Zulke producten worden elke dag vanzelf actueler zonder dat ik iets doe. Een blog moet je voeden, een community moet je modereren, een SaaS met beloofde roadmap moet je bijbenen — een goed gebouwde datamachine draait door en is morgen waardevoller dan vandaag, ook als ik morgen op oefening sta.

Dezelfde regel bepaalt wat er niet komt. De featureverzoeken die binnenkomen zijn vaak goede ideeën, en de meeste wijs ik af — niet omdat ze de gebruiker niets opleveren, maar omdat ik bij elk verzoek niet de bouwtijd reken, maar de eeuwigdurende onderhoudslast. Een feature bouw je één keer; daarna is hij elke dag van je. "Nee" is in mijn situatie geen gebrek aan ambitie, het is de enige manier waarop het geheel blijft passen.

Regel 4: de platforms moeten elkaar voeden

Zeven losse producten naast een baan is waanzin. Maar het zijn er in de praktijk geen zeven — het is één ecosysteem met zeven gezichten. De P2000-pijplijn achter 112Radar voedt ook GrootIncident; de kazerne- en voertuigdata daaronder werd HulpdienstVoertuigen; mijn brandweerpost leverde het probleem waar KorpsApp het antwoord op is; het UniFi-werk voor klanten werd NetwerkBouwer; mijn eigen fascinatie voor dynamische stroomprijzen werd SlimHuys; en CloudVikings is simpelweg de infrastructuur onder dit alles, die zichzelf terugverdient door hem ook aan anderen te verhuren.

Elk nieuw platform kostte daardoor geen nieuw fundament, maar hergebruikte tachtig procent van wat er al stond. Dat is de rekensom die buitenstaanders missen: het eerste platform kostte jaren, het zevende kostte weken. En het draait allemaal op interesses die er toch al waren — ik zou óók naar stroomprijzen en P2000-verkeer kijken als er geen product aan vasthing. Bouwen aan deze dingen is voor mij wat puzzelen voor anderen is; het voelt alleen productiever en het puzzelt terug.

De eerlijke rekening

Zou dit verhaal een tien-stappen-plan zijn, dan hoorde hier de zin "en dat kun jij ook". Maar er is ook een rekening, en die hoort erbij. Er zijn avonden dat ik om 21:30 uur nog een storing zit uit te pluizen die niemand anders kan oppakken, omdat er geen niemand anders ís. Er zijn features waar gebruikers al maanden beleefd om vragen. Er is technische schuld waarvan alleen ik weet waar hij begraven ligt — en dat "alleen ik" is meteen het grootste risico van het hele model: het busnummer van dit ecosysteem is exact één. Dat weet ik, en de documentatie die dat moet ondervangen is — zoals overal — het minst leuke klusje op de lijst.

En toch. De baan geeft betekenis, de brandweer geeft perspectief, en het bouwen geeft iets wat die twee niet geven: een plek waar ik alles zelf mag beslissen én zelf de gevolgen draag. Na een dag vergaderen over andermans projecten is er weinig zo rustgevend als een systeem waar elke regel van jou is.

Conclusie

Hoe je zeven platforms draait naast een baan en een pieper? Door ze zo te bouwen dat ze jou meestal niet nodig hebben. Eén saaie stack, monitoring die zwijgt tot het menens is, producten die tegen verwaarlozing kunnen, en een ecosysteem waarin elk deel de andere voedt. Geen hustle, maar ontwerp. De verjaardagsvraag verdient dus eigenlijk een omgekeerd antwoord: het kost minder tijd dan je denkt — juist omdat er zoveel tijd in is gaan zitten om dat voor elkaar te krijgen.