Niet-technische ondernemers bouwen tegenwoordig zelf werkende prototypes met tools als Replit, Lovable en Bolt. Dat is een echte doorbraak: de inhoud klopt, de logica werkt, de domeinkennis zit erin. Maar een prototype dat werkt is iets anders dan software die de praktijk in kan. De stap van proof-of-concept naar een stabiel, getest, veilig en onderhoudbaar systeem vraagt professionele begeleiding. Dit artikel legt uit waar het verschil zit, waarom herbouwen geen weggooien is, en hoe je die stap zet zonder de domeinexpert buitenspel te zetten.
Iedereen kan nu een prototype bouwen
Er is iets wezenlijks veranderd. Een ondernemer met domeinkennis en geen regel programmeerervaring kan vandaag een werkend prototype bouwen. Tools als Replit, Lovable en Bolt vertalen een idee in een draaiende applicatie, in dagen in plaats van maanden, zonder dat er een ontwikkelaar aan te pas komt.
Dat is geen speelgoed en geen kunstje. Voor prototyping en co-creatie zijn deze tools uitstekend: ze maken een idee tastbaar, laten je het uitproberen met echte gebruikers, en leggen de bedoeling vast op een manier die geen enkel document kan evenaren. De domeinexpert die zijn eigen prototype bouwt, levert iets op wat in een klassiek traject vaak ontbreekt: software waarin de inhoud aantoonbaar klopt.
De vraag is niet meer of het idee werkt. Die is beantwoord. De vraag is of het de praktijk in kan.
Waarom een prototype nog geen productiesysteem is
Hier zit een verschil dat van buitenaf onzichtbaar is. Het prototype werkt immers, dus waarom zou het niet gewoon in gebruik kunnen?
Omdat een prototype iets anders bewijst dan een productiesysteem moet kunnen. Een prototype laat zien dat het idee klopt. Een productiesysteem moet daarnaast stabiel zijn als er honderd gebruikers tegelijk op zitten, veilig met gevoelige gegevens, getest zodat een wijziging niet stilletjes iets anders breekt, en zo opgebouwd dat het over twee jaar nog uit te breiden valt. Dat zijn eigenschappen die je niet ziet in een demo, en die de tools die het prototype bouwden tot op heden niet vanzelf leveren.
Wat er onder de motorkap ontstaat, is meestal een grote hoeveelheid code die plausibel oogt maar niemand echt kent: vijfduizend regels die werken zolang je precies doet wat in de demo gebeurde, en onvoorspelbaar worden zodra de praktijk afwijkt. In de meeste sectoren is dat hinderlijk. In de zorg, of overal waar het met gevoelige gegevens of kritieke processen werkt, is het een risico.
Dit is dezelfde dynamiek die we eerder beschreven over AI-gegenereerde code in het algemeen: snelheid zonder kaders levert onderhoudslast en technische schuld op.
Herbouwen is geen weggooien
Het woord "herbouwen" klinkt alsof het prototype voor niets is geweest. Het tegendeel is waar.
Het prototype is het waardevolste wat je kunt aanleveren. Het is een functioneel ontwerp dat werkt: het laat precies zien wat het systeem moet doen, hoe de logica loopt, welke schermen en stappen kloppen. Geen specificatiedocument benadert die helderheid. Een ervaren bouwer die jouw prototype voor zich heeft, hoeft niet te raden wat je bedoelt; hij ziet het draaien.
Herbouwen betekent dan ook niet opnieuw beginnen. Het betekent: de bedoeling behouden en het fundament vervangen. De inhoud die jij hebt bewezen blijft staan; de techniek eronder wordt gemaakt zoals een systeem hoort te zijn dat mensen er echt op gaan vertrouwen.
Hoe je die stap zet, zonder buitenspel te staan
De grootste angst van een domeinexpert die zijn prototype overdraagt: dat een technische partij het overneemt, er iets technisch moois van maakt, en de bedoeling onderweg kwijtraakt. Dat is een terechte angst, en de manier van werken bepaalt of hij uitkomt.
Zo houden wij die controle bij de expert:
- Eerst begrijpen wat er staat. Een analyse van de bestaande code en het prototype: wat zit erin, wat werkt, waar zitten de knelpunten, en wat is de kortste weg naar een stabiele versie. Niet meteen bouwen, eerst lezen.
- Een fundament dat klopt. De herbouw naar een structuur die getest, veilig en uitbreidbaar is, met de bewezen logica als uitgangspunt.
- Stap voor stap doorontwikkelen. In kleine, werkende stappen, met de expert als inhoudelijke bron bij elke stap. De techniek volgt de bedoeling, niet andersom.
- Het blijft van jou. Code, documentatie en tests op jouw naam, zo opgebouwd dat een ander of een eigen team het later kan overnemen.
De expert levert de inhoud en het ontwerp, de bouwer levert de techniek, en ze schakelen rechtstreeks. Dat is geen compromis tussen domeinkennis en techniek; het is de combinatie waar goede software uit ontstaat.
Wanneer dit speelt
Herkenbaar als een of meer hiervan klopt:
- Je hebt een prototype in Replit, Lovable, Bolt of een vergelijkbare tool, en het loopt vast zodra je de volgende functie toevoegt.
- Het werkt, maar het valt af en toe om, en je weet niet waarom.
- Klanten of collega's gebruiken het al, en het wordt te belangrijk om nog "een prototype" te zijn.
- Je wilt er je naam aan verbinden, en dan moet het kloppen: stabiel, veilig, betrouwbaar.
- Je voelt dat de volgende stap, zeker richting AI-functionaliteit, om een professioneel fundament vraagt.
In al deze gevallen is de boodschap dezelfde: het prototype heeft zijn werk gedaan. Het bewees dat het idee klopt. Nu verdient het een fundament dat de praktijk aankan.
Conclusie
De tools die niet-technische ondernemers laten bouwen, zijn een echte vooruitgang. Ze zijn sterk in prototyping en co-creatie, en zwak — voorlopig — in alles wat daarna komt: stabiliteit, veiligheid, onderhoudbaarheid, schaal. Dat is geen reden om ze niet te gebruiken. Het is een reden om de overgang naar productie serieus te nemen, met professionele begeleiding.
De eerste stap daarin is klein en altijd dezelfde: iemand met ervaring leest wat je gebouwd hebt, en vertelt je wat er staat, waar de knelpunten zitten en hoe de weg naar een stabiele versie eruitziet. Daarna weet je waar je staat, en wat je idee nodig heeft om de praktijk in te kunnen.
Veelgestelde vragen
Kun je een prototype uit Replit, Lovable of Bolt direct in productie gebruiken?
Meestal niet zonder professionele doorontwikkeling. Deze tools zijn sterk voor prototyping en co-creatie, maar leveren tot op heden geen software die vanzelf stabiel, veilig, getest en schaalbaar is. Voor echt gebruik met klanten of gevoelige gegevens is een herbouw van het fundament nodig.
Is het prototype weggegooid geld als het toch herbouwd moet worden?
Nee. Het prototype is een werkend functioneel ontwerp: het laat exact zien wat het systeem moet doen, helderder dan welk document ook. Dat is het waardevolste vertrekpunt voor een professionele herbouw, die de bewezen bedoeling behoudt en het fundament vervangt.
Wat is het verschil tussen een prototype en een productiesysteem?
Een prototype bewijst dat het idee werkt. Een productiesysteem moet daarnaast stabiel zijn onder belasting, veilig met gegevens, getest tegen fouten en onderhoudbaar op de lange termijn. Die eigenschappen zie je niet in een demo en ontstaan niet vanzelf.
Hoe behoud ik als domeinexpert de regie als een developer mijn prototype overneemt?
Door een werkwijze waarin jij de inhoudelijke bron blijft: eerst samen begrijpen wat er staat, dan stap voor stap herbouwen met jou als toetssteen bij elke stap. De techniek volgt jouw bedoeling. En het eigenaarschap — inclusief code en documentatie — blijft bij jou.
Waarom is dit extra belangrijk in de zorg?
Omdat het daar met gevoelige persoonsgegevens en kritieke processen werkt. Stabiliteit, dataveiligheid en betrouwbaarheid zijn dan geen luxe maar een vereiste, ook wettelijk. Een prototype dat "meestal werkt" volstaat niet zodra echte patiënten of cliënten ervan afhankelijk zijn.