Wanneer stap je over van vibecode naar maatwerk?

Maatwerk is software die voor jouw situatie is gemaakt en waarvan jij de code beheert, los van een bouwtool. Bij vibecoden maakt een AI ook code, dus het verschil zit niet in of er code is. Het zit in wie de code beheert, waar hij draait en of iemand hem begrijpt en kan onderhouden.

Er zit een glijdende schaal tussen:

1. Je bouwt en host alles in een tool zoals Lovable, Bolt of Replit.
2. Je bouwt in de tool, maar je code staat ook in je eigen GitHub en je database bij een dienst die je zelf beheert.
3. Je bouwt verder met een programmeerhulp zoals Cursor of Claude Code, op je eigen code, en host zelf.
4. Een ontwikkelaar of bureau heeft je project omgebouwd en houdt het bij.

Elke stap geeft je meer controle, maar ook meer verantwoordelijkheid. In de tool regelt de aanbieder de hosting en een deel van de beveiliging. Beheer je het zelf, dan moet iemand dat doen: jij of een ontwikkelaar. Dat kunnen wij zijn. Veel projecten hoeven nooit verder dan stap twee. Lees Eigen code en afhankelijkheid van het platform voor de basis.

Deze grenzen komen het vaakst voor:

• Snelheid. Pagina's laden traag als er meer data of gebruikers komen, en de tool biedt geen manier om dat op te lossen.
• Kosten. De kosten van je tool en de diensten eromheen stijgen sneller dan je inkomsten. Lees Wat kost het draaien?
• Beveiliging en eisen van klanten. Een zakelijke klant wil weten waar de data staat, wie erbij kan en hoe je het controleert, en in je tool kun je dat niet goed laten zien.
• Functies. Je hebt iets nodig wat de tool niet ondersteunt, zoals een koppeling met een ander systeem of werk dat op de achtergrond draait.
• Afhankelijkheid. Verandert de tool zijn prijzen of voorwaarden, of stopt hij, dan staat je project stil.
• Onderhoud. Elke wijziging via de AI maakt iets anders kapot en je komt niet meer vooruit.

Eén grens is nog geen reden om alles om te bouwen. Vaak is hij met een kleinere stap op te lossen, bijvoorbeeld door alleen je database te verhuizen of één onderdeel te laten herschrijven.

Een overstap is een project op zich. Zo blijft hij beheersbaar:

1. Code en data veilig. Je code komt in GitHub (opent in een nieuw tabblad)¹ en er is een volledige back-up van je database. Daarmee ben je minder afhankelijk, wat je verder ook kiest.
2. Beschrijven wat je project doet. Welke schermen, welke gegevens, welke koppelingen, welke betalingen. Dat is de basis voor iedereen die eraan werkt.
3. Kiezen: verbeteren of opnieuw bouwen. Vaak is de gegenereerde code bruikbaar als begin. Soms is hij zo rommelig dat opnieuw bouwen sneller en veiliger is. Dat beoordeel je alleen als je beide soorten projecten kent.
4. Verhuizen in stappen. Bijvoorbeeld eerst de database of de hosting, terwijl de rest even blijft zoals het was. Lees Hosting en een eigen domein en Waar staat je data?.
5. Testen met echte scenario's voordat gebruikers overgaan: inloggen, betalen, gegevens bekijken en verwijderen.
6. Gebruikers pas overzetten als alles werkt, met de oude versie nog even achter de hand.

Deze stap doen wij voor je: van een project in een AI-tool naar code die je zelf beheert. Jij beslist over de richting, wij doen het werk en houden je op de hoogte.

Bij een overstap verhuizen vaak ook de gegevens van je gebruikers. Daar gelden de gewone regels voor.

• Inloggen. Wachtwoorden zijn als het goed is opgeslagen als hash, een versleutelde vingerafdruk die je niet kunt terugrekenen, en laten zich daardoor niet altijd meeverhuizen. Soms moeten gebruikers een nieuw wachtwoord instellen. Dat vertel je ze vooraf. Lees Inloggen en gebruikers.
• Privacy. Verhuizen je gegevens naar een nieuwe dienst of een ander land, dan moet je privacyverklaring worden aangepast en is een verwerkersovereenkomst (opent in een nieuw tabblad)² met de nieuwe dienst nodig. Lees Privacy en de AVG.
• Betalingen. Lopende abonnementen bij je betaalprovider moeten blijven werken na de overstap. Dat wordt apart getest.
• Opruimen. Gegevens bij de oude dienst gaan weg als je ze niet meer nodig hebt (opent in een nieuw tabblad)³.

Een overstap plan je op een rustig moment, en je gebruikers horen vooraf wat er verandert en wanneer.

Na de overstap begint het onderhoud opnieuw. Je beheert nu zelf meer: de hosting, de updates, de back-ups. Iemand moet dat doen, en dat hoort vast te liggen. Wij kunnen het onderhoud na de overstap van je overnemen. Wat het inhoudt, lees je in Onderhoud na de lancering.

Overstappen kost tijd en geld. Het is niet nodig als je project doet wat het moet doen, je kosten in verhouding staan tot wat het oplevert en je de belangrijkste risico's kent en beheerst.

Een project dat in een tool blijft draaien, kan prima zijn. Dan moet wel de basis staan: je code staat ook in je eigen GitHub, je hebt back-ups van je database, je weet wat je doet als de tool stopt, en iemand heeft de beveiliging gecontroleerd. Dat laatste lees je in Is mijn app veilig?.

Twijfel je, dan lopen we in een gratis adviesgesprek de grenzen uit dit artikel met je langs: waar heb je nu last van, waar binnenkort en waar nooit? Dat maakt de keuze concreet.