Je AI-app live zetten: checklist voor hosting, back-ups en monitoring

Zet alle accounts op je eigen naam

Het eerste wat ik bij een nieuwe klant controleer, is op wiens naam de accounts staan. Vaak draait de database op het persoonlijke account van een freelancer, hangt het domein onder het account van een bureau of staat de app nog alleen in de omgeving van de AI-tool. Zolang alles goed gaat, merk je daar niets van. Maar als die persoon onbereikbaar is of de samenwerking stopt, kun je niet meer bij je eigen app.

Zorg daarom dat elk account op naam van je bedrijf staat: de domeinnaam, de GitHub-omgeving waar de code staat, de database (bijvoorbeeld Supabase of Firebase), de hosting (zoals Vercel of Netlify) en je betaalaccount, zoals Stripe. Gebruik een zakelijk e-mailadres dat niet aan één medewerker vastzit, en zet overal tweestapsverificatie aan.

Werk je met een developer of bureau, geef die dan toegang als teamlid in plaats van het account op hun naam te laten staan. Zo houd je altijd toegang tot je broncode en je gegevens, en kun je iemands toegang intrekken zonder dat je app stilvalt.

Scheid testen en live, en houd geheimen geheim

Veel apps die met AI zijn gebouwd, hebben maar één omgeving. Elke wijziging staat dan meteen live bij je gebruikers, en een test met nepdata komt in je echte database terecht. Richt minimaal twee omgevingen in: een testomgeving waarin je nieuwe dingen uitprobeert en een productieomgeving voor je gebruikers, elk met een eigen database.

Sleutels en wachtwoorden, zoals de API-sleutel van je betaalprovider of de beheersleutel van je database, horen niet in de code. Zet ze in omgevingsvariabelen bij je hosting. Code wordt gedeeld, gekopieerd en soms per ongeluk openbaar gemaakt, en een sleutel die erin staat, is dan voor iedereen bruikbaar.

Let vooral op sleutels die in de browser terechtkomen. Alles wat de voorkant van je app gebruikt, kan een bezoeker zien. Sleutels met beheerrechten horen alleen op de server. Heb je ooit een sleutel in de code gezet, vervang hem dan door een nieuwe. Alleen verwijderen is niet genoeg, want hij staat nog in de geschiedenis van je code.

Back-ups: maak ze en test of ze werken

Een database kan stukgaan, en nog vaker gooit iemand per ongeluk data weg, soms zelfs de AI-tool. Dan wil je een back-up hebben. Zoek daarom uit welke back-ups je hosting maakt, hoe lang ze bewaard blijven en of je ze zelf kunt terugzetten.

Neem Supabase als voorbeeld. Volgens de documentatie maakt Supabase dagelijks back-ups, maar voor projecten op het gratis plan raadt Supabase zelf aan om je data regelmatig te exporteren en ergens anders te bewaren. Op het Pro-plan kun je de dagelijkse back-ups van de laatste 7 dagen terugzetten. Wil je minder dan een dag aan data kunnen verliezen, dan is Point-in-Time Recovery een betaalde uitbreiding. En bestanden die gebruikers uploaden, vallen niet onder de back-up van de database: die regel je apart.

Een back-up die je nooit hebt teruggezet, is een aanname. Zet daarom minstens één keer een back-up terug in je testomgeving en kijk of alles werkt. Dan weet je hoe lang het duurt en wat je moet doen als het echt nodig is.

Monitoring: weet het voordat je klant het merkt

Zonder monitoring hoor je van je klanten dat je app eruit ligt. Uptime-monitoring controleert elke paar minuten of je app bereikbaar is en stuurt je een bericht als dat niet zo is. Daar zijn gratis en goedkope diensten voor, en het instellen kost je een kwartier.

Uptime zegt alleen dat je app aan staat, niet dat hij werkt. Daarom wil je ook foutmeldingen bijhouden. Een dienst voor error tracking laat zien welke fouten gebruikers tegenkomen, op welke pagina en hoe vaak. Zo zie je dat de betaalpagina faalt voordat iemand erover klaagt.

Spreek af wie die meldingen krijgt. Een waarschuwing in een mailbox die niemand leest, helpt niet. Kies één persoon die verantwoordelijk is, en zorg dat die weet wat er dan moet gebeuren.

Verstuurt je app e-mail? Regel SPF, DKIM en DMARC

