Een van de meest verrassende lessen bij het bouwen van een SaaS is dat het moeilijkste deel vaak pas begint zodra het product echt werkt. Code schrijven, features uitrollen, bugs oplossen en deployen zijn concrete taken. Er is een duidelijk probleem, een duidelijk systeem en meestal ook een duidelijke volgende stap.
Klanten krijgen is iets totaal anders. Distributie is rommeliger. Positionering is vager. Messaging vraagt gevoel. Kliks, CTR, retentie en conversie dwingen je om niet alleen als engineer te denken, maar ook als marketeer, schrijver, onderzoeker en iemand die menselijk gedrag begrijpt.
Lanceren is nog maar het begin
Veel ontwikkelaars onderschatten dit, omdat software direct feedback geeft. Een knop werkt of werkt niet. Een deployment slaagt of faalt. Marketing werkt zelden zo. Je kunt iets doordachts publiceren en toch genegeerd worden. Je kunt een nuttig product bouwen en nog steeds moeite hebben om uit te leggen waarom iemand het belangrijk zou moeten vinden.
Die kloof is extra frustrerend als je solo bouwt. Het voelt alsof je naast je eerste vak ook nog een tweede beroep vanaf nul moet leren. En daar wordt in eerlijke SaaS-gesprekken nog steeds te weinig over gesproken.
Distributie heeft een andere feedbackloop
Dat verschil is belangrijk, omdat marketingmetrics signalen zijn en geen kant-en-klare verklaringen. Een klik of een verandering in CTR kan me vertellen dat er iets is veranderd, maar niet vanzelf of dat door de doelgroep, het kanaal, de boodschap, de timing of het product kwam. Retentie en conversie zijn om dezelfde reden nuttig: ze maken de vraag smaller, maar beantwoorden die niet voor me. Het werk zit in het interpreteren van het signaal en bepalen wat ik daarna probeer.
Waarom het creatieve deel moeilijker voelt
- Code beloont logica en structuur.
- Distributie hangt af van aandacht, timing, vertrouwen en herhaling.
- Goede messaging klinkt vaak eenvoudig, maar om die eenvoud te bereiken zijn veel iteraties nodig.
- Zelfs sterke AI-tools helpen sneller met code dan met originele positionering of creatief werk dat echt menselijk klinkt.
Dat laatste is op dit moment bijna grappig. AI kan enorm nuttig zijn wanneer een taak technisch en duidelijk afgebakend is. Maar zodra het werk creatief, genuanceerd of sterk afhankelijk van toon wordt, kan de output ongemakkelijk aanvoelen. Dat contrast laat goed zien hoeveel menselijk oordeel nog steeds waard is.
Ik lees dit niet als bewijs dat AI geen creatief werk kan doen. Mijn conclusie is smaller: in mijn gebruik vertrouw ik AI het makkelijkst wanneer de taak afgebakend is en het resultaat controleerbaar. Positionering en tone of voice hebben geen equivalent van een typechecker. Ik moet nog steeds zelf bepalen of het resultaat concreet, geloofwaardig en passend voor het publiek is.
Wat ‘shippen’ voor mij nu betekent
Dit veranderde hoe ik naar het lanceren van een SaaS kijk. Een product kan live en technisch gezond zijn terwijl het distributieprobleem vrijwel onaangeraakt blijft. Na de launch begint een tweede lus: uitleggen voor wie het product is, de juiste mensen helpen het te vinden, kijken wat ze doen en zowel de boodschap als het product aanpassen. Voor een solo-ontwikkelaar concurreert dat werk om dezelfde beperkte aandacht als engineering.
Wat ik voor een volgende launch zou onthouden
- Kan ik duidelijk uitleggen voor wie het product is en waarom die mensen erom zouden moeten geven?
- Waar gaan de eerste gebruikers het daadwerkelijk ontdekken?
- Welke signalen volg ik — kliks, CTR, conversie, retentie — en wat kan elk signaal mij op zichzelf niet vertellen?
- Behandel ik AI-output als een concept dat ik moet beoordelen, in plaats van als vervanging van mijn oordeel?
Dit is geen universele regel
Ik beweer niet dat klantacquisitie voor elke SaaS altijd moeilijker is dan engineering. Sommige producten hebben zware technische beperkingen; andere hebben al distributie. Mijn punt is smaller: voor een ontwikkelaar die comfortabel software bouwt, kan het werk na de launch een ander pakket vaardigheden en een veel minder deterministische feedbackloop vereisen. In mijn geval was dat het meest verrassende deel.
Mijn praktische conclusie is simpel: lanceren is niet de finish. Klantacquisitie, positionering, messaging en retentie zijn echte vaardigheden in productontwikkeling. Ze zijn langzamer te leren en lastiger te debuggen dan code omdat de feedback veel rumoeriger is, maar negeren laat ze niet verdwijnen.