Hoe je een MVP bouwt zonder ontwikkelaar, en wat niemand je vooraf vertelt

Bouwen is ophouden het knelpunt te zijn. Bijna niemand heeft zijn plan daarop aangepast.

Hier is de vraag die me wordt gesteld, en de vraag die eronder ligt.

De gestelde vraag: kan ik mijn product bouwen zonder iemand voor de ontwikkeling aan te nemen? Ja. In 2026 kan één persoon met AI-hulpmiddelen in ongeveer een week een werkende toepassing online hebben, tegenover een klassieke MVP-tijdlijn van acht tot zestien weken. De cijfers van Altar.io leggen het gemiddelde dichter bij vier maanden, met drie maanden als meest voorkomende waarde.

De vraag eronder: gaat dat werken? En het eerlijke antwoord is dat het afhangt van dingen die niets met bouwen te maken hebben.

CB Insights analyseerde 431 met risicokapitaal gefinancierde bedrijven die zijn gestopt en vond dat 43 procent mislukte door slechte aansluiting tussen product en markt. Bij 70 procent «raakte het kapitaal op», wat dezelfde analyse als symptoom en niet als oorzaak behandelt. Zonder geld komen te zitten is wat er gebeurt op de weg naar het echte probleem.

Geen van die mislukkingen werd veroorzaakt door langzame ontwikkeling. Wat betekent dat het knelpunt van de ontwikkeling wegnemen, op zichzelf, het cijfer niet beweegt.

Wat er precies is veranderd

Niet «software is nu makkelijk». Iets nauwers en nuttigers.

De kosten van een toepassing opleveren zijn ingestort. De kosten van beslissen wat de toepassing zou moeten zijn, zijn helemaal niet bewogen.

Twintig jaar lang verborg het knelpunt van de ontwikkeling die tweede kostenpost. Toen bouwen vier maanden en 80.000 dollar kostte, dwongen die vier maanden een zekere discipline: je had tijd om met klanten te praten terwijl de ontwikkeling werkte, en de uitgave zette je aan tot nadenken vóór je je verbond.

Haal die vier maanden weg en nadenken is nu facultatief. Dat is het werkelijke risico van 2026, en het is nieuw. Je kunt het verkeerde ding veel sneller bouwen dan voorheen, en het zal indrukwekkend af lijken terwijl het verkeerd is.

De vier beslissingen vóór je iets prompt

Geen proces. Vier vragen, en je kunt ze allemaal in een middag beantwoorden.

1. Voor wie is dit precies, en wat doen die mensen vandaag in plaats daarvan?

Geen markt. Een persoon, en de omweg die die vandaag gebruikt: een rekenblad, een groep op WhatsApp, een bureau, drie uur op zondag. Als je de omweg niet kunt noemen, weet je nog niet of het probleem echt is, want iedereen heeft een omweg voor problemen die werkelijk pijn doen.

2. Wat is het ene ding dat het moet doen?

De enkele handeling die iemands dag beter maakt. Al het overige is versie twee. Dat telt nu meer dan vroeger, want AI-hulpmiddelen bouwen graag alle negen functies die je beschrijft, en negen functies is de weg naar een product dat niemand kan uitleggen.

3. Welke dingen zijn er in jouw product, en hoe hangen ze samen?

Dit is de vraag die oprichters overslaan, en de vraag die bepaalt of maand zes te overleven is. Gebruikers, orders, projecten, facturen: wat jouw zelfstandige naamwoorden ook zijn. Wat bij wat hoort. Wat uniek moet zijn. Wat er gebeurt wanneer er een wordt verwijderd.

Je hebt geen technisch vocabulaire nodig. «Een klant kan veel projecten hebben, een project heeft precies één eigenaar, twee klanten kunnen geen e-mailadres delen» is een gegevensmodel. Dat opschrijven kost een kwartier en het is het kwartier met de meeste hefboom van de hele onderneming. Als het vocabulaire onbekend is, behandelt het technische glossarium de termen zonder aan te nemen dat je ze al kent.

4. Hoe ga je weten of het werkt?

Kies het getal vóór je begint, want na de start vind je een getal dat bemoedigend lijkt. Aanmeldingen zijn doorgaans het verkeerde. Of iemand een tweede keer terugkwam, is doorgaans het juiste.

Waarom de derde vraag degene is die bijt

