MVP bouwen met AI: van Lovable-prototype naar werkend MKB-product
Van Lovable-prototype naar een product dat ook echt werkt in jouw MKB-bedrijfsvoering. De drie integratie-valkuilen, een eerlijke kostenvergelijking (€8K-25K) en wanneer je een partner nodig hebt.
Een ondernemer bouwt in een weekend een functioneel prototype in Lovable, toont het aan zijn team, iedereen blij. En dan? Dan begint het echte werk. Dit artikel gaat over dat tweede deel: van werkend prototype naar een product dat ook daadwerkelijk aansluit op jouw bedrijfsvoering.
Wat je hier vindt: het verschil tussen een prototype en een productie-klaar MVP, welke AI-tools wij in 2026 gebruiken en wanneer, de drie integratie-valkuilen die MKB-MVPs stranden, een eerlijke kostenvergelijking, en een kopieerbare checklist om te bepalen of je een partner nodig hebt.
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. Maar voor een MKB-ondernemer die een intern tool of klantportal wil bouwen, is die definitie te vaag. Er zijn drie typen die in de praktijk door elkaar worden gebruikt:
Type 1: Clickable prototype. Een gesimuleerde interface, geen werkende database, geen echte data. Goed voor het ophalen van feedback, niet voor dagelijks gebruik.
Type 2: Functioneel prototype. Werkt technisch, heeft een database (Supabase), maar staat op zichzelf. Logt geen data in Exact Online, praat niet met HubSpot, 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 wij in 2026 binnenkrijgen van MKB-klanten zijn type 2. Ze worden aangezien voor type 3. Dat verschil kost tijd en geld.
Een voorbeeld uit onze praktijk. Een installatiebedrijf van 35 medewerkers in de regio Utrecht bouwde in Lovable een portal waarmee monteurs hun werkbonnen konden registreren. Het zag er professioneel uit, werkte soepel in de demo, en de directeur belde ons enthousiast op: "Kunnen jullie dit even aan Exact Online koppelen?" Wat bleek: de data moest gesynchroniseerd worden met factuurregels in Exact, het systeem had drie gebruikersrollen nodig (monteur, projectleider, administratie), en de ISO-auditlog vereiste dat elke wijziging traceerbaar was. We zijn zes weken bezig geweest. Niet met "de koppeling", maar met de helft van de productontwikkeling die nog moest komen.
De code is niet de bottleneck. De integratie is de bottleneck.
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 wij in 2026 gebruiken en waarom
Er is geen one-size-fits-all keuze. De tool hangt af van wat je wil bereiken en 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 |
Onze werkwijze: voor een eerste MKB-MVP starten we vrijwel altijd met Lovable of Bolt voor de UI-laag. Snel, visueel sterk, goed voor stakeholder-feedback in week één. Daarna bouwen wij de businesslogica, rechtenstructuur en integraties. Claude Code gebruiken we intern voor complexere backends en AI-agent logica.
Wij schreven eerder uitgebreid over de vibe coding aanpak in de context van MKB-klanten: zie ons artikel over vibe coding. De kern: het gaat niet om de tool, het gaat om wat je bouwt nádat het prototype staat.
Wat Lovable en Bolt bewust niet doen: ERP-koppelingen, rolgebaseerde rechtenstructuren, en beheer na livegang. Dat is geen tekortkoming, dat is ontwerp. Ze zijn gebouwd voor validatie. Productie is een ander spel.
De 3 momenten waarop AI-MVPs voor MKB vastlopen
Dit is de kern van dit artikel. Niet de bouw zelf strandt de meeste MVPs, maar wat daarna komt.
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 is aanzienlijk: MKB-bedrijven die workflow-automatisering professioneel implementeren besparen gemiddeld 15 tot 30 uur per week aan handmatig werk, met een terugverdientijd van drie tot zes maanden (Vynexo, 2026). Maar dat geldt alleen als de integratie correct is gebouwd.
Knelpunt 2: Authenticatie en rechtenstructuur
In een intern MKB-tool zijn er altijd rollen: manager, medewerker, klant. Lovable genereert standaard authenticatie via Supabase Auth: e-mail, wachtwoord, bevestigingsmail. Dat werkt voor een public SaaS, maar niet voor een intern systeem waar een monteur alleen zijn eigen werkbonnen ziet en de projectleider die van zijn hele team.
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. Achteraf RLS toevoegen aan een bestaand prototype is bijna altijd makkelijker te vermijden door het direct in het datamodel te verwerken.
Knelpunt 3: De overgang naar productie en beheer
Lovable's stack is exporteerbaar naar GitHub. Mooi. Maar wie beheert het daarna? Wie doet de security-patches als Supabase een kwetsbaarheid publiceert? Wie past de n8n-flows aan als Exact Online een API-versie depreceert? Wie is verantwoordelijk voor AVG-compliance als klantdata in de database staat?
Dit is geen technische vraag, het is een operationele vraag. De meeste zelfgebouwde MVPs stranden hier niet omdat de code breekt, maar omdat er daarna niemand verantwoordelijk is. Een goed MVP-traject eindigt niet bij livegang, maar bij een duidelijk beheerplan.
Wat kost een AI-MVP realistisch in 2026?
Hier zijn de eerlijke cijfers. Inclusief de nuances die je niet op een salespage leest.
| 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 |
| NDO als 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 | NDO + afgesproken beheerplan |
| Traditionele software-ontwikkeling | 3 tot 6 maanden | € 25.000 tot € 75.000 | Gemiddeld | Extern team of interne IT |
De bandbreedte bij een NDO-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. Een klantportal met HubSpot-data, drie gebruikersrollen en meerdere omgevingen (test, acceptatie, productie) zit aan de bovenkant.
Wat je bij NDO altijd krijgt: scoping, bouw, integratie-laag, testfase met echte gebruikers, en overdracht inclusief beheer-afspraken. We bouwen niets 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. Bij twee of meer vinkjes is het verstandig een partner te betrekken. Bij vier of meer: bouw niet alleen.
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. Drie systemen zijn al drie integraties. Vijf systemen zijn tien mogelijke verbindingen, elk met eigen foutscenario's en dataconflicten.
Onze inschatting op basis van trajecten die bij ons binnenkomen: bij ongeveer zes van de tien MVP-opdrachten die wij ontvangen, heeft de klant al een Lovable- of Bolt-prototype. In de meeste gevallen houden we de UI grotendeels intact, herbouwen we het datamodel, en bouwen we de integratie-laag van de grond af. Dat klinkt als meer werk, maar het is minder dan opnieuw beginnen met een verkeerde architectuur als fundament.
Hoe ziet een NDO MVP-traject eruit?
Geen abstracte praatjes. Dit is de volgorde die wij hanteren, stap voor stap.
Stap 1: Intake en scoping (1 sessie, circa 2 uur) We brengen 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) We bouwen de centrale functionaliteit, inclusief datamodel, authenticatie en de basisinterface. Afhankelijk van de stack gebruiken we Lovable, Bolt of Cursor.
Stap 3: Integratie-laag (1 tot 3 weken, afhankelijk van systemen) We bouwen de koppelingen met Exact, AFAS, HubSpot of andere systemen. Via n8n voor workflow-logica, custom API-connectoren waar de standaard-integraties niet volstaan.
Stap 4: Testfase met echte gebruikers (1 week) Geen UAT met fictieve scenario's, maar jouw team met echte data. We lopen erbij en fixen wat misgaat.
Stap 5: Overdracht en beheer-afspraken Jij krijgt de code, de documentatie, en een beheerplan. We leggen vast wie verantwoordelijk is voor wat na livegang en wat de opties zijn 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?
Eerlijkheid gaat twee kanten op. Als je een intern tool wil bouwen dat door maximaal drie mensen wordt gebruikt, geen koppeling met bestaande systemen nodig heeft, geen gevoelige klantdata verwerkt, en jijzelf of een collega wil beheren: dan kun je prima zelf starten met Lovable Pro (€ 25 per maand). Bouw het, test het, en schakel ons in als je het wil uitbreiden.
Wij zijn niet het goedkoopste alternatief. Maar we zijn ook niet het langzaamste. En we bouwen niets wat je daarna niet meer begrijpt.
Conclusie
De tools om een MVP te bouwen zijn in 2026 goedkoper en toegankelijker dan ooit. Maar de uitdaging is verschoven: niet de bouw is de bottleneck, maar de integratie met bestaande systemen, de rechtenstructuur en het beheer na livegang.
Als je een idee hebt voor een intern tool, klantportal of SaaS-product en je herkent jezelf in twee of meer van de checklistpunten hierboven: neem contact op voor een vrijblijvende scoping van 30 minuten.
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.
Het prototype bouwen is de makkelijke helft. Wij helpen met de andere helft.