Bouwen was nooit de bottleneck — maar het deed drie andere klussen (2026)
By Surya Pratap
5 augustus 2026
12 min read
Startup Strategy
5 augustus 2026
12 min read
De meeste weken lees ik de populairste draadjes op r/SaaS en r/startups. Meestal is het een allegaartje: een lancering, een analyse van opzeggingen, iemands eerste $9. Deze week niet. Drie losse draadjes, vanuit drie totaal verschillende invalshoeken, bleken hetzelfde te beschrijven zonder dat iemand het doorhad.
Een bouwer schreef dat hij alles kan uitbrengen en geen enkel idee vindt dat het uitbrengen waard is. Iemand die in loondienst werkt, schreef dat ze, als een leverancier opschept dat iets in een weekend is gebouwd, een waarschuwing hoort. En een consultant wiens werk nu bestaat uit het redden van met vibe coding gebouwde producten, beschreef hoe hij een founder met tachtig betalende klanten zijn eigen app zag openen en rondklikken om te ontdekken wat er gebeurde als iemand halverwege de maand opzegde.
Los gelezen zijn dat een ideeënprobleem, een marketingprobleem en een kwaliteitsprobleem. Samen gelezen zijn ze één probleem, en het is niet het probleem waar de reacties op uitkwamen.
Dit is wat elk ervan werkelijk zei, voordat ik er een interpretatie aan geef.
| Draadje | Geschreven door | Punten | Reacties |
|---|---|---|---|
| "Ik ben de founders met 'ik heb dit in een weekend met AI gebouwd' zat" | Een medewerker aan de kopende kant | 306 | 102 |
| "Ik kan bijna alles bouwen. Ik vind geen enkel SaaS-idee dat het bouwen waard is." | Een sterke bouwer | 129 | 200 |
| "Ik kan alles bouwen. Ik heb geen idee hoe ik mensen het kan laten schelen." | Een founder die lanceerde in stilte | 84 | 108 |
| "Het grootste probleem van vibe coding is niet de beveiliging" | Een reddingsconsultant | 81 | 51 |
Twee ervan zijn dezelfde zin, getypt door twee verschillende mensen in twee verschillende subreddits op twee verschillende dagen: ik kan alles bouwen. Niemand in een van beide draadjes sprak het tegen. De onenigheid ging uitsluitend over wat er daarna komt, en de bovenste reacties splitsten zich netjes in "je hebt een ideeënprobleem" en "je hebt een distributieprobleem", met een terugkerend derde kamp dat volhield dat nee, bouwen eigenlijk nog steeds het moeilijke deel is en dat wie iets anders beweert er slecht in is.
Alle drie de kampen beschrijven een symptoom. Wat ze gemeen hebben, is nuttiger.
Software bouwen was traag en duur. Iedereen is het erover eens dat dat slecht was, en meestal was het dat ook. Maar traagheid deed naast het opleveren van de software drie andere klussen, en deed die onzichtbaar, gratis, of je dat nu wilde of niet.
Ze filterde je ideeën. Ze liet kopers zien hoe volwassen je was. En ze leerde je wat je eigen product deed.
AI haalde de kosten weg. Het verving de drie bijproducten niet. Dat is de hele vorm van de klachten van deze week, en daarom slaan de adviezen in de reacties steeds de plank mis: je lost een ontbrekend bijproduct niet op door harder te werken aan het ding dat het vroeger opleverde.
Toen bouwen je zes maanden of negentigduizend dollar kostte, kon je geen dertig ideeën hebben. De kosten deden de selectie voor je. Je koos het idee dat je om twee uur 's nachts tegenover jezelf kon verdedigen, en het pure gewicht van de verplichting dwong een mate van kritisch kijken af die voelde als oordeelsvermogen, maar vooral angst was.
Haal de kosten weg en de dwang verdwijnt mee. De bouwer in dat draadje beschreef zijn cyclus precies: brainstormen, op iets slims uitkomen, ontdekken dat tien bedrijven het al doen of dat niemand ernaar zoekt, een snelle versie bouwen, beseffen dat hij de gebruikers helemaal niet begrijpt, herhalen. Hij noemde het resultaat een kerkhof van half gebouwde slimme dingen. Wat opvalt, is dat hij het zelf goed diagnosticeerde: hij schreef dat hij ideeën verzint vanuit zijn stoel in plaats van ze te stelen uit een probleem waarin hij zelf leeft.
Dat klopt precies, en het is de moeite waard om helder te zijn over waarom. Bouwen is het comfortabele deel. Het heeft een definitie van klaar, het levert zichtbare vooruitgang op, en niemand zegt nee tegen je terwijl je ermee bezig bent. Er kwamen tweehonderd reacties om hem te vertellen dat hij met klanten moest praten, en dat wist hij al. Founders verstoppen zich niet in het bouwen uit onwetendheid. Ze doen het omdat bouwen het enige deel van het werk is dat inspanning betrouwbaar beloont met resultaat, en als het niets kost, kun je je er eindeloos in verstoppen.
De scherpste reactie in het draadje gooide de zoektocht volledig om. Maak geen inventaris van problemen, was het betoog — maak een inventaris van ergernissen. Niet "wat ontbreekt er", maar wat mensen stilletjes verdragen en nooit noemen, omdat het niet als een echt probleem voelt. De twintig minuten tegenzin voor een klantreview. De spreadsheet die iemand elke maandag opnieuw bouwt. Die duiken nooit op in een concurrentieanalyse, omdat er technisch niets kapot is. Daar zit de echte betalingsbereidheid.
Op dit bijproduct zijn founders het minst voorbereid, want het verdween niet maar keerde om.
Kopers hadden nooit een manier om je engineering te inspecteren. Wat ze hadden, was een indirect signaal: half gebouwde software zag er half gebouwd uit. Ruwe randen, ontbrekende toestanden, een lelijke instellingenpagina — die vertelden ongeveer hoeveel werk er nog restte, en kopers lazen dat vloeiend zonder ooit te benoemen dat ze dat deden. De afwerking was het bonnetje voor het overleven van de randgevallen.
Nu verschijnt de afgewerkt ogende schil op dag één. Het indirecte signaal is kapot, en de markt deed wat markten doen als een signaal kapotgaat: ze verving het door een grover signaal. De post met 306 punten is die vervanging hardop uitgesproken. De auteur, iemand in loondienst die tools op het bureau krijgt met de opdracht ze in het werk op te nemen, somde op waar het bedrijf echt voor betaalt — dat je er in maand zes nog bent, dat je onze data niet kwijtraakt, dat het ding elke keer hetzelfde doet — en sprak daarna de zin uit waarover het hele draadje het eens was: stop met opscheppen over de snelheid, want voor de mensen die je betalen klinkt dat als een waarschuwing.
De eerlijke kanttekening
Een groot deel van de reacties beschuldigde de post ervan door AI gegenereerd aas voor engagement te zijn, en vroeg de auteur één echt product te noemen dat hen in de steek had gelaten. Misschien hebben ze gelijk. Maar dat is geen reden om het draadje af te doen — het is hetzelfde verschijnsel een laag hoger. De beschuldiging komt aan omdat verzorgd ogende output nergens meer inspanning bewijst, ook niet in een Reddit-post. Het indirecte vertrouwenssignaal ging voor software en voor tekst tegelijk kapot, om dezelfde reden.
Het praktische gevolg is dat snelheid geen marketingtroef meer is, maar ongemerkt een last is geworden die je moet compenseren. Niets in je lanceringstekst zou moeten beginnen met hoe snel je het hebt gebouwd. Wat kopers nu zoeken, is bewijs van duur en van gevolgen: hoe lang je al draait, wat er gebeurt als er iets kapotgaat, wie er antwoordt, of hun data een slechte release overleeft. Een founder in het draadje stelde een maatstaf voor die het overnemen waard is: tel hoeveel supportgesprekken over hetzelfde probleem gaan dat een tweede keer terugkomt. Niet het aantal tickets. Herhalingen. Het is een genadeloze meting van welke delen van je product met plakband bij elkaar worden gehouden, en het maakt niet uit hoe snel je ze hebt uitgebracht.
Het draadje van de reddingsconsultant is het waardevolste van de vier en kreeg de minste aandacht, zoals dat meestal gaat.
Het verhaal: een founder bracht een boekingsproduct binnen dat hij in een paar weekenden met vibe coding had gebouwd. Het was echt goed, verzorgd, met zo'n tachtig betalende klanten. Toen vroeg een klant wat er met het ongebruikte deel van een abonnement gebeurt als je halverwege de maand opzegt, en de founder opende zijn eigen product en klikte rond om het uit te zoeken. Hij schaamde zich niet. Voor hem is dat gewoon hoe je ontdekt wat je product doet.
De manier waarop de consultant uitlegt waarom dit iets anders is dan technische schuld, is het deel om mee te nemen: schuld veronderstelt dat iemand de boeken kan lezen. Hier moet de founder, zodra een klant een bedrag betwist, gedrag aanpassen dat hij nooit heeft begrepen, en geen refactor dicht dat gat, omdat het gat nooit in de code zat. De reageerders kwamen uit op de naam begripsschuld.
Het mechanisme verdient een zorgvuldige formulering, want het is niet "AI schrijft slechte code". De code was in orde. Wat er gebeurde, is dat er een beslissing werd genomen en niemand wist dat er een beslissing werd genomen. Iemand — iets — moest beslissen wat een opzegging midden in een cyclus doet met een pro-ratasaldo. Het model besliste, zelfverzekerd, op een manier die er op het scherm aannemelijk uitzag, en de founder zag nooit een beslismoment. Zoals de consultant het in een latere reactie zei: schrijf eerst de beslissingen op, anders neemt het model ze voor je.
Zijn diagnose is het meest bruikbare uit alle vier de draadjes, en het kost ongeveer twintig minuten:
De vijfvragentest
Schrijf de vijf moeilijkste vragen op die een klant kan stellen over hoe je product zich gedraagt. Beantwoord ze zonder de app te openen. De vragen die je niet kunt beantwoorden, zijn de delen van het bedrijf die je nog niet in handen hebt.
Nog één detail uit hetzelfde draadje, van iemand die meerdere van deze reddingen heeft gedaan: bij facturatie zwerven er meestal drie versies van de waarheid rond — wat in de code staat, wat in Stripe staat, en wat de founder mensen in supportmails heeft verteld. Die drie met elkaar in overeenstemming brengen is meestal de redding. Het codewerk daarna is het makkelijke deel.
De founder op r/startups — het product werkt, een paar gebruikers zijn er dol op, geen idee hoe je iemand het laat schelen — kreeg 108 reacties, en de meeste zeiden in een paar woorden hetzelfde: zoek twintig mensen. Het is goed advies en het hielp niet, en de reden werd door één reageerder ongewoon precies benoemd: de meeste founders kunnen niet zeggen wie die twintig mensen zijn. Niet de sector, niet de persona. De specifieke situatie waardoor iemand dit vandaag nodig heeft in plaats van volgend kwartaal.
Het verschil tussen "operationele mensen bij SaaS-bedrijven" en "operationele mensen die net hun eerste SDR hebben aangenomen en beseffen dat ze geen proces hebben" is het verschil tussen een kanaal dat je koud kunt gaan opzoeken en een categorie waarin je alleen kunt adverteren. Alles daarna — tekst, kanaal, timing — is bijzaak.
Er kwam ook een goed antwoord op het echte bezwaar van de founder, namelijk dat posten voelt als optreden en dat hij het slecht doet. Twee reageerders, onafhankelijk van elkaar: stop met uitzenden en begin met reageren. Ga naar waar het probleem wordt besproken en beantwoord vragen, de meeste zonder enig verband met je product. Reageren is niet op een podium staan. En daarnaast: vraag het handjevol mensen dat je product al gebruikt in welk draadje, forum, Slack of subreddit ze zaten op het moment dat het probleem hen genoeg ergerde om te gaan zoeken. Dat geeft je drie echte plekken in plaats van een contentstrategie.
Als de diagnose is dat drie dingen die je vroeger gratis kreeg nu bewust moeten worden gekocht, dan is het werk om elke aankoop in te plannen. Concreet:
De reacties waren de hele week in discussie over de vraag of het moeilijke deel bouwen, ideeën bedenken of verkopen is. Dat is een slechte discussie, omdat het antwoord steeds verandert en het nooit de interessante vraag was. De interessante vraag is waar een kostenpost stilletjes voor betaalde voordat hij wegviel.
Zes maanden bouwen kocht je vroeger een gefilterd idee, een geloofwaardig product en een werkend mentaal model van je eigen bedrijf. Je betaalde voor één ding en kreeg er vier. Nu betaal je voor niets en krijg je er één, en de andere drie moeten bewust worden verworven, door mensen die meestal niet weten dat ze ontbreken.
Dat is de echte foundervaardigheid in 2026. Niet prompten, niet de snelheid van uitbrengen — opmerken welke van je oude gratis bijproducten niet meer binnenkomen, en ze gaan terugkopen voordat een klant ontdekt dat je ze nooit had.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
