Een demo bouwen met AI lukt tegenwoordig in een middag. Diezelfde demo naar productie brengen waar echte gebruikers op vertrouwen is een ander verhaal. Tussen die twee momenten zit precies de kloof waar de meeste AI-producten stranden: ze werken in de presentatie, maar niet onder belasting, niet bij storingen en niet wanneer iemand anders dan de maker ze gebruikt.
Dit is geen kwestie van talent. Het is een kwestie van volgorde. Teams bouwen vaak eerst het indrukwekkende deel (het model, de prompt, de magie) en stellen de structurele beslissingen uit tot ze blokkeren. Dan is er een demo die niemand durft uit te rollen.
Kort antwoord
- Een werkend prototype betekent niet dat je een product hebt. Het verschil zit in wat eromheen zit: de applicatielaag, de monitoring en de foutafhandeling.
- "Productieklaar" heeft een concrete betekenis: uitgerold, observeerbaar, beveiligd, bestand tegen falen en bij te werken zonder downtime.
- AI voegt eigen faalwijzen toe die gewone software niet kent: kwaliteit die langzaam terugloopt, kosten die plotseling stijgen, onvoorspelbare output.
- De applicatielaag (dashboard, portal, beheerinterface) is wat een model bruikbaar maakt. Zonder die laag blijft het technisch werken maar voor gebruikers onbruikbaar.
- De belangrijkste keuzes maak je in de eerste fase. Scope, stack en architectuur bepalen de snelheid van alles daarna.
- Een MVP definieert zich door wat je bewust weglaat, niet alleen door wat je meeneemt.
De applicatielaag is het echte product
Een taalmodel dat accurate antwoorden geeft is nog geen product. Gebruikers hebben een plek nodig om het te bedienen: een dashboard, een portal, een workflow, een beheerscherm voor support. Die laag is geen bijzaak. Het is vaak precies wat een prototype verandert in iets waar mensen dagelijks mee werken.
Denk aan een model dat documenten samenvat. Als technisch experiment werkt het. Als product heeft de gebruiker een plek nodig om documenten te uploaden, de samenvatting te corrigeren, te zien welke versie is gebruikt en te begrijpen waarom een uitkomst afwijkt. Dat is geen modelwerk. Dat is productwerk, en het is meestal de reden waarom één team wel live gaat en een ander niet.
Wat "productieklaar" concreet betekent
Het begrip wordt vaak vaag gebruikt. Voor AI-producten is het juist preciezer dan voor gewone software, omdat de faalwijzen anders zijn. Een systeem is productieklaar wanneer het aan vijf eisen voldoet.
Uitgerold en bereikbaar: echte gebruikers komen er via infrastructuur die je zelf beheert, niet via een laptop of een gedeeld notebook. Observeerbaar: je weet wanneer het traag is, wanneer het uitvalt, wanneer de kwaliteit van de output terugloopt en wanneer de kosten oplopen. Beveiligd: authenticatie is echt geregeld, data is beschermd in rust en onderweg, en je hebt nagedacht over misbruik van het model. Bestand tegen falen: als het AI-onderdeel uitvalt, en dat gebeurt, faalt het systeem zichtbaar en herstelbaar in plaats van stil verkeerd. Bij te werken: je kunt het model, de prompts of de applicatie aanpassen zonder downtime.
Merk op dat volledigheid hier niet in staat. Een productieklaar MVP is geen compleet product. Het is een stabiel, observeerbaar systeem dat één ding betrouwbaar doet voor echte gebruikers en je de informatie geeft om te bepalen wat je daarna bouwt.
Wat AI toevoegt aan gewone software
Bij deterministische code is een fout een fout: de functie geeft het verkeerde antwoord of crasht. AI-onderdelen gedragen zich anders. De output kan langzaam slechter worden zonder dat er iets kapotgaat, bijvoorbeeld wanneer een modelversie verandert of wanneer de invoer verschuift. De kosten per aanroep kunnen stijgen zonder dat iemand een instelling heeft aangepast. En dezelfde invoer kan twee keer een ander antwoord geven.
Dat betekent dat je dingen moet inbouwen die in traditionele software niet bestaan. Versiebeheer op prompts, zodat je weet welke versie een uitkomst heeft geproduceerd. Een terugvaloptie als het primaire model niet beschikbaar is. Validatie op de output voordat die naar de gebruiker gaat. En kostenbewaking per dag of per uur, niet pas bij de maandfactuur.
Deze dingen achteraf toevoegen is veel duurder dan ze vanaf het begin meenemen. In week één zijn het kleine beslissingen. Na de lancering zijn het projecten.
Waarom de eerste fase alles bepaalt
De keuzes in de eerste fase bepalen de snelheid van alle weken daarna. Scope, stack en architectuur zijn niet alleen technisch. Ze zijn bepalend voor hoe snel je kunt aanpassen wanneer echte gebruikers zich anders gedragen dan verwacht.
Een concreet voorbeeld: kies je voor een aanpak waarbij elke aanroep naar het model synchroon loopt, dan zit de gebruiker te wachten en schaalt je systeem niet mee. Zet je er een wachtrij tussen, dan wordt de ervaring anders maar de last beter verdeelbaar. Dat is geen detail dat je later oplost. Het is een keuze die je meteen goed of fout doet.
De verleiding is om direct alles van de backlog te bouwen. Doe dat niet. Besteed de eerste weken na de lancering aan het observeren van echt gedrag. De functies die gebruikers nodig hebben wijken vaak af van de functies die ze vroegen en van de functies waarvan je dacht dat ze nodig waren.
Scope is de belangrijkste vaardigheid
Een MVP is niet een klein product. Het is een bewuste selectie van wat je wel en niet doet. Voor AI-producten is die discipline belangrijker dan voor gewone software, omdat de verleiding groot is om te veel rond het model te bouwen zodra het eenmaal werkt.
Stel je de vraag per functie: draagt dit bij aan het enige dat dit systeem betrouwbaar moet doen? Zo nee, dan gaat het naar de volgende fase. Elke functie die je toevoegt voordat je echte gebruikerssignalen hebt, is een gok die je onderhoudt zonder te weten of die klopt.
Conclusie
Het verschil tussen een prototype en een product zit niet in het model. Het zit in de applicatielaag eromheen, in de monitoring, in de manier waarop het systeem omgaat met falen en in de discipline om te kiezen wat je weglaat. Wie die keuzes in de eerste fase maakt, lanceert iets waar gebruikers op kunnen bouwen. Wie ze uitstelt, houdt een demo over.
Twijfel je of je idee klaar is om te bouwen, of wil je weten wat er tussen je prototype en productie zit? GitCity denkt graag mee over de techniek, de architectuur en het model erachter. Neem contact op voor een eerste gesprek zonder verplichtingen.