Zelf een app maken met AI: tot waar kom je, en dan?

Met Lovable, Bolt of Replit maak je zonder programmeerkennis een werkend prototype: schermen, een database en soms een inlog. Dat is genoeg om je idee te testen bij echte gebruikers. Een app waar mensen hun gegevens aan toevertrouwen, die betalingen verwerkt of in de App Store moet, bouw je meestal niet zonder developer af. Stop met doorbouwen zodra je weet wat je wilde weten, en draag het prototype netjes over: code op GitHub, accounts op jouw naam en een lijst van wat nog nep is.

Kun je zelf een app bouwen met AI? Het eerlijke antwoord

Ja, tot op zekere hoogte. Met een AI-appbouwer beschrijf je in gewone taal wat je app moet doen, en de tool bouwt schermen, een database en de logica ertussen. Je hoeft niet te kunnen programmeren. Binnen een paar dagen heb je iets wat je op je telefoon kunt laten zien en wat mensen echt kunnen gebruiken.

Die manier van bouwen heet ook wel vibe coding: je beoordeelt alleen of het werkt en leest de code niet. Wat dat betekent en waar het misgaat, lees je in vibe coding uitgelegd.

Waar je meestal niet zonder hulp komt, is de stap naar een app die mensen jarenlang vertrouwen. Dan gaat het om beveiliging, privacy, betalingen, de keuring van Apple en Google en onderhoud. Een echte app laten bouwen kost in Nederland grofweg € 5.000 tot € 25.000 voor een eenvoudige app en € 60.000 tot € 150.000 of meer voor een complexe. Welke posten dat bepalen, lees je in app laten maken: kosten en doorlooptijd.

De slimme route zit ertussen: bouw met AI een prototype dat één vraag beantwoordt, en laat het fundament daarna door een vakmens leggen.

Welke AI-appbouwer past bij jouw idee?

De drie bekendste bouwers lijken op elkaar, maar verschillen in wat ze opleveren. Stand oktober 2026:

Alle drie hebben een gratis versie om te proberen. Voor serieus bouwen betaal je een abonnement plus verbruik, vaak in credits: tegoed dat per opdracht afgaat. Prijzen en limieten veranderen vaak; wat Lovable in de praktijk kost, staat in Lovable kosten en ervaringen.

Werk je liever met bestanden op je eigen computer, dan kun je ook een codeer-agent gebruiken, zoals Claude Code of Codex. Dat geeft meer controle, maar vraagt meer technisch inzicht.

Kies je bouwer op het eindpunt. Moet je app uiteindelijk in de App Store, dan heeft het weinig zin om een prototype te maken in een tool die alleen web-apps bouwt. Is een web-app genoeg, dan houd je het juist simpel.

Stap voor stap: een prototype dat iets bewijst

Een prototype is geen kleine versie van je app. Het is een test. Bouw het daarom rond één vraag die je wilt beantwoorden.

1. Schrijf je hypothese op. Eén zin: [doelgroep] wil [taak] doen met mijn app in plaats van met [huidige oplossing]. Dat is wat je gaat testen.
2. Schets de drie tot vijf belangrijkste schermen. Op papier is prima. Welke knoppen, in welke volgorde? Hoe je dat aanpakt, lees je in wat is een wireframe.
3. Laat de AI eerst plannen. Vraag om een plan voordat er gebouwd wordt (zie de prompt hieronder).
4. Bouw alleen de kernroute. Eén taak van begin tot eind. Instellingen, profielfoto's en een beheerscherm komen later.
5. Gebruik testgegevens. Verzin namen en e-mailadressen. Zet geen echte klantgegevens in een prototype.
6. Laat vijf tot tien mensen uit je doelgroep een taak uitvoeren. Kijk mee, help niet, schrijf op waar ze twijfelen.
7. Schrijf op wat je hebt geleerd. Klopte je hypothese? Wat moet anders? Dat lijstje is het echte resultaat.

Een goede eerste prompt, de opdracht die je in de chat typt, ziet er zo uit:

Ik bouw een prototype voor [doelgroep]. Het doel is testen of ze [taak] willen doen in een app. Schrijf nog geen code. Stel eerst vijf vragen over hoe de app gebruikt wordt. Maak daarna een plan met maximaal vijf schermen, de gegevens die worden opgeslagen en de route die een gebruiker aflegt. Gebruik alleen testgegevens. Laat alles weg wat niet nodig is voor deze ene taak.

De taakverdeling is daarbij steeds hetzelfde:

Wanneer stop je met zelf doorbouwen? Zeven signalen

De verleiding is groot om na een geslaagde test gewoon door te bouwen. Soms kan dat. Maar dit zijn de signalen dat het tijd is voor een developer:

1. Elke aanpassing breekt iets anders. Je lost een fout op en er verschijnen er twee. Dan overziet niemand meer het geheel.
2. Je credits gaan op aan herstelwerk. Als je meer betaalt voor repareren dan voor nieuwe functies, betaal je voor rondjes.
3. Er komen echte gebruikers met echte gegevens. Vanaf het eerste echte e-mailadres ben jij verantwoordelijk onder de AVG.
4. Er moet betaald worden. Abonnementen, betalingen en facturen vragen code die je kunt vertrouwen.
5. De app moet in de App Store of Google Play. Dan krijg je te maken met keuringen, updates voor nieuwe versies van iOS en Android en developeraccounts.
6. Je app moet koppelen met andere systemen. Je boekhouding, je CRM of je betaalprovider. Elke koppeling is een plek waar het mis kan gaan.
7. Je kunt niet uitleggen waar de gegevens staan. Weet je niet welke tabellen er zijn en wie erbij kan, dan is het tijd voor iemand die dat wel kan.

