Blog
Welk van je tien producten is nu kapot?
Je hebt tien producten gelanceerd. Elk verdient een beetje, geen enkel verdient je volle aandacht. Hoe weet je dat alle tien nog werken zonder er één te controleren?
31 augustus 2026
Je hebt tien dingen gelanceerd. Samen betalen ze de huur. Los verdient geen van alle genoeg om een maandagochtend te verdienen — dus geen van alle krijgt er een.
Dat is de afspraak, en het is een goede afspraak. Er zit één gat in.
De portefeuille werkt alleen als elk product bijna niets kost om te houden
De eenmansportefeuille is tegenwoordig een werkend bedrijfsmodel omdat vrijwel elke terugkerende kostenpost per product is wegautomatiseerd. Deployen gebeurt zodra je pusht. Betalingen, facturen en mislukte incasso’s zijn andermans probleem. De database is beheerd en de hosting schaalt zichzelf. Support is een documentatiepagina en een inbox die je op donderdag bekijkt. Fouten landen in een tracker. Een uptimemonitor pingt elke URL en houdt zich stil.
Elk daarvan haalde een taak weg die meegroeide met het aantal producten dat je bezit. Dat is de hele truc: het tiende product is alleen de moeite van het lanceren waard omdat het je bijna niets kost om het aan te houden.
Er blijft één terugkerende kostenpost over, en dat is degene die je overslaat: weten dat waar mensen voor betalen nog steeds doet waarvoor ze betalen. Je slaat het over omdat overslaan geen directe gevolgen heeft. Precies dat maakt het gevaarlijk.
De storingen die ertoe doen gooien geen fouten
Stel je voor hoe een stil, winstgevend, onbeheerd product werkelijk doodgaat.
- Een betaalprovider zet de API-versie uit die jij hebt vastgezet. De afrekenpagina laadt, de knop draait, en er wordt nooit een kaart belast.
- Een verzenddomein wordt geblokkeerd na een DMARC-wijziging. De aanmelding wordt afgerond. De verificatiemail komt nooit aan, dus niemand kan het aanmaken van een account afmaken. Jouw applicatie ziet geen enkel probleem — ze heeft het bericht netjes overgedragen.
- Een OAuth-toestemmingsscherm moet opnieuw geverifieerd worden. ‘Inloggen met Google’ toont nu een waarschuwing over een niet-geverifieerde app. Elke bezoeker leest dat als oplichting en vertrekt.
- Een dependency-update verandert de standaardinstellingen van een formulierbibliotheek. Verzenden valideert nu een veld dat altijd leeg is, dus het formulier wordt nooit verstuurd — en geeft ook nooit een fout, want weigeren te versturen is precies waar validatie voor dient.
- Een database op het gratis plan pauzeert na inactiviteit. Het eerste verzoek van de dag wekt hem, loopt in een timeout, en toont een lege staat die eruitziet als een product zonder gegevens erin.
- Een CSS-wijziging duwt de koopknop op mobiel onder de vouw, achter de cookiemelding.
De lijst heeft één ding gemeen. In alle gevallen antwoordde de server, gooide geen enkele code een fout, en klaagde geen enkele klant.
Niemand klaagde omdat de mensen die het tegenkwamen vreemden waren. Ze hadden je e-mailadres niet en waren je geen bugmelding verschuldigd. De klanten die het je verteld zouden hebben, zijn precies degenen die nooit klant zijn geworden.
Uptime is een uitspraak over je server, niet over je product
Je monitor liegt niet tegen je. Hij beantwoordt een smallere vraag dan je dacht te stellen.
Een pinger stelt vast dat een URL een 200 teruggaf. Een afrekenpagina die geen kaart kan belasten geeft een 200 terug. Een aanmeldformulier dat geen mail verstuurt geeft een 200 terug. En een pagina die een lege staat toont uit een zojuist ontwaakte database ook.
Een foutentracker stelt vast dat je code geen fout gooide. Niets in bovenstaande lijst gooide een fout. Een geblokkeerd verzenddomein is een geslaagde API-aanroep. Een formulier dat weigert te versturen is validatie die werkt zoals bedoeld.
Beide instrumenten zijn de moeite waard en geen van beide kijkt of een klant slaagt. Dat is een andere vraag, en daar hoort een ander instrument bij.
Drie zinnen per product, geen drie testsuites
De omvang klinkt onmogelijk en is dat niet, want je hoeft geen tien producten te testen. Je moet het geldpad door tien producten testen, en dat is kort.
Bij vrijwel elk product zijn er drie flows die omzet dragen:
- Een vreemde kan gebruiker worden.
- Een gebruiker kan je betalen.
- Waar ze voor betaald hebben, doet wat het moet doen.
Tien producten, drie flows elk, is dertig controles. Dat klinkt als veel, tot je doorhebt dat het dertig zinnen zijn, geen dertig repositories:
Aanmelden met een nieuw e-mailadres, het account bevestigen vanuit
de verificatiemail, en op het dashboard uitkomen.
Upgraden naar het Pro-plan met een testkaart en zien dat het plan
op de facturatiepagina op Pro staat.
Een URL in het vak plakken, uitvoeren, en een rapport krijgen met
ten minste één regel erin.
Schrijf ze zoals je het product aan een vriend zou beschrijven. Als je de flow niet in één zin kunt beschrijven, is dat op zichzelf al de moeite waard om te weten.
Waarom je dit nog niet gedaan hebt, en waarom je gelijk had
Het is goed om het maar gewoon te zeggen: dit overslaan was geen luiheid. Het was rekenwerk, en het rekenwerk klopte.
Een Playwright-suite is een echt stuk techniek: selectors, fixtures, aangemaakte testaccounts, een CI-pipeline om hem in te draaien, en een onderhoudsrekening telkens als je een knop verplaatst. Tien daarvan is geen teststrategie, het is een tweede baan. Erger nog: het onderhoud schaalt per product, terwijl de omzet ook per product is en veel kleiner. Voor iets dat tweehonderd per maand opbrengt kost één middag kapotte selectors repareren meer dan de storing die het voorkomen zou hebben.
Dus deed je het verstandige en lanceerde je het elfde product.
Wat er veranderd is, is niet je discipline. Het is dat de kosten per product van één controle ver genoeg gedaald zijn dat dertig ervan geen tweede baan meer zijn.
Wat dit nog steeds niet voor je doet
Twee eerlijke grenzen, want een controle die te mooi wordt verkocht is een controle die je niet meer vertrouwt.
Het gaat je niet vertellen dat een product er niet meer toe doet. Alle drie de flows kunnen elke dag slagen terwijl het product stilletjes sterft aan gebrek aan vraag, verkeer en bestaansrecht. Dat is een reële faalmodus voor een portefeuille en geen enkele monitor merkt het op.
Het dekt de randgevallen ook niet af. Je dekt het geldpad bewust af en laat de rest onbedekt, wat op deze schaal de juiste afweging is en nog steeds een afweging.
En als een product negen dollar per maand opbrengt, is het antwoord misschien om het uit te zetten in plaats van het te bewaken. Een portefeuille is een reeks beslissingen, geen museum.
Waar dit heen leidt
Het obstakel was nooit weten wát je moet controleren — je zou de dertig zinnen vanmiddag kunnen opschrijven. Het was dat je er alleen iets draaiends van maakte door per product een testsuite te bouwen en te onderhouden, precies de kostenpost die het portefeuillemodel bestaat om te vermijden.
Dat gat is wat Testmode dicht: je schrijft de flow als een zin, hij draait tegen het echte, uitgerolde product in een echte browser op het ritme dat je zelf kiest, en hij vertelt je wanneer een klant vastgelopen zou zijn — zonder testcode, zonder pipeline, en zonder iets te installeren in welke van de tien repositories dan ook. Wil je de werkwijze in plaats van het betoog, dan behandelt regressietesten zonder QA-team hoe je de flows kiest en wat je doet als er één faalt.