Ik heb dit product volledig alleen gebouwd, vooral ’s avonds, in weekenden en ten koste van meer vrije dagen dan ik wil toegeven. Lange tijd voelde het desondanks nog als een persoonlijk project dat toevallig op het web stond.
Het activeren van betalingen veranderde dat gevoel meteen. De code werd niet plotseling geavanceerder, maar mijn verantwoordelijkheid voor het product veranderde wel. Zodra iemand kan betalen, is een kapotte flow niet langer alleen een onafgemaakte edge case. Onboarding, moderatie, retentie, vertrouwen en betrouwbaarheid zijn geen onderwerpen meer voor later. Ze horen bij wat het product op dat moment belooft.
Dat is de belangrijkste les die ik uit de launch heb gehaald: een feature-rijk soloproject bouwen en een echt product beheren zijn twee verschillende soorten werk.
Bij solo-ontwikkeling werd aandacht de bottleneck
Terwijl ik bouwde, verdween ik bijna van social media. Dat was geen launchstrategie. Productbeslissingen, implementatie, edge cases, flowtests en releasevoorbereiding concurreerden allemaal om dezelfde beperkte uren.
Dat deel van solo-ontwikkeling begrijp ik nu veel beter. De bottleneck is niet altijd hoe snel ik code kan schrijven. Het is hoeveel aandacht ik kan geven aan een groeiend aantal states, overgangen en failure modes in het product.
Een succesvolle build beantwoordt die vragen niet. Een succesvolle betaling ook niet.
Betalingen veranderden de betekenis van een bug
Voor betalingen kon ik bepaalde ruwe randjes nog zien als dingen die ik later zou repareren. Toen betalingen live gingen, werkte dat mentale model voor mij niet meer. Een betaald product hoeft niet bugvrij te zijn; dat is niet realistisch. Maar de kosten van een bekend, onopgelost probleem veranderen wanneer iemand anders al geld aan het product heeft toevertrouwd.
Hetzelfde geldt voor onboarding en moderatie. Tijdens de ontwikkeling kunnen die eruitzien als ondersteunende systemen rond de “echte” feature. In productie zijn ze onderdeel van de feature, omdat gebruikers ze direct ervaren. Voor retentie geldt iets vergelijkbaars: een goede eerste sessie bewijst niet dat het product iemand een reden geeft om terug te komen.
Betalingen bewezen niet dat het product af was. Ze lieten zien hoeveel werk het woord “af” had verborgen.
De launch gaf me een ander soort informatie
Na de release kwam het minder fotogenieke werk: bugs die pas na publicatie zichtbaar worden, kapotte flows, moderatieproblemen die pas echt worden als gebruikers arriveren, en retentievraagstukken die veel moeilijker zijn dan een goede eerste indruk maken.
Ik probeer zulke signalen niet te overinterpreteren. Een bug na de release betekent niet automatisch dat de architectuur slecht is. Een retentieprobleem is op zichzelf geen diagnose van product-market fit. Een moderatieprobleem bewijst niet dat het hele systeem onveilig is. Een symptoom vertelt me waar ik moet onderzoeken; het vertelt me niet automatisch de oorzaak.
Wat verandert, is de kwaliteit van het bewijs. Voor de launch kan ik testen wat ik verwacht dat gebruikers zullen doen. Daarna moet ik omgaan met wat ze daadwerkelijk doen. Een release is niet het moment waarop onzekerheid verdwijnt. Het is het moment waarop een deel van de belangrijkste onzekerheid eindelijk observeerbaar wordt.
De post-launch-loop die ik nu gebruik
Ik ben nu meer geïnteresseerd in het werk na de launch dan in het polijsten van het launchverhaal zelf: lessen rond betalingen, kapotte flows, moderatie-uitdagingen, gebruikersgedrag, verrassingen in retentie en kleine fixes die het product stap voor stap betrouwbaarder maken.
- Observeer de echte flow. Neem niet aan dat het pad dat ik heb ontworpen ook het pad is dat gebruikers daadwerkelijk volgen.
- Scheid symptomen van oorzaken. Een mislukte stap laat zien waar iets foutging, niet automatisch waarom.
- Geef voorrang aan fouten die vertrouwen raken. Betalingen, toegang, onboarding en moderatie zijn voor mij urgenter dan cosmetische onvolkomenheden, omdat de impact van falen groter is.
- Los eerst het kleinste bevestigde probleem op. Ik verwijder liever één bewezen bron van frictie dan een heel systeem opnieuw te ontwerpen rond een aanname.
- Controleer de gebruikerservaring opnieuw na de fix. Een codewijziging kan technisch correct zijn en toch het probleem van de gebruiker niet oplossen.
Dit is geen universeel framework. Het is simpelweg de werkwijze die voor mij het meest logisch is sinds ik van bouwen naar beheren ben gegaan.
De launch veranderde mijn bron van waarheid
Het onderscheid dat ik nu het belangrijkst vind, is tussen het product gebouwd hebben en klaar zijn om het product te beheren. Bouwen vraagt of het systeem kan doen waarvoor ik het heb ontworpen. Beheren vraagt wat er gebeurt wanneer echte mensen het gebruiken, verkeerd begrijpen, verlaten, terugkomen, betalen of een route nemen die ik niet had verwacht.
Daarom zie ik de launch niet meer als een finish. Voor de launch komt het meeste bewijs uit mijn eigen aannames en tests. Daarna begint het product terug te praten via echt gedrag, fouten en herhaald gebruik.