Vibe Coding Dag 12, Misschien de laatste thread hier. Ik heb 100 uur besteed aan het bouwen van een commerciële app met vibe coding. Enkele observaties uit de ervaring. Mijn top 13 lessen om jou te helpen -- vibe code je eigen app. Een thread🧵

Opmerking: Ik ben medeoprichter van een baanbrekende SaaS die is gegroeid naar $200M ARR, dus hoewel ik geen ingenieur ben en sinds de middelbare school niet echt heb gecodeerd (en dat telt eigenlijk niet) -- heb ik wel context over wat commerciële software vereist. Ik hou van deze apps. Maar als je echt ervoor gaat, weet dan hun beperkingen. Tenminste, hun beperkingen vandaag. Dingen veranderen zo snel, deze lessen zullen zeker zelfs binnen 90 dagen verouderd zijn.

1/13: Begin met een wegwerp-hack. Besteed maximaal 60 minuten aan het vertellen aan een vibe coding app over je wildste productdromen zonder enige planning. Kijk wat er naar voren komt. Maar commit je van tevoren om het weg te gooien—dit is niet je echte product, het is je opleiding. Dat eerste uur zal je meer leren over de mogelijkheden en beperkingen van het platform dan welke tutorial dan ook.

2/13: Voordat je enige code schrijft, besteed een volle week aan het bestuderen van 20 productie-apps die zijn gebouwd op vibe-codingplatforms. Geen casual browsen—gebruik daadwerkelijk apps die live zijn, betalingen verwerken en echte klanten bedienen. Je bent op zoek naar wat echt mogelijk is op schaal en waar de beperkingen het hardst toeslaan. Deze verkenning bespaart weken van frustratie later.

3/13: Definieer je productievereisten voordat je begint met bouwen. Vraag: 1⃣ Hoe veilig moet dit zijn? 2⃣ Wie gaat het onderhouden na de lancering? 3⃣ Moet het kunnen opschalen naar 100 gebruikers of 100.000? 4⃣ Heb je een andere vibe-gecodeerde app in productie gevonden, met betalende klanten, op jouw complexiteitsniveau? Als je geen solide antwoorden hebt, stop dan met bouwen en begin met onderzoeken.

4/13: Schrijf de meest gedetailleerde specificatie die je kunt beheren. Kaart elke pagina, workflow, permissieniveau in. Definieer e-mailsystemen, dashboards, gebruikersbeheerflows expliciet. Ja, dit lijkt tegenintuitief voor natuurlijke taal prompts, maar het dwingt je om na te denken over randgevallen en wordt je leidraad wanneer AI ongewenste functies voorstelt.

5/13: Sommige functies lijken eenvoudig in demo's, maar worden engineering-nachtmerries. Voorbeelden vandaag tenminste (en dit verandert voortdurend): ▶️ betrouwbare e-mailbezorging ▶️ OAuth/identiteitsbeheer ▶️ media-generatie ▶️ native mobiele apps ▶️ aangepaste ontwerpen buiten sjablonen ▶️ enterprise beveiliging. Deze veroorzaken consequent pijn op verschillende platforms. Plan extra tijd of overweeg of ze daadwerkelijk noodzakelijk zijn voor MVP. Vind een ervaren engineer die op jouw platform heeft gebouwd en VRAAG het hen. VRAAG het hen.

5/13: Sommige functies lijken eenvoudig in demo's, maar worden echt grote technische uitdagingen. Voorbeelden vandaag tenminste (en dit verandert voortdurend): ▶️ betrouwbare e-mailbezorging ▶️ OAuth/identiteitsbeheer ▶️ media-generatie ▶️ native mobiele apps ▶️ aangepaste ontwerpen buiten sjablonen ▶️ enterprise beveiliging. Deze veroorzaken consequent pijnpunten op verschillende platforms. Plan extra tijd of overweeg of ze echt noodzakelijk zijn voor MVP. Veronderstel niet dat je statische demo die deze dingen goed lijkt te doen, ze ook echt goed doet. Vind een ervaren engineer die op jouw platform heeft gebouwd en VRAAG het hen. VRAAG het hen.

