Wanneer haal je een ontwikkelaar erbij?

Er is geen vast moment, maar deze signalen komen vaak terug:

• De AI maakt dingen kapot terwijl hij iets anders repareert. Je vraagt om een kleine aanpassing en ergens anders gaat iets mis. Dat wijst op een project dat te groot is geworden om in één keer te overzien.
• Je weet niet meer hoe je project werkt. Je kunt niet uitleggen waar de gegevens staan, wie erbij kan of wat er gebeurt als een betaling mislukt.
• Je verwerkt gevoelige gegevens. Denk aan gezondheid, financiën, kinderen of bedrijfsgegevens van klanten.
• Er komt geld binnen. Vanaf dat moment kost een storing of een lek je klanten en vertrouwen.
• Een zakelijke klant stelt vragen over beveiliging, verwerkersovereenkomsten of waar de data staat, en je weet het antwoord niet.
• Je kosten lopen op zonder dat je weet waarom.

Herken je er een of meer, dan is het verstandig om iemand mee te laten kijken. Liefst voordat er iets misgaat, niet erna. In een gratis adviesgesprek kijken we welke signalen voor jouw project gelden.

Een voorbeeld. Je bouwde een boekingstool voor fysiotherapeuten. Het werkt, de eerste praktijken gebruiken het, en nu vraagt een praktijk of de gegevens van patiënten veilig staan. Dat zijn gezondheidsgegevens, waarvoor strengere regels gelden. Dat is precies het moment om een ontwikkelaar je database en toegangsregels te laten controleren, voordat de volgende praktijk zich aanmeldt.

Een ontwikkelaar erbij halen betekent niet dat je alles uit handen geeft. Er zijn verschillende vormen:

• Een controle. Iemand kijkt naar je project en vertelt wat er mis is of mis kan gaan, met name op het gebied van beveiliging, data en kosten. Jij beslist wat je daarmee doet. Lees Is mijn app veilig? om te zien waar het over gaat.
• Gerichte hulp. Een ontwikkelaar lost één onderdeel op, zoals inloggen, betalingen of de inrichting van je database, en jij bouwt de rest verder.
• Meekijken. Je blijft zelf bouwen en iemand beantwoordt je vragen en kijkt je werk na.
• Overdracht. Een ontwikkelaar neemt het project over en bouwt het om naar code die je zelf beheert. Lees daarover Van vibecode naar maatwerk.

Dit werk doen wij. Projecten uit AI-tools zien er van binnen anders uit dan projecten die een ontwikkelaar zelf begon, en juist daar kijken we naar. In een gratis adviesgesprek bepalen we samen welke vorm bij jouw project past.

Als iemand anders aan je project werkt, moeten een paar dingen goed geregeld zijn:

• Toegang zonder je wachtwoord. Wie meekijkt, krijgt een eigen account met eigen rechten, en die toegang gaat weer dicht als het werk klaar is. Je code staat dan bij voorkeur op één plek, zoals GitHub, een dienst waar code wordt bewaard. Lees Eigen code en afhankelijkheid van het platform.
• Persoonsgegevens niet onnodig open. Moet een ontwikkelaar bij de echte gegevens van je gebruikers, dan is hij volgens de AVG een verwerker en is een verwerkersovereenkomst nodig. Uitleg staat bij de Autoriteit Persoonsgegevens (opent in een nieuw tabblad)¹.
• Wie eigenaar wordt van de code. Volgens Ondernemersplein (opent in een nieuw tabblad)² heeft de maker automatisch het auteursrecht op wat hij maakt. Wil je dat als opdrachtgever zelf hebben, dan moet de overdracht schriftelijk worden vastgelegd.

De toegang en het overzetten van je code regelen wij. De afspraken teken jij; wij zetten op een rij wat erin hoort, en zeggen het als een jurist verstandig is.

Goede hulp bij een vibecode-project herken je aan een paar dingen:

• Eerst de vraag wat je wilt bereiken, voordat het over techniek gaat.
• Uitleg in gewone taal over wat er mis is en waarom het ertoe doet.
• Geen afkraken van je project. Een gevibecodede eerste versie is een prima begin; het gaat om de volgende stap.
• Duidelijkheid over wat wel en niet gebeurt, en over wie het werk na de oplevering bijhoudt.
• Eerlijkheid als je de hulp niet nodig hebt of als een andere oplossing beter past.

Daar houden we ons zelf ook aan. Daarom begint het bij ons met een gesprek over je project, en pas daarna met de techniek. Wat er gebeurt, spreken we vooraf met je af.

Met een ontwikkelaar aan boord hoef je niet te stoppen met bouwen. Veel vibecoders houden de onderdelen die ze goed overzien zelf in handen: teksten, schermen, kleine functies. De ontwikkelaar let op wat je niet ziet: beveiliging, data, kosten en de structuur van je code.

Bouw je zelf door in de tool terwijl er aan de code wordt gewerkt, dan kun je elkaars werk overschrijven. Daarom spreken we vooraf af hoe we samenwerken en hoe jouw wijzigingen bij ons terechtkomen.

Hoe beter je weet hoe je project werkt, hoe makkelijker je meebeslist. De woordenlijst helpt je met de begrippen. Wat er na de lancering bij komt kijken, lees je in Onderhoud na de lancering.