Je hebt iets gebouwd dat werkt en nu moet het naar buiten. Live zetten lijkt een knop, maar het is vooral een lijstje vragen dat je een keer beantwoord moet hebben. Hieronder staat dat lijstje, in de volgorde waarin wij het zelf aflopen.
Wat live zetten eigenlijk betekent
Zolang iets op jouw laptop draait, ben jij de enige gebruiker en ben jij ook degene die het merkt als er iets misgaat. Vanaf het moment dat er een adres op staat waar anderen naartoe kunnen, verandert dat. Er komen mensen die iets anders invullen dan jij bedacht had, er komen zoekmachines langs, er komen scripts langs die op elk adres ter wereld proberen of er een deur openstaat. Dat laatste is geen paranoia, dat is de normale gang van zaken op internet.
1. Waar staan je gegevens
Begin hier, want dit is het enige punt op deze lijst dat je achteraf niet meer goed kunt rechtzetten. Weet van elk stukje informatie waar het staat, wie erbij kan en of het het land uit gaat. Gaat er iets naar een taalmodel, dan telt de leverancier daarvan ook mee: kijk na of die je invoer gebruikt om zijn model te trainen en of je dat uit kunt zetten.
Staan er persoonsgegevens in, dan hoort daar een verwerkersovereenkomst bij met de partijen die ze voor je verwerken, en een regel in je privacyverklaring die klopt met wat er echt gebeurt.
2. Sleutels en wachtwoorden uit de code
Dit is de fout die we het vaakst tegenkomen, en ook de makkelijkste om op te lossen. Een API-sleutel of een wachtwoord hoort niet in de bestanden zelf, want die reizen mee naar elke kopie, elke back-up en elke map die je met iemand deelt. Ze horen in de instellingen van je server, los van de code.
Stond er al een sleutel in en heb je die met iemand gedeeld, verander hem dan. Een sleutel die ergens anders heeft gestaan is niet meer geheim, hoe klein de kans ook lijkt.
3. Een plek om te proberen
Zonder testomgeving oefen je op je klanten. Een tweede versie van je project, met een eigen database en nepgegevens erin, kost weinig en verandert hoe je werkt: je durft weer dingen te proberen. Het hoort samen te gaan met een manier om een wijziging in één handeling live te zetten, en om hem net zo makkelijk terug te draaien.
4. Back-ups die je een keer hebt teruggezet
Bijna iedereen heeft back-ups aan staan. Veel minder mensen hebben er ooit een teruggezet. Doe dat een keer, op je testomgeving, en noteer hoe lang het duurde. Dan weet je niet alleen dat het kan, maar ook wat het je kost als het echt nodig is.
5. Merken dat er iets stuk is
Zorg dat je het hoort voordat je klant het hoort. In de basis zijn dat twee dingen: iets dat elke minuut controleert of je site nog antwoordt, en foutmeldingen die ergens binnenkomen waar jij ze ziet. Voor allebei bestaan gratis of goedkope diensten, en het instellen kost een uurtje.
6. Wie mag wat
In een prototype is iedereen meestal beheerder, want jij was de enige gebruiker. Zodra er anderen bij komen, wil je dat een gewone gebruiker niet per ongeluk bij de gegevens van iemand anders kan. Controleer dat niet alleen in het scherm maar ook in de laag eronder, want een knop verbergen is iets anders dan een handeling verbieden.
Zelf doen of laten doen?
Doe je het zelf, dan ben je vooral tijd kwijt: reken op een paar avonden voor de punten hierboven, plus vaste kosten per maand voor hosting en monitoring. Laat je ernaar kijken, dan is een technische check een afgebakende opdracht waarna je precies weet wat er nog nodig is en wat dat kost.
Wat dat oplevert is geen nieuwe functie, en dat voelt soms als een vreemde investering. Wat je ervoor terugkrijgt is dat je weer durft door te bouwen. Meer daarover lees je op de pagina over zelfbouw en AI-prototypes, en hoe ver je met AI zelf komt staat in zelf software bouwen met AI.
