Gepubliceerd op 16 maart 2026·Door Yannick Caron
In 1999 liep Nick Swinmurn een lokale schoenenwinkel binnen met een camera. Niet als toerist. Niet als fashionblogger. En zelfs niet om schoenen voor zichzelf te kopen. Hij begon simpelweg foto’s te maken van de paren die in de winkel stonden. Als je erbij was geweest, had je waarschijnlijk gedacht: “Wat is die gast aan het doen?”
Diezelfde avond verschenen die foto’s op een kleine, heel 1999-achtige website. Geen magazijn. Geen voorraad. Geen logistieke operatie op de achtergrond. Wanneer iemand een bestelling plaatste, ging Nick terug naar de winkel, kocht de schoenen voor de volledige winkelprijs, pakte ze in en verstuurde ze zelf.
Hij probeerde geen bedrijf van een miljard dollar te bouwen. Hij probeerde één simpele vraag te beantwoorden: zijn mensen bereid om schoenen online te kopen?
Tien jaar later werd dit kleine experiment, inmiddels bekend als Zappos, overgenomen door Amazon voor 1,2 miljard dollar. In 1999 was de beperking technologie. Vandaag de dag, nu AI code voor ons schrijft, is de beperking discipline.
Laten we één ding meteen duidelijk maken. Als je mensen hoort zeggen dat MVP’s dood zijn, dan hebben ze ongelijk. De kernprincipes die Eric Ries beschreef in The Lean Startup gelden nog steeds.
“Die versie van een nieuw product waarmee een team met de minste inspanning de maximale hoeveelheid gevalideerde kennis over klanten kan verzamelen.”
Een MVP was nooit bedoeld als half werk of slordig. Het ging er niet om iets rommeligs te lanceren en het “lean” te noemen. Het ging om focus.
Niet een uitgeklede eindversie van een product, maar een bewust kleine versie. Niet goedkoop, maar kostenefficiënt. Alles met één doel: gevalideerd leren.
Gedurende het grootste deel van de geschiedenis van startups was het bouwen van digitale producten duur. Je had developers nodig. Je had kapitaal nodig. En vooral: je had tijd nodig.
Die frictie werkte als een natuurlijke filter. Prioriteren was geen keuze, het was overleven. Founders moesten zichzelf afvragen: wat is het absolute minimum aan ontwikkeling dat we nodig hebben om dit idee te valideren?
AI heeft die filter verwijderd.
De bottleneck is verschoven van bouwen naar besluitvorming. Moderne AI-tools kunnen interfaces opzetten, backendlogica genereren en integraties verbinden met een paar prompts. Op het eerste gezicht werkt alles, totdat het dat niet meer doet.
De moeite die nodig is om iets toonbaars te bouwen is drastisch afgenomen. En wanneer de benodigde inspanning daalt, verdwijnt ook de terughoudendheid.
Ries definieerde een MVP als de versie van een product die maximale gevalideerde inzichten oplevert met minimale inspanning. Maar wat gebeurt er wanneer inspanning bijna irrelevant wordt?
Wanneer inloggen met Google, rolgebaseerde permissies, AI-samenvattingen, CSV-exports, dark mode en een volledig analytics-dashboard met één prompt kunnen worden opgezet, wat houdt ons dan nog tegen om ze toe te voegen voordat we onze kernfunctionaliteit hebben gevalideerd?
De vraag is niet langer: “Kunnen we dit bouwen?”
Maar: “Waarom zouden we het niet toevoegen?”
AI heeft de definitie van een MVP niet veranderd. Het heeft alleen veranderd hoe makkelijk het is geworden om die te negeren.
Het is verleidelijk om de eerste versie vol te stoppen met features. Als developer ben ik daar zelf ook schuldig aan geweest. Wanneer bouwen makkelijk wordt, voelt “nog één ding toevoegen” onschuldig. Maar less is more bestaat niet voor niets.
Neem het voorbeeld van Zappos. Als je doel is om te valideren of mensen bereid zijn om schoenen online te kopen, dan zou je volledige focus op één ding moeten liggen: iemand in staat stellen een paar schoenen te kopen.
Ja, je kunt gebruikersaccounts toevoegen. Ja, je kunt geavanceerde filters bouwen. Ja, je kunt een slimme schoenenvinder maken. En nog allerlei andere ogenschijnlijk geweldige features die je kunt bedenken.
Maar heb je dat allemaal nodig om te testen of iemand zijn creditcard wil pakken?
Als die features stuk gaan, gaat de feedback over bugs. “Deze filter geeft geen resultaten.” “Ik krijg damesschoenen aanbevolen terwijl ik een man ben.”
Je eindigt met het oplossen van bugs en het verspillen van tijd en geld aan features die vanaf het begin nooit essentieel waren. De echte vraag blijft onbeantwoord: willen mensen schoenen online kopen?
Stel je nu een simpele versie voor: een overzichtelijke lijst met schoenen en een soepel checkout proces. Niets meer.
De feedback verandert.
“Kun je filters toevoegen voor heren en dames?” “Kun je me helpen schoenen te vinden die bij mijn stijl passen?”
Dat is feedback die voortkomt uit vraag, niet uit aannames. AI maakt het makkelijk om alles vooraf te bouwen. Discipline betekent ervoor kiezen om dat niet te doen.
Er zijn vandaag de dag twee dominante manieren waarop founders AI gebruiken.
AI-app builders zoals Base44 en Lovable verlagen de drempel om je eigen app te lanceren enorm. Je kunt in enkele dagen, of zelfs uren, van idee naar product gaan. Het zijn uitstekende tools voor snelle validatie.
Maar die snelheid heeft ook nadelen. De architectuur is ondoorzichtig. Opschalen kan onzeker zijn. Kosten kunnen onvoorspelbaar stijgen. En als het product aanslaat, brengt het migreren van gebruikers naar een custom-built systeem frictie en risico met zich mee.
Aan de andere kant staan AI-coding tools zoals Cursor, Chat GPT en Claude. Daarmee kun je vanaf dag één op je eigen fundament bouwen. Je hebt controle over architectuur, schaalbaarheid en onderhoudbaarheid op de lange termijn. Er zijn minder beperkingen, maar je draagt ook meer verantwoordelijkheid. Je hebt een goede technische basis nodig en nog steeds heb je discipline nodig.
Beide paden versnellen het bouwen. Geen van beide vervangt de noodzaak voor focus.
AI heeft de principes van een MVP niet vervangen. Het heeft de tijd- en inspanningsbeperkingen verwijderd die deze principes afgedwongen.
Het echte voordeel zit niet in welke AI-tool je kiest. Het zit in hoe lang je kunt weerstaan om meer te bouwen dan nodig is.
Zappos begon niet met infrastructuur of met de keuze voor een tool. Ze begonnen met een vraag.
AI laat ons sneller bouwen dan ooit.
Maar de founders die winnen, zullen niet degenen zijn die het meest bouwen. Het zullen degenen zijn die het snelst leren.
Dus, waarom beginnen we niet met de vraag?