MVP bouwen met AI: van Lovable-prototype naar werkend MKB-product
Een Lovable-prototype is nog geen product dat draait in je MKB-bedrijfsvoering. Lees waar AI-MVPs meestal vastlopen, wat een productie-klaar MVP in 2026 kost (€8K-25K) en wanneer je een partner nodig hebt.
Een ondernemer bouwt in een weekend een functioneel prototype in Lovable en laat het maandag aan zijn team zien. Iedereen is enthousiast, en daarna begint het echte werk pas. Dit artikel gaat over dat tweede deel: de stap van werkend prototype naar een product dat ook daadwerkelijk aansluit op jouw bedrijfsvoering.
Je leest hier wat het verschil is tussen een prototype en een productie-klaar MVP, welke AI-tools ik in 2026 waarvoor gebruik, op welke drie integratiepunten MKB-MVPs vastlopen, wat een traject realistisch kost, en hoe je met een kopieerbare checklist bepaalt of je een partner nodig hebt.
Kort samengevat
- Een werkend prototype uit Lovable of Bolt is meestal een functioneel prototype (type 2), geen productie-klaar MVP (type 3). De code schrijven kost de minste tijd; het aansluiten op je bestaande systemen vraagt het meeste werk.
- MKB-MVPs lopen vrijwel altijd na de bouw vast op drie punten: data-integratie met bestaande systemen (Exact, AFAS, HubSpot), authenticatie en rechtenstructuur (RLS), en het beheer na livegang.
- Zelf bouwen met Lovable Pro kost de toolprijs plus 40-80 uur eigen tijd, maar laat integraties en beheer ongedekt. Een partner-traject inclusief integraties loopt van 3 tot 6 weken.
- Kruis de checklist aan: bij twee of meer vinkjes betrek je een partner bij de scoping, bij vier of meer kun je beter niet alleen bouwen.
- Heb je al een prototype, loop dan eerst de checklist door voordat je verder bouwt.
Wat is een MVP en wat is het niet?
In startup-jargon staat MVP voor "minimum viable product": het kleinste product dat genoeg waarde levert om echt te testen. Voor een MKB-ondernemer die een interne tool of klantportal wil bouwen, is die definitie te vaag. In de praktijk worden er drie typen door elkaar gebruikt:
Type 1: Clickable prototype. Een gesimuleerde interface, geen werkende database, geen echte data. Goed om feedback mee op te halen, al kun je er in het dagelijkse werk nog niets mee.
Type 2: Functioneel prototype. Werkt technisch en heeft een database (Supabase), maar staat op zichzelf: het logt geen data in Exact Online, praat niet met HubSpot en kent geen rollen of rechtenstructuur.
Type 3: Productie-klaar MVP. Werkt met jouw bestaande systemen, heeft authenticatie, rolgebaseerde toegang, AVG-compliance en een duidelijk beheerplan voor na de livegang.
De meeste "AI-MVPs" die in 2026 uit zo'n weekendproject rollen zijn type 2, terwijl de bouwer ervan uitgaat dat het type 3 is. Dat misverstand kost tijd en geld. De code schrijven kost in zo'n traject namelijk de minste tijd; het aansluiten op je bestaande systemen vraagt verreweg het meeste werk.
Een werkend prototype in Lovable is het equivalent van een IKEA-keuken op de schetstafel: hij ziet er goed uit, maar zonder loodgieter en elektricien woont er niemand in.
De AI-tools die ik in 2026 gebruik en waarom
Welke tool past hangt af van wat je wilt bereiken en van hoe technisch je team is.
| Tool | Beste voor | Technisch niveau vereist | Stack |
|---|---|---|---|
| Lovable | UI-heavy prototypes, MKB-validatie | Laag | React + Supabase, exporteerbaar |
| Bolt.new | Snelle iteraties, full-stack in browser | Laag tot gemiddeld | Diverse stacks, token-based |
| Cursor | Developers die controle willen houden | Hoog | Jouw eigen codebase |
| Claude Code | Technische teams, complexe backends | Hoog | Maximale flexibiliteit |
Voor een eerste MVP start ik vrijwel altijd met Lovable of Bolt voor de UI-laag, omdat je daarmee al in week één iets visueels hebt waar stakeholders op kunnen reageren. Daarna bouw ik de businesslogica, de rechtenstructuur en de integraties. Claude Code gebruik ik voor complexere backends en AI-agent logica; de agents die ik bouw draaien via mijn platform beemanaged.com.
Ik schreef eerder uitgebreid over de vibe coding aanpak: zie het artikel over vibe coding. De kern daarvan: de toolkeuze doet er minder toe dan wat je bouwt nadat het prototype staat.
Wat Lovable en Bolt bewust niet doen: ERP-koppelingen, rolgebaseerde rechtenstructuren en beheer na livegang. Dat is een ontwerpkeuze van die tools, want ze zijn gebouwd om snel een idee te valideren. Voor productie gelden simpelweg andere eisen.
De 3 momenten waarop AI-MVPs voor MKB vastlopen
Dit is de kern van dit artikel. De meeste MVPs stranden pas na de bouw, op de aansluiting met de rest van het bedrijf. Drie knelpunten komen daarbij steeds terug.
Knelpunt 1: Data-integratie met bestaande systemen
Lovable bouwt standaard op Supabase. Prima database, maar jouw bedrijf werkt waarschijnlijk met Exact Online, AFAS, HubSpot of een ouder ERP. Die twee werelden praten niet vanzelf met elkaar.
Je hebt een integratie-laag nodig: n8n-flows, custom API-connectoren of webhooks die data op het juiste moment naar het juiste systeem schrijven. Klinkt eenvoudig, maar in de praktijk betekent het: veldmapping tussen systemen met andere datamodellen, foutafhandeling voor wanneer de API van Exact tijdelijk niet beschikbaar is, retry-logica, authenticatie naar beide kanten, en datavalidatie. De terugverdientijd na goede integratie kan aanzienlijk zijn: professioneel opgezette workflow-automatisering bespaart al snel veel handmatig werk per week. Dat geldt alleen als de integratie correct is gebouwd.
Knelpunt 2: Authenticatie en rechtenstructuur
In een interne MKB-tool zijn er altijd rollen: manager, medewerker, klant. Lovable genereert standaard authenticatie via Supabase Auth: e-mail, wachtwoord, bevestigingsmail. Voor een publieke SaaS volstaat dat. Een intern systeem waar een monteur alleen zijn eigen werkbonnen mag zien en de projectleider die van zijn hele team, vraagt om meer.
De functionaliteit die dit regelt heet Row-Level Security (RLS) in Supabase. Je kunt het toevoegen, maar het vereist structureel nadenken over je datamodel voordat je bouwt. RLS achteraf inbouwen in een bestaand prototype kan wel, maar het scheelt veel uitzoekwerk en herstelwerk als je het vanaf het begin in het datamodel verwerkt.
Knelpunt 3: De overgang naar productie en beheer
Lovable's stack is exporteerbaar naar GitHub, en daarmee begint het beheer pas. Wie doet de security-patches als Supabase een kwetsbaarheid publiceert? Iemand moet ook de n8n-flows aanpassen als Exact Online een API-versie depreceert, en de AVG-compliance bewaken zolang er klantdata in de database staat.
Die vraag is eerder operationeel dan technisch. De code van zelfgebouwde MVPs breekt zelden; ze stranden vooral omdat er na de livegang niemand verantwoordelijk is. Een goed MVP-traject loopt daarom door tot er een duidelijk beheerplan ligt, met namen erbij.
Wat kost een AI-MVP realistisch in 2026?
Hieronder staan de cijfers zoals ik ze in de praktijk tegenkom, inclusief de nuances.
| Aanpak | Doorlooptijd | Kosten | Risiconiveau | Wie beheert het na livegang? |
|---|---|---|---|---|
| Volledig zelf met Lovable Pro | 1 tot 4 weken prototype | € 20-30/mnd tool + 40-80 uur eigen tijd | Hoog: integraties en beheer ontbreken | Jijzelf |
| Externe partner (incl. integraties) | 3 tot 6 weken van intake tot live | € 8.000 tot € 25.000 afhankelijk van scope | Laag: integraties, RLS en overdracht inbegrepen | Partner + afgesproken beheerplan |
| Traditionele software-ontwikkeling | 3 tot 6 maanden | € 25.000 tot € 75.000 | Gemiddeld | Extern team of interne IT |
De bandbreedte bij een partner-traject (€ 8.000 tot € 25.000) hangt af van drie factoren: het aantal te integreren systemen, de complexiteit van de rechtenstructuur, en de hoeveelheid maatwerk in de businesslogica. Een intern dashboard met één Exact-koppeling zit aan de onderkant van die bandbreedte. Een klantportal met HubSpot-data, drie gebruikersrollen en meerdere omgevingen (test, acceptatie, productie) zit aan de bovenkant.
Wat een goed partner-traject hoort te bevatten: scoping, bouw, integratie-laag, testfase met echte gebruikers, en overdracht inclusief beheer-afspraken. Let erop dat er niets gebouwd wordt waar jij daarna afhankelijk van bent zonder uitstapoptie.
Ter vergelijking: een MKB-bedrijf van 15 medewerkers dat wekelijks 20 uur kwijt is aan handmatige dataoverdracht tussen systemen, betaalt bij een gemiddeld uurtarief van € 35 jaarlijks circa € 36.400 aan die taak. Een integratie van € 10.000 die 80% van dat werk overneemt, verdient zichzelf in vier maanden terug.
Wanneer schakel je een partner in?
Kopieer deze checklist en kruis aan wat voor jouw situatie geldt. Bij twee of meer vinkjes is het verstandig een partner te betrekken. Bij vier of meer kun je beter niet alleen bouwen.
MVP-checklist: heb ik een partner nodig?
- [ ] Mijn MVP moet koppelen aan een bestaand systeem (ERP, CRM, boekhouding)
- [ ] Er werken meer dan 5 mensen mee in het systeem
- [ ] Klantdata of gevoelige bedrijfsdata wordt verwerkt (AVG-relevant)
- [ ] Ik wil over 12 maanden nog doorontwikkelen of uitbreiden
- [ ] Er zijn meerdere gebruikersrollen nodig met verschillende rechten
- [ ] Ik heb geen developer in huis die ook na livegang beschikbaar is
Score: 2 of meer vinkjes → betrek een partner bij de scoping.
Score: 4 of meer vinkjes → bouw niet alleen, ook niet als je al een prototype hebt.
Vul in:
- Hoeveel medewerkers gebruiken het systeem? <aantal medewerkers>
- Welke systemen moeten er mee koppelen? <ERP/CRM/boekhouding>
- Wie is verantwoordelijk voor beheer na livegang? <naam of functie>
De reden achter de drempel van twee: elk extra systeem dat je koppelt vermenigvuldigt de complexiteit. Twee systemen koppelen is één integratie, bij drie systemen zijn het er al drie, en bij vijf systemen heb je tien mogelijke verbindingen, elk met eigen foutscenario's en dataconflicten.
Toen ik mijn eigen MVP's vanaf een Lovable-prototype doorontwikkelde, hield ik de UI grotendeels intact, herbouwde ik het datamodel, en bouwde ik de integratie-laag van de grond af. Dat klinkt als dubbel werk, maar het kost minder tijd dan doorbouwen op een verkeerde architectuur en later alsnog opnieuw moeten beginnen.
Hoe ziet een goed MVP-traject eruit?
Dit is de volgorde die ik bij mijn eigen MVP's aanhoud. Bouw je met een partner, dan mag je dezelfde stappen verwachten.
Stap 1: Intake en scoping (1 sessie, circa 2 uur) Breng in kaart welke systemen meepraten, welke gebruikersrollen er zijn, en wat de minimale feature-set is voor een productie-waardige versie. Output: een scopedocument met prioriteiten, technische keuzes en een kostenschatting.
Stap 2: Core feature bouwen (1 tot 2 weken) Bouw de centrale functionaliteit, inclusief datamodel, authenticatie en de basisinterface. Afhankelijk van de stack is dat Lovable, Bolt of Cursor.
Stap 3: Integratie-laag (1 tot 3 weken, afhankelijk van systemen) Bouw de koppelingen met Exact, AFAS, HubSpot of andere systemen. Via n8n voor workflow-logica, met custom API-connectoren waar de standaard-integraties niet volstaan.
Stap 4: Testfase met echte gebruikers (1 week) Laat het team een week met echte data werken, in plaats van een UAT met fictieve scenario's. Fix wat misgaat voordat je live gaat.
Stap 5: Overdracht en beheer-afspraken Zorg dat de code, de documentatie en een beheerplan zijn vastgelegd: wie is verantwoordelijk voor wat na livegang, en wat zijn de opties voor doorontwikkeling.
Totale doorlooptijd: drie tot zes weken afhankelijk van scope. Dat staat tegenover de "bouw in een weekend" belofte van solo-tools, maar ook tegenover de drie tot zes maanden van traditionele development.
Wanneer heeft het geen zin een partner in te schakelen?
Een partner inschakelen is lang niet altijd nodig. Als je een interne tool wil bouwen die door maximaal drie mensen wordt gebruikt, geen koppeling met bestaande systemen nodig heeft, geen gevoelige klantdata verwerkt, en je het zelf of via een collega wilt beheren, dan kun je prima zelf starten met Lovable Pro (€ 25 per maand). Bouw en test het in eigen beheer, en betrek pas een partner zodra je het wilt uitbreiden.
Een partner is zelden het goedkoopste alternatief. Let er daarom op dat je code krijgt die je na de overdracht nog steeds begrijpt, met vastgelegde afspraken over wie wat beheert.
Veelgestelde vragen over een MVP bouwen met AI
Wat is het verschil tussen een prototype en een productie-klaar MVP?
Een functioneel prototype (type 2) werkt technisch en heeft een database, maar staat op zichzelf: het logt geen data in Exact Online, praat niet met HubSpot en kent geen rollen of rechtenstructuur. Een productie-klaar MVP (type 3) werkt met jouw bestaande systemen, heeft authenticatie, rolgebaseerde toegang, AVG-compliance en een duidelijk beheerplan voor na de livegang.
Waarom loopt een AI-MVP zo vaak vast na de bouw?
De code schrijven kost in zo'n traject de minste tijd; het aansluiten op je bestaande systemen vraagt verreweg het meeste werk. MVPs stranden pas na de bouw op drie terugkerende knelpunten: data-integratie met bestaande systemen, authenticatie en rechtenstructuur, en het beheer na livegang. De code breekt zelden; ze stranden vooral omdat er na de livegang niemand verantwoordelijk is.
Welke AI-tool kan ik het beste gebruiken voor mijn MVP?
Dat hangt af van wat je wilt bereiken en hoe technisch je team is. Voor een eerste MVP start je vrijwel altijd met Lovable of Bolt voor de UI-laag, omdat je daarmee al in week één iets visueels hebt waar stakeholders op kunnen reageren. Cursor en Claude Code passen bij technische teams die controle willen houden of complexere backends bouwen. De toolkeuze doet er minder toe dan wat je bouwt nadat het prototype staat.
Wat is Row-Level Security en waarom is het belangrijk?
Row-Level Security (RLS) is de functionaliteit in Supabase die regelt wie welke data mag zien. In een interne MKB-tool zijn er altijd rollen, bijvoorbeeld een monteur die alleen zijn eigen werkbonnen mag zien en een projectleider die van zijn hele team. RLS achteraf inbouwen in een bestaand prototype kan wel, maar het scheelt veel uitzoekwerk en herstelwerk als je het vanaf het begin in het datamodel verwerkt.
Wanneer kan ik beter een partner inschakelen?
Loop de checklist door en kruis aan wat voor jou geldt. Bij twee of meer vinkjes is het verstandig een partner bij de scoping te betrekken, bij vier of meer kun je beter niet alleen bouwen, ook niet als je al een prototype hebt. De vinkjes gaan onder meer over koppelingen met bestaande systemen, het aantal gebruikers, gevoelige data, meerdere gebruikersrollen en de beschikbaarheid van een developer na livegang.
Wanneer heeft het juist geen zin een partner in te schakelen?
Als je een interne tool wil bouwen die door maximaal drie mensen wordt gebruikt, geen koppeling met bestaande systemen nodig heeft, geen gevoelige klantdata verwerkt, en je het zelf of via een collega wilt beheren, dan kun je prima zelf starten met Lovable Pro. Bouw en test het in eigen beheer, en betrek pas een partner zodra je het wilt uitbreiden.
Conclusie
De tools om een MVP te bouwen zijn in 2026 goedkoper en toegankelijker dan ooit, en daardoor is de uitdaging verschoven. De bouw zelf is zelden nog het probleem; het werk zit in de integratie met bestaande systemen, in de rechtenstructuur en in het beheer na livegang. Heb je al een prototype liggen, loop dan eerst de checklist hierboven door voordat je verder bouwt.
Als je nog aan het oriënteren bent op wat AI-agents voor je bedrijf kunnen doen nadat je MVP live is, lees dan eerst dat artikel.