6/13: AI-systemen fabriceren gegevens wanneer ze falen. Iedereen die aan EENENIGE vibe-codingplatform heeft gewerkt, inclusief Claude Code, weet dit. Het is een bug, maar ook een functie. Zonder dit kunnen ze geen problemen oplossen. Een AI op ELK platform zal, wanneer het tegen obstakels aanloopt, fictieve gegevens genereren. Dit is geen bug—ze zijn getraind om output te geven in plaats van falen toe te geven. Na meerdere mislukte pogingen zullen ze overtuigende nepgegevens creëren in plaats van te zeggen "Ik kan dit niet doen." Je moet dit begrijpen, accepteren en eromheen werken. Dit zal tijd kosten.

7/13: Besteed je eerste volledige dag aan het leren van elke functie van het platform, niet aan bouwen. Deze platforms bevatten enorme functionaliteit in hun interfaces. Elk pictogram, menu-optie en functie bestaat om een reden. Je kunt geen mogelijkheden benutten die je niet weet dat ze bestaan. Dit is geen optionele research—het is essentiële kennis voor commerciële apps. Er is niet altijd een oplossing voor elke uitdaging. Maar de platforms hebben meer oplossingen dan je in eerste instantie denkt. En ze zijn een beetje nerdy. Op een goede manier, maar nerdy. Diep van binnen zijn ze gebouwd voor ontwikkelaars, ongeacht wat de marketing zegt. Accepteer dat en leer ELKE functie kennen voordat je begint. Als je een functie, een pictogram of een acroniem niet begrijpt, STOP. Ga het nu onderzoeken. Niet later.

8/13: Beheers rollback-systemen op de eerste dag, voordat je ze wanhopig nodig hebt. De meeste platforms bieden elegante versiecontrole, vergelijkbaar met opsla-punten in videogames. Oefen met het opzettelijk terugrollen terwijl de inzet laag is. Begrijp precies hoe het werkt, wat bewaard blijft, wat verloren gaat. Dit wordt je meest waardevolle debugtool.

9/13: AI zal wijzigingen aanbrengen die je niet hebt aangevraagd. Het zal gewoon gebeuren. Het zal gevestigde functies aanpassen, ongewenste functionaliteit toevoegen, werkende code breken terwijl het iets anders "verbeterd". Verdediging: Voeg "GEEN WIJZIGINGEN ZONDER VRAAG" toe aan elke prompt. Wanneer je het over wijzigingen hebt, zeg dan "GEEN WIJZIGINGEN. GEEN CODE. GEWOON DISCUSSIE." Vermindert ongewenste aanpassingen met ~80%. Maar het stopt ze niet. Dit is waar voor elk platform. Uiteindelijk draaien ze allemaal op Claude -- meestal. Ze hebben allemaal verschillende niveaus van dezelfde problemen daaruit. Ze zullen >allemaal< wijzigingen aanbrengen die je niet hebt aangevraagd. Het is gewoon zo dat de meer prosumer-apps verder zullen gaan, aangezien de ontwikkelaarsgerichte codeer-apps meer geïsoleerd zijn in termen van de wijzigingen die ze aanbrengen.

10/13: Leer je applicatie te forkeren wanneer deze een stabiele complexiteit bereikt. In het begin lossen rollbacks de meeste problemen op. Maar naarmate je app complexer wordt, weet je misschien niet naar welke versie je moet terugrollen. Fork op stabiele momenten om veilige experimenteertakken te creëren terwijl je bekende goede versies behoudt. Denk aan verzekeringspolissen.

