Wat ik controleer voor een startup live gaat

Live gaan voelt voor founders vaak als één technisch moment: de schakelaar omzetten en het product staat aan. In de praktijk is “live” een verzameling beslissingen die je een paar weken voor de daadwerkelijke launch goedkoop kunt nemen, of een paar weken erna duur kunt repareren.

Dit is wat ik standaard nakijk voor een vroege startup live gaat. Niet om er een security-audit van te maken, maar om de risico’s te beperken die in de eerste weken het meeste schade kunnen aanrichten.

De vraag is nooit “is alles perfect?”. De vraag is “weten we wat we niet weten, en kan het terug als het misgaat?”.

Een minimale productiecheck

Voor de daadwerkelijke launch wil ik antwoorden hebben op een korte set vragen:

• Wie controleert dat de live-versie ook echt de live-versie is, en niet per ongeluk de staging-bouw?
• Welke testgebruiker is verwijderd uit de productiedatabase?
• Welke debug-tools, console-logs, of testbetalingen staan nog open?
• Welke “voorlopig”-tekst staat er nog ergens?

Het zijn kleine dingen. Ze worden vrijwel altijd over het hoofd gezien omdat het bouwteam met andere dingen bezig is. Een founder kan zelf in een half uur alles doorlopen. Liever ervoor dan erna.

Logging en monitoring

Een productieomgeving zonder logging is een blackbox. Je weet pas dat er iets misgaat als een klant het meldt, en dan is die klant alweer weg.

Minimaal wat erin moet:

• Basislogging van fouten met een tijdstempel, een gebruikers-ID en de actie die werd uitgevoerd.
• Een melding naar iemand (mail, Slack) als er een onverwachte fout optreedt.
• Een uptime-monitor die controleert of de site überhaupt bereikbaar is.

Dit hoeft geen Datadog-installatie te zijn. Een eenvoudige error-rapportagedienst en een gratis uptime-monitor zijn genoeg voor de eerste maanden. Wat het wel moet doen: jou wakker maken voor je klant je belt.

Backups

Vraag voor de launch hoe vaak de database wordt geback-upt, waar de backups staan en hoe je ze terugzet. Test dat laatste één keer voor je live gaat. Een backup die nooit teruggezet is, is geen backup.

Wat je ook moet weten: wat verlies je in het ergste geval? Een uur werk? Een dag? Een week? Als je het antwoord niet hebt, weet je niet wat je risico is.

Foutmeldingen

Wat ziet een gebruiker als er iets misgaat? Een melding “er ging iets fout” is acceptabel. Een witte pagina, een stack trace of een Engelse foutmelding op een Nederlandstalig product is dat niet.

Loop voor de launch een paar voor de hand liggende fouten af: wat als iemand zijn wachtwoord vergeet? Wat als een betaling mislukt? Wat als de inlogpagina niet bereikbaar is? Wat als een download faalt?

De eerste indruk van klanten wordt vaak niet bepaald door wat werkt, maar door wat de eerste keer fout ging.

Betaalflow

Als je producten of abonnementen verkoopt, is de betaalflow het belangrijkste deel. Dit is wat ik standaard test:

• Een geslaagde betaling, krijgt de klant de juiste rechten, factuur en bevestigingsmail?
• Een mislukte betaling, wat gebeurt er, kan de klant het opnieuw proberen?
• Een terugkerend abonnement dat halverwege stopt, wat gebeurt er op de vervaldatum?
• Een terugbetaling, werkt die ook in de praktijk?

Voor de eerste klanten in een vroege startup heb je het liefst alle vier deze paden minimaal één keer in productie geverifieerd. Niet uit principe, maar omdat de hoek waarin betalingen fout gaan vaak de duurste klantgesprekken oplevert.

Een werkbaar supportproces

Wie reageert op de eerste klant die een vraag stelt? Op welk kanaal? Binnen welke tijd?

Een vroege startup hoeft geen 24/7-helpdesk te hebben. Maar er moet wel een afspraak zijn over hoe vragen binnenkomen, wie ze beantwoordt en wat de redelijke verwachting is voor je klant.

Praktische minimums:

• Eén e-mailadres dat actief gemonitord wordt.
• Een eenvoudige FAQ op de site met antwoorden op de vijf vragen die je het meest verwacht.
• Een interne notitie waar je veelvoorkomende vragen en antwoorden bijhoudt, zodat de tweede keer sneller gaat.

Security basics

Voor een vroege startup is dit geen volledige audit. Het is een korte checklist:

• HTTPS is afgedwongen voor alle paden (geen mengvorm met HTTP).
• Wachtwoorden zijn correct opgeslagen (gehashed, niet plain text).
• Toegang tot de productieomgeving is beperkt tot mensen die er werk in moeten doen.
• Geen geheime sleutels in de codebase of in een publieke repository.
• Tweefactor-authenticatie staat aan op je hosting, je domeinregistratie en je e-mail.

Dit zijn basics. Ze zijn vaak niet gedaan omdat ze niet urgent voelden. Tot het wel urgent wordt en het te laat is.

Voor founders die voor security-, AVG- of NIS2-vragen staan: dat zijn aparte gesprekken die niet binnen een launch-check passen. Maar de basics horen er wel in.

Een rollback-plan

Wat doe je als blijkt dat de nieuwe versie kapot is? Hoe ga je terug naar de versie van gisteren?

Voor een vroege startup hoeft dit geen geautomatiseerd proces te zijn. Het moet wel een proces zijn. Schrijf het op:

• Welke knop druk je, of welk commando voer je uit?
• Wat verlies je als je terugrolt (bijvoorbeeld databasewijzigingen)?
• Wie informeer je?

Een rollback-plan dat in iemands hoofd zit, is geen plan. Een plan in een notitie die je in tien minuten kunt uitvoeren, is genoeg.

Klantcommunicatie

Tot slot: een vroege launch betekent vaak dat er ergens iets misgaat. Dat is niet erg. Het wordt wel erg als je klanten daarvan niets horen.

Een simpele afspraak vooraf: als iets fout gaat, wie informeert klanten en hoe? Een korte mail die zegt “er ging iets mis, we kijken ernaar, we komen erop terug” is voldoende. Wat niet werkt: stilte van vier dagen waarna je een excuus moet bedenken.

Wat niet perfect hoeft te zijn

Veel founders stellen launches uit omdat iets “nog niet af” voelt. Dit is wat je niet hoeft te repareren voor je live gaat:

• Het ontwerp is niet overal pixel-perfect.
• Niet elke browser is getest.
• De onboarding kan slimmer.
• Er staan kleine inconsistenties tussen schermen.
• De marketingsite mist een paar pagina’s.

Dit zijn dingen die je beter na de launch verbetert met echte klantdata. Wachten tot ze klaar zijn betekent vooral dat je niet leert.

De vuistregel: alles wat klanten beschermt, betalingen, security, basis-foutafhandeling, moet voor de launch. Alles wat het product mooier maakt, hoort erna.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert