Zwölf Commits später stand im Impressum von theapparchitect.com: DigitalFreedom Global LLC, Wyoming. Das wirkt wie eine Kleinigkeit im Footer. Tatsächlich war es der sichtbarste Schritt einer Entscheidung, die ich schon länger mit mir herumgetragen hatte. Ich wollte weg von der Bindung an einen Ort und hin zu einer Struktur, die dazu passt, wie ich als App-Entwickler wirklich arbeite: remote, für Kunden in verschiedenen Ländern, ohne festen Schreibtisch an einem bestimmten Ort. Außerdem habe ich diese Woche etwas gebaut, das ich selbst täglich nutzen will, nämlich einen automatischen Podcast-Generator, der sich jeden Tag neu einstellt. Dazu gleich mehr.
Der Umbau auf die LLC: vier Websites, ein Tag, eine Entscheidung
Der Auslöser war banal. Ich saß vor den AGB auf theapparchitect.com und wollte die Rechtswahl aktualisieren. Dabei fiel mir auf, dass der genannte Betreiber der Website nicht mehr zu dem passte, was ich vermitteln wollte. Die LLC ist an keinen Standort gebunden. Sie ist eine saubere rechtliche Struktur für jemanden, der ortsunabhängig arbeitet und das auch so ausweisen möchte.
Der Umbau lief über mehrere Repositories gleichzeitig: theapparchitect.com, marcelrgberger.com und das GitHub-Profil. Überall dasselbe Vorgehen: Betreiber umstellen, Adressen aktualisieren, Impressum neu einspielen. Der rechtliche Teil ging schnell. Länger dauerte die Positionierung. Auf mehreren Seiten standen noch Formulierungen, die stillschweigend auf einen deutschen Standort verwiesen, etwa eine Präsenzgarantie auf den Regionalseiten oder die Rechtswahl als Verkaufsargument in den AGB. Beides habe ich gestrichen.
An dieser Stelle musste ich zweimal nachdenken. Ich hatte auf theapparchitect.com gerade eine neue Reihe regionaler Seiten gebaut, für Städte und Regionen mit jeweils eigenem Argument. Direkt danach merkte ich, dass eine Präsenzzusage auf diesen Seiten nicht stimmt, wenn ich mich gleichzeitig als „remote-first“ positioniere. Also wieder hinein, wieder heraus. Elegant ist das nicht, aber ehrlicher, als den Widerspruch stehen zu lassen. Die Seiten kommen jetzt ohne Präsenzzusage aus und haben dafür ein klareres Argument: Ich arbeite remote, und das ist kein Kompromiss, sondern ein Vorteil für Kunden, die keinen Entwickler im Nachbarbüro brauchen.
Die englische Seite bekam außerdem ihre eigene Währung: USD statt EUR. Das klingt selbstverständlich, war bisher aber nicht durchgängig umgesetzt. Wer über die englischsprachige Route kommt, sieht jetzt Preise in der Währung, die er erwartet. Die deutschen Seiten bleiben bei EUR. Eine winzige Änderung, die aber spürbar beeinflusst, ob ein Besucher in den ersten Sekunden Vertrauen fasst.
Die Podcast-Pipeline: 16 Commits für drei tägliche Folgen
Der zweite Schwerpunkt dieser Woche war technisch deutlich dichter und hat mir auch mehr Spaß gemacht. nblm-podcast-gen ist ein Projekt aus Shell-Skripten, das ich für mich selbst gebaut habe. Es erzeugt täglich drei persönlich zugeschnittene NotebookLM-Podcasts, ausgerichtet auf meine Ziele als unabhängiger Entwickler, mit jeweils über zwanzig verschiedenen Quellen pro Folge und bewusst auch mit kontroversen Sichtweisen.
Das klingt nach Bastelei. Tatsächlich steckt viel Logik darin, die ich im Laufe der Woche Schritt für Schritt aufgebaut habe. Das Hauptproblem am Anfang waren Wiederholungen. Ein fester Themenpool führte dazu, dass immer wieder dieselben Themen oben landeten, und das ist bei einem täglichen Format tödlich. Die Lösung bestand darin, die Themen jeden Tag neu zusammenzustellen, statt einen Pool rotieren zu lassen. Ein Skript sammelt täglich frische Hinweise: was ich gestern gemacht habe, was in meinen Projekten gerade läuft und welche Themen ich in letzter Zeit oft gehört habe. Daraus entsteht der Themenvorschlag für den Tag. Es gibt keinen festen Pool mehr und kein Weiterdrehen von Hand.
Dazu kommt ein Baustein, den ich Hörerprofil nenne. Früher war das eine fest eingetragene Liste im Hauptskript. Jetzt ist es eine eigene Datei, die sich mit der Zeit verändern kann: Interessen, Ziele und das, was gerade besonders wichtig ist. Dieses Profil liefert der Pipeline den Kontext, um Themen sinnvoll zu gewichten.
Dann kam ein Klassiker: ein Fehler, der erst nach dem ersten Lauf im Echtbetrieb auffiel. Der Zähler, der festhält, wie viele Podcasts an einem Tag bereits erzeugt wurden, brach nach dem ersten den gesamten Lauf ab. Die Ursache lag in der Logik zum Hochzählen, einem Off-by-one-Fehler in der Shell-Bedingung. Im Test war er nicht aufgefallen, weil die Tests mit einer eigenen Log-Datei liefen und nicht mit dem echten Zustand. Also musste ich zuerst die Testsuite sauber abtrennen, ohne gemeinsames Log und ohne gemeinsamen Zustand zwischen Test und Echtbetrieb. Erst danach konnte ich sicher sein, dass die Korrektur auch wirklich greift.
Das letzte Problem der Woche war subtil. Das Skript hielt NotebookLM zu früh für „fertig“, bevor die Plattform intern zu Ende gerendert hatte. Dadurch wurden gelegentlich leere oder unvollständige Ergebnisse als Erfolg gewertet. Die Lösung: Das Skript wartet ausdrücklich auf ein festgelegtes Render-Signal, bevor ein Lauf als abgeschlossen gilt. Einfach beschrieben, aber aufwendiger umgesetzt, denn ich musste zuerst verstehen, woran NotebookLM überhaupt „fertig“ erkennen lässt.
Am Ende der Woche läuft die Pipeline stabil. Die Lauf-Logs liegen außerhalb des Repositorys, sodass tägliche Ausgabedateien keine überflüssigen Commits erzeugen. Die Tests laufen getrennt vom Echtbetrieb. Und eine Obergrenze pro Thema verhindert, dass ein einzelnes Thema die Pipeline an zu vielen Tagen hintereinander bestimmt.
Was das mit App-Entwicklung zu tun hat
Die Umstellung auf die LLC ist für die meisten Leser eher Hintergrund. Der Podcast-Generator zeigt aber etwas, das ich in Kundenprojekten oft erlebe: Eine Automatisierung ist selten auf Anhieb fertig. Man baut das Gerüst, startet es und findet dann die Stellen, an denen die Wirklichkeit anders aussieht als die Spezifikation. Der Zählerfehler, das verfrühte Urteil über das Rendering und die fehlende Trennung der Logs waren im Entwurf nicht zu sehen. Alle drei zeigten sich erst beim ersten echten Lauf.
Das ist kein Scheitern, sondern normale Entwicklung. Wer das weiß, geht gelassener mit dem ersten Release um und plant ein realistisches Budget für die Nacharbeit ein.
Wenn Sie überlegen, eine eigene Automatisierung oder App entwickeln zu lassen, und wissen möchten, wie ich solche Projekte angehe, finden Sie das auf der Leistungsseite.
Den aktuellen Stand von theapparchitect.com mit den neuen regionalen Seiten und der überarbeiteten Preisdarstellung sehen Sie direkt auf theapparchitect.com.