Op 17 augustus lag GitHub er grotendeels uit, veroorzaakt door een capaciteitsprobleem dat werd uitgelokt door een fout in VS Code. Voor wie met AI-tools bouwt is dat geen randgeval: je hangt aan meer externe diensten dan je denkt, en ze vallen zelden alleen uit. Hieronder waar de afhankelijkheden zitten en wat je in een uur kunt regelen.
Wie met moderne tools bouwt, leunt op een keten waarvan hij de helft nooit heeft gekozen.
Een prototype dat je vandaag maakt, hangt al snel aan zes of zeven externe diensten: het model dat je aanroept, het platform waar je code staat, de dienst die je bouwt en uitrolt, de plek waar je database draait, de partij die je mail verstuurt en het register waar je pakketten vandaan komen. Elk daarvan is een enkel punt waar het kan stoppen.
Het lastige is dat ze niet los van elkaar staan. De storing van deze maand liet dat zien: een fout in een editor veroorzaakte zoveel extra verzoeken dat het platform eronderdoor ging. Wie op dat moment wilde uitrollen, kwam er niet doorheen, ook al was er met zijn eigen code niets aan de hand.
Voor een prototype is een halve dag stilstand vervelend maar niet fataal. Het wordt anders zodra er echte gebruikers op zitten, of zodra je op een afgesproken moment iets moet laten zien. Dan is de vraag niet of het uitvalt maar of je er dan omheen kunt.
Niet alle uitval is gelijk. Deze drie leggen je daadwerkelijk stil.
Ligt je codeplatform eruit, dan kun je vaak nog lokaal werken maar niet meer uitrollen, want je uitrolproces haalt de code daar op. De oplossing is klein: houd een tweede kopie van je repository ergens anders, en zorg dat je uitrol ook vanaf je eigen machine kan draaien. Dat is een middag werk en het scheelt je een keer een deadline.
Valt het model weg, dan werkt niet je app maar de functie waar mensen voor komen. Dit is de enige afhankelijkheid waarvoor een terugvaloptie echt eenvoudig is, mits je de modelkeuze niet door je hele code hebt verspreid. Hoe je dat inricht staat in welk AI-model kies je.
Hier heb je in de praktijk het minst aan een tweede optie, want alles staat er nu eenmaal. Wat wel helpt is weten hoe lang het duurt om ergens anders op te starten, en dat een keer geprobeerd te hebben. Wie dat nooit heeft gedaan, ontdekt op het slechtste moment dat er een handmatige stap in zat die niemand had opgeschreven.
Geen enkele van deze maatregelen kost een dag, en samen halen ze het grootste deel van het risico weg.
Niet elke afhankelijkheid is het waard om te verzekeren.
Het is verleidelijk om na een storing alles dubbel te willen uitvoeren. Dat is voor een klein product zelden de goede afweging: twee van alles betekent twee keer onderhoud, twee keer configuratie en twee keer een plek waar iets kan verlopen. Meestal is de storing korter dan de tijd die je aan de verdubbeling kwijt bent.
De nuttige vraag is niet hoe je uitval voorkomt maar hoe erg het is als het gebeurt. Voor een intern hulpmiddel is een dag stilstand geen probleem. Voor iets waar klanten op rekenen is het dat wel, en dan zijn de maatregelen hierboven ruim voldoende. Er tussenin zit vrijwel alles.
Waar je wel altijd iets aan moet doen: gegevens die je kwijt kunt raken. Uitval is tijdelijk, gegevensverlies niet. Zorg dat je database en je bestanden ergens staan waar jij bij kunt zonder tussenkomst van de partij die eruit ligt, en dat je een keer hebt geoefend hoe je ze terugzet. Voor de bredere stap van proefopstelling naar echte gebruikers is er van prototype naar productie.
Op 17 augustus 2026 ontstond een grote storing die werd uitgelokt door een fout in VS Code, waardoor er zoveel extra verzoeken binnenkwamen dat de capaciteit tekortschoot. Voor gebruikers betekende het dat werken met de dienst en uitrollen vanaf die dienst grotendeels stillag, ook als er met hun eigen code niets aan de hand was.
Meestal zes of zeven: de modelaanbieder, het platform waar de code staat, de dienst die bouwt en uitrolt, de plek waar de database draait, de partij die mail verstuurt, het pakketregister en vaak nog een betaaldienst. Elk daarvan kan afzonderlijk uitvallen, en ze zijn onderling vaker verbonden dan het lijkt.
Nee, voor een klein product is dat zelden de goede afweging. Twee van alles betekent twee keer onderhoud en twee keer iets dat kan verlopen, en meestal duurt een storing korter dan de tijd die je erin steekt. Verdubbel alleen waar de schade van uitval echt groot is, en beperk je voor de rest tot back-ups en een uitgeschreven noodplan.
Een tweede kopie van je repository bij een andere aanbieder, automatisch bijgewerkt. Dat kost je eenmalig een halfuur en het zorgt ervoor dat een storing bij je codeplatform je hooguit vertraagt in plaats van stillegt. Direct daarna komt een back-up van je database die je daadwerkelijk een keer hebt teruggezet.
Dat moet je een keer geprobeerd hebben om het te weten. In veel projecten zit er een stap in de pijplijn die nergens is opgeschreven, en die ontdek je pas als je het handmatig probeert. Doe die oefening één keer op een rustig moment en leg de stappen vast.
Dat is de enige afhankelijkheid waarvoor een terugvaloptie eenvoudig is, mits je de modelkeuze op één plek hebt staan in plaats van verspreid door je code. Dan schakel je over naar een tweede aanbieder met een instelling. Houd er rekening mee dat je instructies mogelijk licht moeten worden aangepast.
Belangrijker dan het lijkt. Zonder vaste versies haalt je bouw elke keer de nieuwste variant op, wat betekent dat een storing bij een register of een gewijzigd pakket je bouw kan blokkeren of stilletjes iets anders kan opleveren. Vaste versies plus bewaarde installatiebestanden maken je bouw herhaalbaar.
Eén pagina met per dienst: wat je ervan gebruikt, wat er stopt als die uitvalt, wat het alternatief is en wie het doet. Meer heb je niet nodig, en minder betekent dat je op het moment zelf gaat improviseren. De waarde zit vooral in het opschrijven, want daarbij merk je welke afhankelijkheid je niet had zien aankomen.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.