11/13: Budget 150 uur over een volle maand om commerciële kwaliteit te bereiken. Misschien meer. ▶️Die 20-minuten prototype is 5% van je daadwerkelijke werk. ▶️Meer dan de helft van je tijd zal besteed worden aan testen, debuggen, verfijnen. De initiële opbouw is eenvoudig—het betrouwbaar, veilig en gebruiksvriendelijk maken vereist de meeste inspanning. Laat je niet misleiden door de snelheid van de demo.

12/13: Accepteer je nieuwe rol als QA-engineer. Zodra je dagen bezig bent met serieuze ontwikkeling, verwacht dan een dagelijkse routine van: ▶️ het maken van bug-screenshots ▶️ het schrijven van gedetailleerde rapporten voor AI ▶️ het testen van gedeeltelijke oplossingen ▶️ het opnieuw testen van randgevallen ▶️ het documenteren van nieuwe problemen ▶️ het uitvoeren van unittests op je fork Dit is geen vibe-codingbeperking—het is de realiteit van softwareontwikkeling. Platforms behandelen de codering; QA blijft menselijk werk. De platforms doen ... iets. Maar slechts iets. Je kunt niet op hen vertrouwen om je QA alleen te doen.

13/13: Plan je exitstrategie vanaf dag één. De meeste commerciële apps groeien uiteindelijk uit de prosumer vibe coding platforms vanwege schaal, aanpassingsmogelijkheden of beveiligingsbehoeften. Opties: 1⃣platformcode-export 2⃣hybride aanpak 3⃣volledige herbouw, of ... 4⃣blijven en opschalen. De waarheid is, bij de prosumer apps van vandaag, verlaat de meeste mensen. Niet allemaal. Maar de meeste die echte commerciële apps bouwen. Voor nu. Dit betekent niet dat jij dat ook moet doen. Maar heb >opties< wanneer je begint. Heb ... een exitplan als je het nodig hebt. Documenteer de bedrijfslogica, onderhoud de specificaties, evalueer regelmatig. Als je app complex wordt, kan het uiteindelijk gemakkelijker zijn om te vertrekken dan om te werken rond de accumulerende beperkingen.

Vibe-codingplatforms zijn echt magisch voor bepaalde soorten toepassingen—en echt onvoldoende voor andere. Jouw taak is uit te zoeken in welke categorie jouw project valt voordat je te diep zit om van koers te veranderen. Dit zijn krachtige tools met specifieke beperkingen, geen vervangers voor het begrijpen wat commerciële software vereist. Het zijn tools. Geen ontwikkelteams. Herinner jezelf daar elke dag aan.

De platforms zullen zich snel blijven ontwikkelen. Wat vandaag onmogelijk is, kan over zes maanden eenvoudig zijn. Maar op dit moment, beschouw "prosumer" vibe coderen zonder code aan te raken als net zo waarschijnlijk een brug naar traditionele ontwikkeling voor commerciële apps ... dan als een eindtoestand. Gebruik het om je markt te valideren, vereisten te verfijnen, initiële inkomsten te genereren—en maak dan weloverwogen beslissingen op basis van echte beperkingen, niet theoretische mogelijkheden.

12 dagen van vibe coding voelt als ... 12 weken. De late nachten met debuggen, de dopaminehits wanneer iets eindelijk werkt, de frustratie wanneer het weer kapot gaat. Het is een van de meest intense leerervaringen die ik in jaren heb gehad. Voor mij is het tijd om een stapje terug te doen en meer te plannen, meer na te denken. Ik heb enkele van mijn nieuwe favoriete apps gevonden. Maar ik heb ook geleerd dat zelfs ik het allemaal veel beter moet leren. Hopelijk helpt dit je.

Code: heel enthousiast dat we @dharmesh hebben geïnspireerd om hier groot in te gaan!!

Coda: Super enthousiast dat onze reis @dharmesh heeft geïnspireerd om te kopen en een hele gemeenschap hier te starten!

@dharmesh Dag 11 hier: