Welk onderhoud heeft je project na de lancering nodig?

Software slijt niet, maar de wereld eromheen verandert. Je project draait op onderdelen van anderen: pakketten met code, een database, een inlogdienst, een betaalprovider, een AI-model. Die krijgen updates, veranderen van prijs of stoppen. In oudere versies worden beveiligingslekken gevonden.

Bij een gevibecodede app zie je dat niet vanzelf. De AI koos de onderdelen voor je, en jij weet misschien niet welke het zijn. Een dependency (afhankelijkheid) is zo'n onderdeel van een ander waar je code op leunt. Een gemiddeld project heeft er al snel tientallen.

Onderhoud betekent dus: weten waar je project op draait, bijhouden wat er verandert en op tijd ingrijpen.

Onderhoud werkt het best op een vast moment. Een uur per maand is voor een klein project vaak genoeg. Dan komen deze punten langs:

• Updates. Verouderde onderdelen en bekende beveiligingslekken worden opgespoord. Veel tools en GitHub (opent in een nieuw tabblad)¹ geven daar zelf meldingen over. Eerst gaan de beveiligingsupdates erin, daarna wordt getest of alles nog werkt.
• Back-ups. De automatische back-ups van je database moeten blijven draaien. Eens per kwartaal hoort er één teruggezet te worden in een testomgeving. Een back-up die nooit is teruggezet, is een hoop, geen plan. Lees Waar staat je data?
• Kosten. De facturen van je tools en diensten worden bekeken. Stijgt er iets onverwacht, dan moet duidelijk worden waarom. Lees Wat kost het draaien?
• Toegang. Wie heeft er nog toegang tot je accounts, je database en je code? Mensen die er niet meer bij hoeven, gaan eruit.
• Teksten. Klopt je privacyverklaring nog met wat je project doet? Is er een dienst bijgekomen, dan hoort die erin. Lees Privacy en de AVG.

Dit is het werk dat wij van je overnemen. Jij hoort van ons wat er speelt en wat er nodig is.

Je wilt eerder weten dat je project niet werkt dan je gebruikers. Daarvoor zijn twee soorten meldingen nodig:

• Bereikbaarheid. Een eenvoudige dienst controleert elke paar minuten of je site bereikbaar is en stuurt je een bericht als dat niet zo is.
• Foutmeldingen. Een dienst die fouten in je project verzamelt, laat je zien wanneer iets misgaat bij een gebruiker, ook als die het niet meldt. Let op: zo'n dienst kan persoonsgegevens meesturen (opent in een nieuw tabblad)². Hij moet zo zijn ingesteld dat hij dat beperkt, en hij hoort in je privacyverklaring.

Daarnaast tellen de berichten van je gebruikers. Een vaste plek voor vragen, zoals een e-mailadres dat je echt leest, voorkomt dat meldingen verdwijnen. Wat er binnenkomt is het bijhouden waard, want herhaling is een signaal.

De meldingen zetten wij voor je op, zodat een storing snel opvalt.

Een veelgemaakte fout na de lancering: de AI direct in je live project laten wijzigen. Gaat het mis, dan merken je gebruikers het meteen.

Een veilige wijziging gaat zo:

1. Eerst in een aparte versie of testomgeving. Veel tools hebben een manier om eerst een voorbeeld te bekijken.
2. De belangrijkste routes testen na elke wijziging: aanmelden, inloggen, betalen en gegevens opslaan. Lees Testen voordat je live gaat.
3. Een weg terug. Met je code in GitHub is een vorige versie terug te zetten (opent in een nieuw tabblad)³ als het misgaat.
4. Niet op vrijdagmiddag of vlak voor je vakantie. Dan is er niemand om het op te lossen.

Wie een wijziging maakt, moet kunnen uitleggen wat er veranderde. Is dat niet duidelijk, dan gaat de wijziging nog niet live. Zo werken wij ook als we je project bijhouden.

Naast je eigen code veranderen ook de tools en diensten waar je project op draait. Een bouwtool past zijn abonnementen aan, een AI-model wordt vervangen door een nieuwe versie, een gratis laag van een database krijgt nieuwe grenzen. Dat kan gevolgen hebben voor je project, ook als je zelf niets wijzigt.

Daarom hoort dit bijgehouden te worden:

• Een lijst van alle diensten die je project gebruikt, met het account waarmee je bent ingelogd en wie er toegang heeft.
• De e-mails van die diensten. Aankondigingen over prijzen, voorwaarden of het stoppen van een functie komen meestal per mail. Ze moeten binnenkomen op een adres dat iemand echt leest.
• De AI-modellen in je project. Wordt een model uitgefaseerd, dan is een overstap op een ander model nodig, en een test of de uitkomsten nog bruikbaar zijn.
• Wat je doet als een dienst stopt. Waar staan je gegevens, en kun je ze exporteren?

Dit is ook een moment om naar je privacyverklaring te kijken. Die lijst zetten wij voor je op. Een nieuwe dienst of een dienst die zijn opslag naar een ander land verplaatst, hoort daarin te staan.

Een storing of een lek vraagt voorbereiding voordat het gebeurt. Op een vaste plek hoort te staan:

• hoe je je project offline haalt of in onderhoud zet;
• hoe je een back-up terugzet;
• welke sleutels en wachtwoorden je moet vervangen als ze gelekt zijn;
• wie er gebeld wordt voor hulp.

Gaat het om persoonsgegevens die bij iemand terechtkomen die er niet bij mocht, dan is het een datalek. Volgens de Autoriteit Persoonsgegevens (opent in een nieuw tabblad)⁴ meld je dat binnen 72 uur na ontdekking, tenzij het waarschijnlijk geen risico oplevert voor de mensen om wie het gaat. Lees meer in Privacy en de AVG.

Groeit het onderhoud je boven het hoofd, of begrijp je de meldingen niet meer, dan hoef je het niet alleen te doen. Wij zetten met je op een rij wat er bij een storing of lek moet gebeuren. Lees ook Wanneer haal je een ontwikkelaar erbij? Wordt je project groter dan je tool aankan, lees dan Van vibecode naar maatwerk.