Een app bouwen met vibe coding: van idee tot gepubliceerde app

Om een app met vibe coding te bouwen schrijf je een beschrijving van één pagina van de eerste versie, geef je die als eerste prompt aan een AI-app-builder, en laat je de app daarna groeien in kleine, geteste stappen: data, login, de belangrijkste workflow, afwerking, een beveiligingscontrole en tot slot publiceren. Deze gids volgt één voorbeeldproject, een boekingsapp voor de lessen van een kleine yogastudio, door elke fase heen, met de prompts die bij elke stap horen.

Als je nog nooit op deze manier iets hebt gebouwd, begint onze vibe coding-tutorial voor beginners kleiner. Voor een breder overzicht dat niet aan vibe coding vastzit, zie hoe je een app met AI bouwt.

Het project

Stel je een yogastudio-eigenaar voor, Sara, die acht lessen per week geeft. Boekingen komen binnen via WhatsApp; zij houdt per les een papieren lijst bij en overboekt vaak. Ze wil:

• Dat cursisten het lesrooster van de week zien en een plek boeken.
• Dat elke les een capaciteit heeft.
• Een lijst per les die ze bij de deur kan controleren.
• Dat cursisten tot twee uur van tevoren kunnen annuleren.

Dat is de hele eerste versie. Geen betalingen, geen abonnementen, geen appstore. Die komen later, of nooit.

Stap 1: Schrijf een spec van één pagina

Voordat je een tool opent, schrijf je de eerste versie in gewone woorden op. Tien minuten hier besparen uren heen-en-weer. Een bruikbare opzet:

• Wie gebruikt het: cursisten (boeken en annuleren), Sara (lessen beheren, lijsten bekijken).
• Schermen: rooster, lesdetail, mijn boekingen, beheer lessen, beheer lijst per les.
• Data: lessen (naam, docent, starttijd, duur, capaciteit), boekingen (cursist, les, status), cursisten (naam, e-mail, telefoon).
• Regels: geen boeking van een volle les; één boeking per cursist per les; annuleren tot twee uur van tevoren; alleen Sara ziet de beheerpagina’s.
• Niet in v1: betalingen, lespakketten, wachtlijsten, herinneringen.

De lijst “niet in v1” is het belangrijkst. Die zorgt dat de bouw afgemaakt kan worden. Onze gids over een product requirements-document schrijven met AI gaat verder als je een uitgebreidere spec wilt.

Stap 2: Kies een tool die de hele lus afhandelt

Voor een app met een database, logins en een publieke URL gebruik je een AI-app-builder die de code draait, een database koppelt en publiceert, in plaats van een chatassistent die je bestanden geeft. Onze vergelijking van vibe coding-tools somt de opties op. Wij gebruiken hier Mythex, omdat het elke stap op één plek dekt: chat, live preview, een echte database en bestandsopslag, en publiceren met één klik.

Stap 3: De eerste prompt

Zet de spec om in één alinea. Plak niet meteen het hele document met alle details; geef de kern en voeg de rest stapsgewijs toe.

Bouw een boekingsapp voor mijn yogastudio. Cursisten melden zich aan met naam, e-mail en telefoon, zien het rooster van deze week en boeken een plek in een les. Elke les heeft een naam, docent, starttijd, duur en capaciteit; een volle les toont “Vol” en kan niet geboekt worden. Cursisten zien hun boekingen en kunnen tot twee uur van tevoren annuleren. Ik ben de beheerder: ik kan lessen toevoegen en bewerken en de lijst zien van wie er voor elke les geboekt is. Rustig, eenvoudig ontwerp dat goed werkt op telefoons.

Als je niet zeker weet of de tool het goed heeft begrepen, vraag dan eerst om een plan. In Mythex laat de modus Plan de schermen en data zien voordat er code wordt geschreven, en die keur je goed.

Stap 4: Krijg de kernlus werkend

De kernlus is het ene waarvoor de app bestaat: een cursist boekt een les, en Sara ziet het. Test alleen dat:

1. Meld je aan als cursist en boek een les.
2. Open de beheerweergave. Staat de boeking erin?
3. Boek dezelfde les nogmaals. Het moet weigeren.
4. Zet de capaciteit van een les op 2, boek hem vanuit twee cursistaccounts en probeer een derde.

Op dit punt duiken meestal twee problemen op. Het rooster toont tijden in de tijdzone van de server, niet die van de studio. En de controle “Vol” gebeurt alleen op de pagina, dus een snelle dubbelklik maakt twee boekingen.

Toon alle lestijden in de tijdzone van de studio, [Asia/Dubai], ongeacht hoe het apparaat van de bezoeker is ingesteld.

Controleer capaciteit en dubbele boekingen op de server op het moment dat een boeking wordt gemaakt, niet alleen op de pagina. Als twee verzoeken tegelijk binnenkomen voor de laatste plek, mag er maar één slagen.

