Mittwochabend, ich scrolle über marcelrgberger.com und sehe am Ende jeder Seite dasselbe Element: ein Newsletter-Formular. Eingetragen haben sich in den letzten Wochen exakt null Menschen. Das war kein Überraschungsbefund — es war eine Bestätigung. Der Newsletter war eine Idee aus einer Phase, in der ich dachte, ich bräuchte einen Verteiler. Was ich tatsächlich brauche, ist ein Erstgespräch. Also habe ich den Formular-Block rausgeworfen und stattdessen den Buchungskalender direkt eingebettet. Klingt nach einem Nachmittagsprojekt. War es auch. Aber im Weg lagen ein paar Entscheidungen, die ich hier gerne aufschreibe.
Newsletter raus, Kalender rein: warum und wie
Der Newsletter hatte auf marcelrgberger.com nie eine echte Funktion. Er war ein Platzhalter für eine Content-Strategie, die ich nie vollständig umgesetzt habe. Was ich stattdessen schreibe — Build-in-Public-Posts, Case Studies, Gedanken zur App-Architektur — landet auf theapparchitect.com. marcelrgberger.com ist mein Portfolio. Wer dort landet, hat meinen Namen gegoogelt oder ist von einem Projekt auf mich gestoßen. Der nächste sinnvolle Schritt für diesen Besucher ist nicht “trag dich in einen Newsletter ein”, sondern “buch ein Gespräch”.
Die technische Umstellung war schnell erledigt: Das MailerLite-Embed flog raus, dafür kam ein eingebetteter Cal.com-Kalender rein. Den Termin heißt bei mir “talk-with-marcel” — nicht “discovery call”, nicht “strategy session”, einfach ein Gespräch. Die Sprache reiche ich per URL-Parameter durch, damit der Kalender auf der deutschen Seite auch auf Deutsch erscheint und auf der englischen Seite auf Englisch. Das war der Teil, der mich kurz aufgehalten hat: Cal.com unterstützt Locale-Parameter, aber die Dokumentation dazu ist dünn. Ich habe mit ?locale=de experimentiert, bis es zuverlässig funktionierte.
Was mich dabei leicht geärgert hat: Ich hatte den Termin zwischenzeitlich umbenannt und musste die Umbenennung wieder zurücknehmen, weil sich die Einbettungs-URL dadurch geändert hatte und der Kalender auf einer Seite leer blieb. Kleiner Fehler, aber genau die Art von Fehler, die einem bei schnellen Änderungen passiert — man zieht an einer Stelle, ohne alle Abhängigkeiten zu prüfen. Zwei Commits rein, ein Commit wieder raus. Das war mein Yak dieser Woche.
Die Texte, die ich dabei mitgezogen habe
Während ich die Einbettung umgebaut habe, sind mir auf marcelrgberger.com ein paar Formulierungen aufgefallen, die ich so nicht stehen lassen wollte. Der Kopfsatz und die Beitragszeile auf der deutschen Version waren zu wörtlich aus dem Englischen übertragen — man konnte förmlich spüren, dass jemand übersetzt hatte, statt auf Deutsch zu denken. Ich habe sie neu geschrieben. “Sinngemäß statt wörtlich” stand danach als Commit-Message — das trifft es gut. Deutschen Text, der wie übersetzter Englischtext klingt, merke ich inzwischen beim Vorlesen sofort. Er klingt ein bisschen zu ordentlich, zu symmetrisch, zu wenig idiomatisch.
Das ist eine Kleinigkeit in der Gesamtrechnung dieser Woche, aber mir ist wichtig, dass die Texte auf meinen eigenen Sites genauso sorgfältig behandelt werden wie die in Kundenprojekten. Die Seite, auf der jemand entscheidet, ob er mich für die Entwicklung seiner App beauftragen will, sollte nicht nach Übersetzung klingen.
Nebenschauplätze: Buch, security.txt, toter CSS-Block
Drei kleinere Dinge, die ich der Vollständigkeit halber erwähne.
Das Buch, an dem ich arbeite — “Solopreneur: The Art of Working Alone” — hat drei Commits bekommen. Keine inhaltlichen Ergänzungen, sondern eine Korrektur: An zwei Stellen im Text stand noch der alte Unternehmensname. Seit letzter Woche bin ich als DigitalFreedom Global LLC tätig, und der Buchtext sollte das korrekt widerspiegeln. Außerdem habe ich zwei Passagen geglättet, die durch das Umschreiben etwas unrund geworden waren. Kein Fortschritt am Inhalt, nur Sauberhaltung.
Für civo-cloud-manager.app habe ich eine security.txt nach RFC 9116 ergänzt. Das ist eine kleine Datei unter /.well-known/security.txt, die beschreibt, wie Sicherheitsforscher Schwachstellen melden sollen. Bei einer Marketing-Site ist das nicht kritisch — aber es gehört zum Handwerk, und ich hatte es bis jetzt schlicht vergessen. Wer eine native macOS-App für Kubernetes-Management baut, sollte das zumindest für seine eigene Website richtig machen.
Auf jasminelise-beauty.de ist parallel zur Newsletter-Ablösung auf meinen Sites auch ein toter CSS-Block rausgeflogen: übergebliebene MailerLite-Styles, die sich in den Stylesheet eingeschlichen hatten und dort seit Wochen unnötig Bytes verschwendeten. Kein sichtbarer Effekt, aber sauberer Code ist sauberer Code.
Was das für eine App-Beratung bedeutet
Ich schreibe das nicht, um die Woche größer klingen zu lassen als sie war. Es waren sieben Commits, keine große Architekturentscheidung, kein Release. Aber die Entscheidung dahinter — Newsletter durch direkte Terminbuchung zu ersetzen — ist genau die Art von Entscheidung, die ich auch für Kundenprojekte treffe: Was ist der tatsächlich nächste Schritt für den Nutzer? Was steht ihm im Weg? Was kann man weglassen?
Wenn du selbst überlegst, eine App entwickeln zu lassen, ist das oft die wertvollste Frage in der ersten Beratungsstunde: nicht “welche Features bauen wir?”, sondern “welchen einen Schritt soll der Nutzer als nächstes machen?” Alles andere folgt daraus. Wenn du das mit mir besprechen willst, kannst du direkt auf theapparchitect.com/contact/ einen Termin buchen — ohne Formular, ohne Newsletter.
Die Wochenübersicht zu meinen laufenden Projekten findest du wie immer unter /work.