Vanwege wat er gebeurt wanneer je die overslaat.

Elke beslissing die je niet uitdrukkelijk neemt, wordt toch genomen. Ze wordt genomen door de generator, op het moment van opleveren, uit een context die jouw bedrijf niet omvat. Het hulpmiddel stopt niet om te vragen of twee klanten een e-mailadres kunnen delen. Het kiest iets aannemelijks en gaat verder.

Dan heb je in maand vier teams nodig, of facturatie, of een tweede gebruikerstype, en blijkt dat het antwoord dat in week één stilzwijgend is gekozen die verandering een herbouw maakt in plaats van een toevoeging. Elke reparatie breekt iets anders. Meer prompts maakt het erger.

Bouwers noemen dit het 70-procentprobleem: de app raakt bijna af en vordert niet meer. De blokkade is nooit ontbrekende code. Het is een beslissing die honderden generaties eerder stilzwijgend is genomen en niet meer goedkoop te veranderen valt.

De versie hiervan op sectorschaal is meetbaar. Het DORA-onderzoek van 2025 vond dat een hogere inzet van AI samengaat met stijgende leveringsproductiviteit en stijgende instabiliteit op hetzelfde moment: sneller en brakker, samen. De analyse van GitClear over 623 miljoen codewijzigingen vond verdubbelde code 81 procent hoger dan de basislijn van 2023, terwijl het herstructureringswerk daalde van 21 procent van de wijzigingen in 2022 naar 3,8 procent in 2026.

Opleveren is goedkoop. Samenhang niet, en niets levert die per ongeluk op. De praktijk die hiervoor is gebouwd, is specificatiegestuurde ontwikkeling, en de architectonische versie van het argument staat hier.

Wat je werkelijk moet doen, in deze volgorde

1. Schrijf de vier antwoorden op. Eén pagina. Doe dat voordat je een hulpmiddel opent. Als je vraag drie niet kunt beantwoorden, ben je niet klaar om te bouwen: je bent klaar om met nog twee klanten te praten.
2. Kies een hulpmiddel op wat er in maand zes gebeurt, niet op wat er vanmiddag gebeurt. Elke optie in deze categorie levert vandaag iets indrukwekkends op. Ze verschillen enorm in of je het later nog kunt uitbreiden. Het landschap, eerlijk vergeleken.
3. Bouw het ene ding. Weersta de tweede functie tot iemand de eerste twee keer heeft gebruikt. Dat is veel moeilijker dan het klinkt wanneer functies toevoegen bijna gratis is.
4. Zet het voor vijf echte mensen, niet vijftig. Vijf mensen die het probleem hebben, vertellen je meer dan vijftig die aardig doen. Kijk waar ze stoppen in plaats van te vragen of ze het leuk vonden.
5. Beslis wat je met het getal doet. Als niemand terugkwam, is het antwoord niet meer functies. Het is opnieuw vraag één.

Waarvoor je werkelijk nog iemand uit de ontwikkeling nodig hebt

Ik zeg dit liever recht voor de raap dan dat ik je een fantasie verkoop.

Alles waar ernaast zitten duur is. Betalingen voorbij een gewone kassa, gezondheidsgegevens, alles wat onder toezicht staat. Niet omdat de hulpmiddelen het niet kunnen opleveren, maar omdat je niet kunt beoordelen of wat ze hebben opgeleverd veilig is, en in die velden is «leek in orde» geen norm.

Migraties onder belasting. De vorm van levende gegevens veranderen met echte klanten erop is werkelijk moeilijk en gaat stil mis.

Het moment dat het werkt. Dat is het goede probleem. Wanneer het gebruik groeit, moet iemand die het systeem begrijpt het overnemen. Plan die aanstelling als mijlpaal van succes in plaats van als iets dat je had moeten vermijden.

Waarvoor je waarschijnlijk niemand uit de ontwikkeling nodig hebt: om op het punt te komen waar je weet of iemand dit wil. Dat vroeg vroeger iemand. Nu niet meer, en dat is een echte verandering die het waard is te benutten.

De valstrik van de indrukwekkende demonstratie

Een werkend scherm is enorm overtuigend, ook voor jezelf.

