Montagmorgen, 06:23 Uhr. Ein automatisierter Job hätte es auch erledigen können — aber ich habe es von Hand gemacht: YouTube-Daten auf jasminelise-beauty.de aktualisiert, gepusht, fertig. Ein Commit. Danach: nichts. Keine weiteren Commits diese Woche. Kein neues Feature, kein neues Release, kein Umbau. Nur dieser eine kleine Handgriff an einer laufenden Client-Site. Das ist die Woche, wie sie war.
Ich schreibe das trotzdem auf. Nicht um sie größer zu machen, als sie ist — sondern weil genau das der Punkt ist.
App-Architektur bedeutet auch: Dinge einfach laufen lassen
jasminelise-beauty.de ist eine Astro-Site, die ich für ein Beauty-Studio gebaut habe. Sie ist live, sie funktioniert, die Inhaberin ist zufrieden. Einmal pro Woche oder so schaue ich drüber, ob irgendwas klebt. Dieser Montag: die YouTube-Daten waren veraltet. Der Build zieht die Kanal-Informationen zur Compile-Zeit aus der API — Abonnentenzahl, neueste Videos, das übliche. Die Daten lagen ein paar Wochen zurück. Also: npm run fetch-yt, Daten gecheckt, committed, deployed.
Das klingt banal. Ist es auch. Und trotzdem ist es eine bewusste Entscheidung, die hinter dem Aufbau der Site steckt: Ich hole YouTube-Daten nicht live im Browser, weil das eine externe API-Abhängigkeit im Client erzeugt, die ich nicht kontrolliere. Stattdessen bake ich die Daten beim Build ein. Die Site bleibt schnell, bleibt unabhängig vom YouTube-Quota-Limit eines einzelnen Seitenaufrufs, und der Nutzer bekommt keine halbfertig geladene Seite, wenn Google mal langsam ist. Der Preis dafür: ich muss gelegentlich neu deployen, wenn die Daten zu sehr altern. Ein fairer Tausch.
Ehrlicher Moment: ich bin noch nicht entschieden, ob das langfristig die richtige Lösung ist. Ein Webhook-gesteuerter Rebuild — ausgelöst, sobald ein neues YouTube-Video erscheint — wäre eleganter. Dann würden die Daten sich von selbst aktualisieren, ohne dass ich montags um halb sieben einen manuellen Fetch mache. Den Umbau habe ich schon dreimal gedanklich begonnen und nie fertig durchgeplant. Irgendwann.
Was eine stille Woche über Wartung sagt
Ich lasse diese Woche so stehen, wie sie ist, weil ich glaube, dass das ehrlich ist — und weil es etwas zeigt, das im Build-in-Public-Kontext selten ausgesprochen wird: die meiste Zeit, die in eine laufende App oder Site fließt, ist unsichtbar. Sie taucht nicht im Changelog auf. Sie erzeugt keinen PR. Sie ist trotzdem Arbeit.
Wenn du überlegst, eine App entwickeln zu lassen, dann ist das der Teil, den du beim Vergleichen von Angeboten leicht übersiehst: Was passiert nach dem Launch? Wer hält das Ding am Laufen? Wer merkt, dass die Daten drei Wochen alt sind, und geht montagmorgens um 06:23 Uhr kurz rüber und fixt es?
Das ist keine dramatische Fähigkeit. Aber es ist der Unterschied zwischen einer App, die nach einem Jahr noch gepflegt aussieht, und einer, die langsam vor sich hin staubt.
Nächste Woche steht mehr an — ich möchte den YouTube-Refresh endlich automatisieren und habe noch ein offenes Thema in einem anderen Repo, das ich diese Woche bewusst liegengelassen habe. Dazu mehr, sobald es fertig ist.
Was genau ich für Kunden wie Jasmine Lise baue und wie meine Arbeit strukturiert ist, findest du auf der Leistungsübersicht.