Wachtwoordresets, bevestigingen en facturen: veel apps sturen e-mail. Belanden die in de spam, dan kan een nieuwe gebruiker niet eens inloggen. Of je mail aankomt, hangt voor een groot deel af van drie instellingen in de DNS van je domein: SPF, DKIM en DMARC.

Google vraagt van iedere afzender naar Gmail minstens SPF of DKIM, en van afzenders die veel mailen alle drie. Andere grote providers stellen vergelijkbare eisen. Verstuur je mail daarom via een dienst die daarvoor gemaakt is en volg hun handleiding voor de DNS-records.

Test daarna met een paar echte mailboxen, bijvoorbeeld Gmail en Outlook, of je berichten in de inbox aankomen en niet in de spam.

SPF

Een lijst in je DNS met de servers die namens jouw domein mogen mailen.

DKIM

Een digitale handtekening op je berichten, zodat de ontvanger kan controleren dat ze echt van jou komen.

DMARC

Een regel die ontvangers vertelt wat ze moeten doen met mail die SPF en DKIM niet haalt.

Privacy, voorwaarden en de AVG

Zodra je app namen, e-mailadressen of andere persoonsgegevens opslaat, geldt de AVG. Dat betekent niet dat je een jurist in dienst moet nemen, maar wel dat je een paar dingen op orde hebt voordat je live gaat.

Je hebt een privacyverklaring nodig waarin staat welke gegevens je verwerkt, waarom en hoe lang je ze bewaart. Algemene voorwaarden regelen wat gebruikers van je mogen verwachten en waar je aansprakelijkheid ophoudt. En laat je gegevens verwerken door leveranciers, zoals je hosting, je database of je maildienst, dan sluit je met hen een verwerkersovereenkomst. Dat is verplicht volgens artikel 28 van de AVG. De meeste grote partijen hebben een standaardversie die je kunt aanvragen of accepteren.

Kijk ook waar je data staat. Een database in de EU maakt het een stuk eenvoudiger dan een server buiten Europa. Bij de meeste diensten kies je de regio bij het aanmaken van een project, dus doe dat bewust.

Dit artikel is geen juridisch advies. Twijfel je over wat jouw app nodig heeft, vraag het dan aan een jurist die zich met privacy bezighoudt.

Kosten die meegroeien, en wie je belt als het misgaat

De gratis plannen van hosting, database en AI-diensten zijn ruim genoeg om te bouwen, maar niet altijd om te groeien. De kosten stijgen met het aantal gebruikers, de hoeveelheid data, het verkeer en elke aanroep naar een AI-model. Stel bij elke dienst een budgetwaarschuwing of bestedingslimiet in, zodat een drukke week of een fout in je code niet ongemerkt een hoge rekening oplevert.

Bedenk ook nu al wie je belt als er iets misgaat. Op een rustige middag kun je misschien zelf met de AI-tool een oplossing proberen. Maar ligt je app eruit terwijl klanten betalen, dan wil je iemand die de code kent en snel kan reageren. Leg dat vast voordat je het nodig hebt, met duidelijke afspraken over reactietijden.

Daar help ik bij. In mijn onderhoudsplannen houd ik je app in de gaten met monitoring, controleer ik dagelijks of er bekende kwetsbaarheden in de pakketten van je app zitten, werk ik ze bij en regel ik back-ups. Bij een storing reageer ik op werkdagen tussen 9:00 en 17:00 binnen 2 uur.

De checklist

Loop deze punten na voordat je echte gebruikers toelaat. Kun je een punt niet afvinken, zet het dan op je lijst voor deze week.

1. 1Domein, GitHub, database, hosting en betaalaccount staan op naam van je bedrijf, met tweestapsverificatie.
2. 2Je hebt een aparte testomgeving met een eigen database.
3. 3Er staan geen sleutels of wachtwoorden in de code, en sleutels met beheerrechten komen nooit in de browser.
4. 4Je weet welke back-ups er worden gemaakt en je hebt er één als test teruggezet.
5. 5Bestanden die gebruikers uploaden, worden apart geback-upt.
6. 6Uptime-monitoring en error tracking staan aan, en één persoon krijgt de meldingen.
7. 7SPF, DKIM en DMARC zijn ingesteld en je mail komt aan in Gmail en Outlook.
8. 8Je privacyverklaring en algemene voorwaarden staan online.
9. 9Je hebt verwerkersovereenkomsten met de leveranciers die persoonsgegevens voor je verwerken.
10. 10Bij elke dienst staat een budgetwaarschuwing of bestedingslimiet.
11. 11Je weet wie je belt bij een storing en hoe snel die reageert.