Ich öffne mein Terminal, tippe git log --since="2026-07-13" und sehe einen einzigen Eintrag: den automatischen Wochenbeitrag. Das war es. Eine Woche lang saß ich täglich am Rechner und habe kaum etwas hinterlassen, das sich zählen ließe.
An dieser Stelle muss man sich als Einzelentwickler entscheiden, was man darüber schreibt: die ehrliche Fassung oder die aufgeräumte.
Ich schreibe die ehrliche.
Was ein leeres Commit-Log wirklich bedeutet
Sommelio ist live. Das war das Ereignis der letzten Woche. Diese Woche war die Woche danach, und die fühlt sich bei jedem Projekt ähnlich an: etwas leer, etwas orientierungslos, ein wenig wie der erste Arbeitstag nach einem langen Urlaub.
Nach einem Release springe ich nie sofort ins nächste Feature. Das hat nichts mit Faulheit zu tun, sondern mit Kalkül. Zuerst beobachte ich. Wie verhält sich die App im echten Betrieb? Welche Nutzungsmuster zeigen sich, die ich im Simulator nicht gesehen habe? Welche Abstürze kommen herein, oder, noch aufschlussreicher, warum kommen keine? Passiv ist das nicht. Ich sammle Informationen, bevor ich womöglich in die falsche Richtung entwickle.
Diese Woche stand also im Zeichen der Beobachtung. Kein Umbau, kein neues Feature, kein Hotfix, nur genaues Hinsehen.
Nebenher habe ich begonnen, das nächste größere Vorhaben zu durchdenken: eine macOS-App, über die ich hier noch nicht geschrieben habe. Es gibt noch keinen Namen, kein Repository und keinen Commit, sondern nur Papier, Notizen und ein paar Skizzen auf dem Block neben meinem Schreibtisch. In dieser Phase entscheide ich, ob eine Idee sechs Wochen meiner Zeit wert ist oder sich bei näherem Hinsehen als Sackgasse erweist.
Diese Arbeit taucht im Commit-Log nicht auf. Gleichzeitig wird sie am teuersten, wenn man sie überspringt.
Die Lektion, die ich immer wieder lerne
Ich habe früh gelernt, und zwar durch eigene Fehler und nicht durch Ratschläge, dass die größten Zeitverluste bei individuellen App-Projekten nicht im Code entstehen, sondern in der Phase davor. Etwa wenn jemand zu bauen beginnt, bevor er weiß, was er eigentlich baut. Oder wenn Architekturentscheidungen unter Zeitdruck fallen, die sich später als Fundament herausstellen.
Ich habe Projekte gesehen, und selbst eines gebaut, bei denen eine Woche mehr Arbeit auf dem Papier sechs Wochen Umbau im Code erspart hätte. Das klingt nach einer Binsenweisheit. Steckt man aber mitten im Projekt und fragt der Auftraggeber, warum noch nichts zu sehen ist, lässt sich das verdammt schwer verteidigen.
Deshalb nehme ich mir diese Wochen bewusst. Nicht jede Woche, das wäre nur Aufschieberei mit besserem Etikett. Aber nach einem Release, zu Beginn eines neuen Projekts oder wenn ich merke, dass ich Code schreibe, ohne genau zu wissen, wohin er führt, halte ich an.
Diese Woche war so eine Woche.
Ehrliche Bilanz
Zufrieden bin ich damit nicht, dass die Woche so dünn ausgefallen ist. Alles andere wäre gelogen. Beim Blick auf ein fast leeres Commit-Log regt sich immer ein kleiner innerer Widerstand, das Gefühl, ich hätte mehr liefern können.
Ich glaube aber auch nicht, dass eine Woche sichtbare Ergebnisse braucht, um nützlich zu sein. Die beste Architektur, die ich je gebaut habe, begann mit einer Woche, in der ich fast nichts geschrieben habe. Die schlechteste begann, weil ich es nicht erwarten konnte, endlich loszulegen.
Nächste Woche gibt es wieder mehr zu zeigen. Entweder den ersten Commit für das neue macOS-Projekt oder die Entscheidung, dass daraus nichts wird, samt Begründung.
Falls Sie gerade überlegen, eine App entwickeln zu lassen, und sich fragen, warum ein Architekt manchmal eine ganze Woche „nichts tut“: Hier steht die Antwort. Die Phase vor dem ersten Commit ist keine verschwendete Zeit, sondern oft die wichtigste. Was dabei herauskommt, sehen Sie auf der Leistungsseite.
Alle meine aktiven Projekte, also Sommelio, DokuAI und was als Nächstes kommt, finden Sie unter Projekte.