Freitagabend. Ich öffne mein Terminal, tippe git log --since="2026-07-13" und sehe einen einzigen Eintrag: der automatische Wochenpost vom letzten Sonntag. Das war es. Eine Woche, in der ich täglich am Rechner saß — und kaum etwas hinterlassen habe, das zählbar wäre.
Das ist der Moment, in dem man sich als Solo-Entwickler entscheiden muss, was man darüber schreibt. Die ehrliche Version, oder die aufgeräumte.
Ich schreibe die ehrliche.
Was ein leeres Commit-Log wirklich bedeutet
Sommelio ist live. Das war letzte Woche das Ereignis. Diese Woche war die Woche danach — und die fühlt sich bei jedem Projekt ähnlich an: ein bisschen leer, ein bisschen orientierungslos, ein bisschen wie der erste Tag nach einem langen Urlaub.
Nach einem Live-Release gibt es immer eine Phase, in der ich nicht sofort ins nächste Feature springe. Nicht aus Faulheit, sondern aus Kalkül. Ich beobachte erst. Wie verhält sich die App in freier Wildbahn? Welche Nutzungsmuster tauchen auf, die ich im Simulator nicht gesehen habe? Welche Abstürze kommen rein — oder, noch relevanter, warum kommen keine? Das ist keine passive Haltung. Das ist Informationssammlung, bevor ich anfange, in die falsche Richtung zu entwickeln.
Diese Woche war also Beobachtungsphase. Kein Umbau, kein neues Feature, kein Hotfix. Nur Hinschauen.
Parallel dazu habe ich angefangen, die nächste größere Sache zu durchdenken: eine macOS-App, über die ich hier noch nicht geschrieben habe. Noch kein Name, noch kein Repo, noch kein Commit. Nur Papier, Notizen, ein paar Skizzen auf dem Whiteboard-Block neben meinem Schreibtisch. Die Phase, in der ich entscheide, ob eine Idee es wert ist, dass ich sechs Wochen damit verbringe — oder ob sie beim genaueren Hinsehen ein Sackgassenprojekt ist.
Das ist die Arbeit, die im Commit-Log unsichtbar bleibt. Und gleichzeitig die Arbeit, die am teuersten wird, wenn man sie überspringt.
Die Lektion, die ich immer wieder lerne
Ich habe früh gelernt — durch eigene Fehler, nicht durch Ratschläge — dass die größten Zeitverluste bei Custom-App-Projekten nicht im Code entstehen. Sie entstehen in der Phase davor. Wenn jemand anfängt zu bauen, bevor er weiß, was er eigentlich baut. Wenn Architekturentscheidungen unter Zeitdruck gefällt werden, die sich später als Fundament herausstellen.
Ich habe Projekte gesehen — und selbst eines gebaut — bei denen eine Woche früher auf dem Papier sechs Wochen Umbau im Code gespart hätte. Das klingt nach einer Binsenweisheit. Aber wenn man mitten in einem Projekt steckt und der Stakeholder fragt, warum noch nichts zu sehen ist, ist es verdammt schwer, das zu verteidigen.
Deswegen nehme ich mir diese Wochen bewusst. Nicht jede Woche — das wäre Prokrastination mit besserem Branding. Aber nach einem Live-Release, am Anfang eines neuen Projekts, wenn ich merke dass ich Code schreibe ohne wirklich zu wissen wohin er führt: dann halte ich an.
Diese Woche war so eine Woche.
Ehrlicher Schlussbefund
Ich bin nicht zufrieden damit, dass die Woche so dünn war. Das wäre gelogen. Es gibt immer diesen kleinen inneren Widerstand, wenn ich auf einen fast leeren Commit-Log schaue — das Gefühl, ich hätte mehr liefern können.
Aber ich glaube auch nicht, dass jede Woche sichtbare Outputs produzieren muss, damit sie nützlich war. Die beste Architektur, die ich je gebaut habe, hat mit einer Woche angefangen, in der ich fast nichts geschrieben habe. Die schlechteste hat angefangen, weil ich zu ungeduldig war, anzufangen.
Nächste Woche wird wieder mehr zu zeigen sein. Entweder der erste Commit für das neue macOS-Projekt — oder der Entscheid, dass es das nicht wird, und warum.
Wenn du gerade darüber nachdenkst, eine App entwickeln zu lassen, und dich fragst, warum ein Architekt manchmal eine ganze Woche “nichts tut”: genau das ist hier die Antwort. Die Phase vor dem ersten Commit ist keine verschwendete Phase. Sie ist oft die wichtigste. Was dabei herauskommt, siehst du auf der Leistungsseite.
Alle meine aktiven Projekte — Sommelio, DokuAI und was als nächstes kommt — findest du unter /work.