Repareer de kernlus voordat je iets toevoegt. Alles hangt ervan af.

Stap 5: Voeg de overige regels toe, één per bericht

Loop nu de regels uit de spec één voor één langs:

Cursisten kunnen een boeking annuleren tot twee uur voordat de les begint. Verberg daarna de annuleerknop en weiger de annulering op de server met een duidelijke melding.

Alleen mijn account kan de beheerpagina’s openen. Zorg dat dit bij elke beheeractie op de server wordt gecontroleerd, niet alleen door het menu te verbergen.

Test na elke wijziging en ga pas verder als het werkt. Als een wijziging iets breekt, ga dan terug naar het laatste goede checkpoint en probeer een duidelijker verzoek, in plaats van fixes op elkaar te stapelen.

Stap 6: Werk af wat echte gebruikers zullen opmerken

Echte gebruikers merken kleine dingen. Een korte lijst voor Sara’s app:

• Lege staten: “Nog geen lessen deze week” in plaats van een lege pagina.
• Bevestiging: “Je bent geboekt voor Vinyasa, dinsdag 18:00” na het boeken.
• Telefoonlayout: grote knoppen, het rooster leesbaar op een scherm van 375 px.
• Vrije plekken: “3 plekken over” op elke leskaart, zodat cursisten sneller boeken.

Toon op elke leskaart het aantal vrije plekken, bijvoorbeeld “3 van 12 vrij”. Toon na het boeken een bevestiging met de naam van de les, dag en tijd, en een knop naar mijn boekingen.

Stap 7: Test als een vreemde

Voordat iemand anders het gebruikt, besteed je een half uur aan proberen het kapot te maken:

Je kunt de AI ook vragen randgevallen door te lopen:

Noem tien dingen die een echte cursist zou kunnen doen waardoor boeken of annuleren kan breken, test elk ervan en repareer wat faalt. Vertel me wat je hebt veranderd.

Stap 8: Een beveiligingscontrole

Deze app slaat namen, e-mailadressen en telefoonnummers op, dus een korte beveiligingscontrole is de moeite waard. De belangrijkste vragen:

• Kan één cursist de boekingen of contactgegevens van een ander zien?
• Staan er sleutels of wachtwoorden in code die in de browser draait?
• Is het aanmeldformulier beschermd tegen bots?
• Is er een back-up van de data?

Onze pagina over of vibe coding veilig is legt elke controle uit en geeft prompts ervoor, en de beveiligingschecklist voor met AI gebouwde apps is de lange versie.

Stap 9: Publiceren

Wanneer de kernlus, de regels en de controles slagen, publiceer je. Op Mythex is dat één klik, en de app krijgt een publieke URL met de database en hosting al ingericht. Op Pro kun je een eigen domein koppelen, zoals book.sarasyoga.com; zie hoe je een eigen domein koppelt.

Controleer de gepubliceerde versie nog eens voordat je de link verstuurt. Boek een les vanaf je telefoon. Productie en preview horen zich hetzelfde te gedragen, maar bevestig het.

Stap 10: Eerste gebruikers en de volgende versie

Geef de link eerst aan vijf vaste cursisten, niet aan allemaal. Vraag hen hun volgende les via de app te boeken en je te vertellen wat verwarrend was. Repareer daarna de top drie van wat ze noemen.

Na een paar weken echt gebruik schrijft een v2-lijst voor zo’n app zichzelf meestal: een wachtlijst voor volle lessen, e-mailherinneringen de avond ervoor, en lespakketten die online betaald worden. Elk onderdeel krijgt dezelfde aanpak: beschrijf het in een paar regels, prompt het, test het, publiceer. Voor het toevoegen van betalingen, zie hoe je betalingen aan je app toevoegt. Voor het bekendmaken, hoe je een app lanceert en de eerste gebruikers krijgt.

Er een telefoon-app van maken

Veel studio’s willen een icoon op de telefoons van hun cursisten. Op Mythex Pro kan de gepubliceerde app worden omgezet naar een Android-app (een bestand dat je naar Google Play kunt uploaden) en een iPhone-app die met je eigen App Store Connect-sleutel naar TestFlight wordt gestuurd, zonder Mac. De telefoon-app opent de gepubliceerde webapp, dus elke keer dat je een update publiceert, heeft de telefoon-app die ook.

Wat je hieruit meeneemt

De bouw zelf was het korte deel. Wat de app bruikbaar maakte, was de lijst “niet in v1” uit de spec, het testen van de kernlus voor al het andere, regels op de server voor capaciteit en toegang, en vijf echte gebruikers voordat het er vijftig worden. Zo ziet vibe coding eruit wanneer de app voor andere mensen moet werken.

Klaar om het zelf te proberen? Schrijf je spec van één pagina en plak de eerste alinea in de AI-app-builder. Wil je meer app-types en de prompts erachter zien, lees dan onze voorbeelden van vibe coding.

Veelgestelde vragen