Je zult het aan mensen laten zien en ze zullen bemoedigend zijn, want naar een afgewerkte interface kijken geeft een andere reactie dan gevraagd worden je manier van werken te veranderen. Bemoediging is geen bewijs. De demonstratie is alleen iets waard als iemand die twee keer gebruikt zonder dat jij in de kamer bent.

Ik zou liever een oprichter zien met een lelijk product en veertig terugkerende gebruikers dan een met een mooi product, vierhonderd aanmeldingen en geen tweede bezoeken. Het tweede is veel gemakkelijker te krijgen en veel moeilijker te herstellen, want het voelt als voortgang.

Het deel dat niet gemakkelijker werd

Je kunt het ding nu in een week bouwen. Dat is echt, dat is werkelijk nieuw, en wie je iets anders vertelt heeft het recent niet geprobeerd.

Maar 43 procent van die 431 gestopte bedrijven stierf aan slechte aansluiting tussen product en markt, en niet één stierf omdat het bouwen te lang duurde. Het knelpunt is verschoven. Het verschoof naar het deel dat altijd het moeilijke was en dat vroeger achter vier maanden techniek verborgen lag.

Welke beslissingen, in welke volgorde, voor wie. Dat is nu het werk. Het was altijd het werk.

Het bouwen was alleen luid genoeg om het te overstemmen.

Verwante lectuur

Specifiek over de architectonische beslissingen, SaaS-ontwikkeling voor niet-technische oprichters. Over wat de hulpmiddelen je werkelijk kosten, tekens, credits of inspanning.

Veelgestelde vragen

Kun je in 2026 werkelijk een app bouwen zonder ontwikkelaar? Ja. Iemand zonder technisch profiel kan met AI-appbouwers in ongeveer een week een werkende toepassing online brengen, tegenover een klassieke MVP-tijdlijn van acht tot zestien weken. De beperking is niet langer of je het kunt bouwen: het is of je vóór de start de juiste dingen hebt besloten.

Hoe lang duurt het om een MVP te bouwen? Klassiek acht tot zestien weken, waarbij cijfers het gemiddelde dichter bij vier maanden leggen en drie maanden de meest voorkomende tijdlijn is. Met AI-hulpmiddelen kan één persoon in ongeveer een week een werkend product bereiken, al helpt die snelheid alleen als de onderliggende beslissingen bewust zijn genomen.

Wat moet ik beslissen vóór het bouwen? Vier dingen: voor wie het is en wat die mensen vandaag in plaats daarvan doen, de enkele handeling die het product moet ondersteunen, welke dingen er in jouw product zijn en hoe ze samenhangen, en het getal dat je vertelt of het werkt. Het derde slaan de meeste oprichters over en het veroorzaakt later de duurste problemen.

Waarom houden door AI gebouwde MVP’s na een paar maanden op te werken? Omdat beslissingen die niemand uitdrukkelijk nam stilzwijgend door de generator zijn genomen, en die beslissingen begrenzen alles wat erna komt. Dat is het 70-procentprobleem: de app raakt bijna af en loopt vast, omdat de blokkade een architectonische keuze is en geen ontbrekende functionaliteit.

Moet ik databases begrijpen om een MVP te bouwen? Je hebt geen technisch vocabulaire nodig, maar je moet wel kunnen zeggen welke dingen er in jouw product bestaan en hoe ze samenhangen. «Een klant kan veel projecten hebben, een project heeft één eigenaar, twee klanten kunnen geen e-mailadres delen» is een gegevensmodel in gewoon Nederlands, en dat opschrijven is een van de waardevolste dingen die je kunt doen.

Wanneer moet ik werkelijk iemand voor de ontwikkeling aannemen? Voor alles waar ernaast zitten duur is (gegevens onder toezicht, betalingen voorbij de gewone kassa) omdat je niet kunt beoordelen of de uitkomst veilig is. Voor het migreren van levende gegevens onder belasting. En wanneer het product begint te werken en iemand het systeem behoorlijk moet overnemen. Behandel dat laatste als mijlpaal van succes.

Wat kost het om een MVP te bouwen zonder ontwikkelaar? Het gereedschap loopt van gratis niveaus tot enkele honderden dollars per maand, afhankelijk van hoeveel je bijschaaft, wat drastisch minder is dan een klassieke bouw. De kosten die oprichters verrassen, zijn die na de start: hosting terwijl het gebruik groeit, en de herbouw als de vroege architectuur de volgende functie niet kan dragen.