Herken je er twee of meer, stop dan met bouwen en loop eerst de controles in vibe coding security na, of laat ze uitvoeren.

Doorbouwen of opnieuw beginnen?

Dit is de vraag die ondernemers het liefst ontwijken, omdat er al zoveel tijd in zit. Toch is het eerlijke antwoord: dat hangt af van hoe het prototype gebouwd is, en dat kan alleen iemand beoordelen die de code leest.

Signalen dat doorbouwen kan:

• de code staat netjes in GitHub, met een geschiedenis van wijzigingen;
• de app gebruikt gangbare techniek die veel developers kennen;
• er is een duidelijke database met toegangsregels per tabel;
• het prototype doet al wat de echte app moet doen, alleen minder uitgebreid.

Signalen dat opnieuw beginnen goedkoper is:

• dezelfde logica staat op meerdere plekken, net iets anders;
• er zijn geen toegangsregels, of niemand weet of ze kloppen;
• het prototype is een web-app terwijl je een app voor de App Store nodig hebt;
• het prototype was een test, en de test leverde nieuwe inzichten op die alles veranderen.

Opnieuw beginnen klinkt als weggegooid geld. Dat is het meestal niet. Het geld zat in leren, en dat heb je gedaan. De schermen, de testresultaten en de keuzes neem je allemaal mee.

De overdrachtslijst voor je developer

Hoe beter je overdraagt, hoe sneller een developer kan zeggen wat het kost. Zorg dat je dit klaar hebt voordat je een gesprek plant:

• De code op GitHub, in een repository op jouw naam of die van je bedrijf. Geef de developer toegang, geen kopie per mail.
• Alle accounts op eigen naam: je domein, hosting, database (Supabase of Lovable Cloud), de bouwer zelf, je e-maildienst en, als het een mobiele app wordt, je Apple Developer- en Google Play-account.
• Een lijst van sleutels en koppelingen. Welke diensten zijn gekoppeld, zoals betalen, mail of AI? Stuur de sleutels zelf nooit per mail of chat, en laat ze na de overdracht vernieuwen.
• Wat echt werkt en wat nep is. Testgegevens, knoppen die nog niets doen, berekeningen die vastgezet zijn.
• Je testresultaten. Wat deden gebruikers, waar liepen ze vast, wat vroegen ze?
• Je schetsen en de belangrijkste beslissingen. Waarom koos je voor deze opbouw?
• Wat er met persoonsgegevens gebeurt. Welke gegevens worden opgeslagen en in welke regio staat je database?

Wil je je code en data uit Lovable meenemen, lees dan Lovable exporteren. Daar staat ook welke accounts je overzet.

Dit zijn de vragen die ik iemand met een zelfgebouwd prototype zou stellen. Welk probleem lost het op, en voor wie? Wat heb je getest en met hoeveel mensen? Wat moet de app over een jaar kunnen? En wie heeft de code en de accounts in handen? Weet je die antwoorden, dan wordt het gesprek kort en concreet.

Wat Koach laat zien: een app is meer dan code

Hoeveel werk er na een prototype komt, zie je aan Koach, een app voor volleybalcoaches. Ik ontwierp en bouwde de app voor iOS, Android en web, met het merk, de website en de marketing erbij. Een paar dingen uit dat traject die je in een AI-prototype niet zomaar meekrijgt:

• Live scoren dat ook zonder wifi werkt. Offline werken en daarna synchroniseren zonder dat er iets dubbel of kwijt raakt, is een van de lastigste onderdelen van een app.
• Drie platforms. Elk platform vraagt eigen tests, en iOS en Android hebben elk een eigen keuring.
• Zes talen in app en website, met teksten die op elke knop moeten passen.
• Een merk en marketing vanaf dag één: een huisstijl, een website met kennisbank, SEO per taal en campagnes in Google Ads, Meta Ads en ChatGPT Ads die coaches naar de gratis proefperiode van 14 dagen sturen.

Het resultaat: 500+ coaches gebruiken Koach en de app heeft een gemiddelde beoordeling van 4,9. Dat kwam niet uit één slimme bouwsessie, maar uit product, merk en marketing die op elkaar aansloten. Hoe dat traject verliep, van schets tot eerste gebruikers, lees je in app idee laten ontwikkelen.

Conclusie: AI om snel te leren, een vakmens voor het fundament

Zelf een app maken met AI is de snelste manier om te ontdekken of je idee werkt. Bouw een prototype rond één vraag, gebruik testgegevens en laat echte mensen uit je doelgroep het proberen. Stop met doorbouwen zodra er echte gegevens, betalingen of een store in beeld komen, of zodra elke fix iets anders breekt. Zet je code op GitHub, houd accounts op je eigen naam en draag over wat werkt en wat nog nep is.

Zo gebruik je AI voor wat het goed kan, en houd je het fundament in handen van iemand die ervoor tekent. Wil je zien wat een website en marketing rond je app bij mij kosten? Download de prijslijst.