Montagmorgen, Impressum auf theapparchitect.com: Marcel R. G. Berger, GbR. Montagabend, zwölf Commits später: DigitalFreedom Global LLC, Wyoming. Das klingt nach einer Kleinigkeit im Footer. Tatsächlich war es der sichtbarste Schritt einer Entscheidung, die ich schon länger mit mir herumgetragen hatte — weg von der Ortsgebundenheit, hin zu einer Struktur, die zu dem passt, wie ich als App Entwickler wirklich arbeite: remote, für Kunden in verschiedenen Ländern, ohne festen Schreibtisch an einem bestimmten Ort. Parallel dazu habe ich diese Woche eine Sache gebaut, die ich selbst täglich benutzen will: einen automatisierten Podcast-Generator, der sich jeden Tag neu kalibriert. Dazu komme ich gleich.
Der LLC-Umbau: vier Sites, ein Tag, eine Entscheidung
Der eigentliche Auslöser war banal. Ich saß vor den AGB auf theapparchitect.com und wollte die Rechtswahl aktualisieren. Dabei fiel mir auf, dass der Betreiber selbst — meine Gesellschaftsform — nicht mehr zu dem passte, was ich kommunizieren wollte. Eine GbR ist an Deutschland gebunden. Die LLC ist es nicht. Sie ist eine saubere juristische Struktur für jemanden, der ortsunabhängig arbeitet und das auch so stehen haben möchte.
Der Umbau lief über vier Repos gleichzeitig: theapparchitect.com, marcelrgberger.com, jasminelise-beauty.de und das GitHub-Profil. Überall dasselbe: Betreiber umstellen, Adressen aktualisieren, Impressum neu ziehen. Der juristische Teil war der schnelle Teil. Der langsamere Teil war die Positionierung. Ich hatte auf mehreren Seiten noch Formulierungen, die implizit auf einen deutschen Standort hinwiesen — eine Präsenzgarantie auf den Regionalseiten zum Beispiel, oder die Rechtswahl als Verkaufsargument in den AGB. Beides habe ich rausgeworfen.
Genau da lag der moment, der mich zweimal hat nachdenken lassen: Ich hatte auf theapparchitect.com eine frische Reihe regionaler Seiten gebaut — Städte, Regionen, mit jeweils eigenem Argument — und direkt danach gemerkt, dass eine Präsenzzusage auf diesen Seiten inhaltlich nicht stimmt, wenn ich gleichzeitig “remote-first” als Positionierung fahre. Also wieder rein, wieder raus. Das ist nicht elegant. Aber es ist ehrlicher als der Widerspruch stehenzulassen. Die Seiten leben jetzt ohne Präsenzzusage, dafür mit einem klareren Argument: Ich arbeite remote, und das ist kein Kompromiss, sondern ein Vorteil für Kunden, die keinen Entwickler im Büro nebenan brauchen.
Die englische Seite bekam außerdem ihre eigene Preiswährung: USD statt EUR. Klingt selbstverständlich, war aber bis jetzt nicht konsistent durchgezogen. Wer über die englischsprachige Route landet, sieht jetzt Preise in der Währung, die er erwartet. Die deutsche Fläche bleibt in EUR. Das ist eine winzige Änderung mit echter Wirkung auf das Vertrauen der ersten Sekunde.
Die Podcast-Pipeline: 16 Commits für drei tägliche Episoden
Der andere Block dieser Woche war technisch wesentlich dichter — und hat deutlich mehr Spaß gemacht. nblm-podcast-gen ist ein Shell-Skript-Projekt, das ich für mich selbst gebaut habe: Es generiert täglich drei personalisierte NotebookLM-Podcasts, zugeschnitten auf meine Ziele als Indie-Entwickler, mit jeweils über zwanzig verschiedenen Quellen pro Episode, bewusst inklusive kontroverser Perspektiven.
Das klingt nach einem Wochenendbastelprojekt. Tatsächlich steckt da eine Menge Logik drin, die ich im Lauf der Woche Schritt für Schritt aufgebaut habe. Das zentrale Problem am Anfang war Wiederholung: Ein statischer Topic-Pool führte dazu, dass dieselben Themen immer wieder vorne landeten. Das ist bei einem täglichen Format tödlich. Die Lösung war eine tägliche Synthese statt eines rotierenden Pools. Ein Skript sammelt morgens frische Signale — was habe ich gestern gemacht, was läuft in meinen Projekten gerade, welche Themen habe ich in letzter Zeit oft gehört — und baut daraus den Topic-Vorschlag für den Tag. Kein statischer Pool mehr, kein manuelles Drehen.
Dazu kommt eine Komponente, die ich das Listener-Profil nenne. Früher war das eine hartcodierte Liste im Hauptskript. Jetzt ist es eine eigene Datei, die sich mit der Zeit verändern kann — Interessen, Ziele, was gerade besonders relevant ist. Das Profil ist der Kontext, den die Pipeline braucht, um Themen sinnvoll zu gewichten.
Dann gab es einen Klassiker: Einen Bug, der erst nach dem ersten Produktionslauf aufgefallen ist. Der Counter, der zählt, wie viele Podcasts an einem Tag schon generiert wurden, hat nach dem ersten den ganzen Run abgebrochen. Der Fehler lag in der Increment-Logik — ein Off-by-one in der Shell-Kondition, der im Test nicht aufgefallen war, weil die Tests gegen eine eigene Log-Datei liefen und nicht gegen den echten State. Also musste ich zuerst die Test-Suite sauber isolieren — kein gemeinsamer Log, kein gemeinsamer State zwischen Test und Produktion. Erst dann konnte ich sicher sein, dass der Fix auch wirklich der Fix ist.
Das letzte Problem dieser Woche war subtil: Das Skript hat NotebookLM zu früh als “fertig” bewertet, bevor die Plattform intern fertig gerendert hatte. Die Konsequenz war, dass gelegentlich leere oder unvollständige Ergebnisse als Erfolg gewertet wurden. Die Lösung ist ein explizites Warten auf ein definiertes Render-Signal, bevor der Run als abgeschlossen gilt. Einfach in der Beschreibung, aufwendiger in der Umsetzung — weil ich erstmal verstehen musste, was NotebookLM überhaupt als “fertig” signalisiert.
Am Ende der Woche läuft die Pipeline stabil. Die Run-Logs bleiben außerhalb des Repositories — kein Commit-Rauschen durch tägliche Ausgabedateien. Die Tests laufen isoliert. Und ein Theme-Cap sorgt dafür, dass kein einzelnes Thema an zu vielen Tagen in Folge die Pipeline dominiert.
Was das mit App-Entwicklung zu tun hat
Die LLC-Umstrukturierung ist für die meisten meiner Leser eher Hintergrundinformation. Aber der Podcast-Generator illustriert etwas, das ich oft in Projekten für Kunden sehe: Automatisierung ist selten auf Anhieb fertig. Man baut das Gerüst, startet, und findet dann die Stellen, an denen die Realität nicht so aussieht wie die Spezifikation. Der Counter-Bug, das zu frühe Render-Urteil, die Log-Isolation — keines davon war im Entwurf sichtbar. Alle drei waren erst nach dem ersten echten Lauf sichtbar.
Das ist kein Scheitern. Das ist normale Entwicklung. Wer das weiß, geht entspannter mit dem ersten Release um — und budgetiert realistisch für die Iteration danach.
Wenn du überlegst, eine eigene Automatisierung oder App entwickeln zu lassen, und wissen möchtest, wie ich an solche Projekte herangehe, findest du das auf der Leistungsseite.
Den aktuellen Stand von theapparchitect.com — inklusive der neuen regionalen Seiten und der überarbeiteten Preisdarstellung — findest du direkt auf theapparchitect.com.