Eine App, die fragt, wie der Tag war, und nach zwei Minuten wieder Ruhe gibt.
Im Dezember habe ich hier über Zeitmanagement zwischen Teamführung und Studium geschrieben. Kanban-Karten, handschriftliche Zusammenfassungen und der Satz, dass man bewusst entscheiden muss, was man nicht tut. Was in dem Beitrag nicht vorkam, ist der Blick zurück auf den einzelnen Tag. Habe ich mich heute bewegt? Wie habe ich geschlafen? Habe ich etwas gelernt, oder nur Termine abgearbeitet? Das sind Fragen, die man sich abends stellen kann. An vollen Tagen stellt man sie sich nicht, und genau an denen wären die Antworten am interessantesten. Aus dieser Lücke ist in den letzten vier Monaten eine App geworden. Sie heißt Tageswerk, steht im Play Store und hat inzwischen 21 Releases hinter sich. In dieser Reihe möchte ich erzählen, wie es dazu kam. In diesem ersten Teil geht es um die Idee und die erste Woche. Danach folgt, wie die weiteren Features hineingekommen sind, wie der Weg mit Claude bis in den Play Store aussah und wie man eine App weiterentwickelt, die schon bei Nutzern installiert ist.
Die Grundidee passt in einen Satz, und der steht seit dem ersten Tag im Anforderungsdokument: „Reflektiere deinen Tag in 2 Minuten und sieh, wie sich deine Gewohnheiten über Wochen, Monate und Jahre entwickeln.“ Man wählt ein paar Gewohnheiten aus, zum Beispiel Sport, Schlaf, Ernährung, Bildschirmzeit und Bildung. Die App stellt dann zu jeder aktiven Gewohnheit genau eine Frage. Wie gut hast du letzte Nacht geschlafen? Die Antwort ist ein Tipp auf eine Skala von 1 bis 5, ein Ja oder Nein, oder eine Zahl. Kein Freitext, den man ausfüllen muss. Das ist die wichtigste Regel im ganzen Projekt, und sie hat bis heute gehalten: Die Reflexion muss sich nur mit Antippen in unter zwei Minuten abschließen lassen. Alles, was mehr Zeit kostet, darf es geben, aber es darf nie Pflicht sein. Die meisten Apps in dem Bereich sind entweder reine Checklisten zum Abhaken oder schwergewichtige Coaching-Programme. Tageswerk sollte dazwischen liegen. Nachdenken über den Tag, aber ohne Ballast.
Bevor es eine Zeile Code gab, gab es drei Dokumente. Alle drei tragen das Datum 12. Juli 2026, und alle drei sind im Gespräch mit Claude entstanden. Das erste ist das Anforderungsdokument. Vision, Zielgruppe, eine MoSCoW-Liste mit zehn Must-haves, neun User Stories von FA-01 bis FA-09 und Akzeptanzkriterien als Gherkin-Szenarien. Dazu eine Liste mit dem Titel „Won’t-have“, auf der unter anderem Tablet- und Desktop-Versionen und KI-generierte Coaching-Empfehlungen standen. Auf diese Liste komme ich im nächsten Teil zurück, denn sie hat nicht lange überlebt. Das zweite Dokument ist der Tech-Stack mit den Entscheidungen T1 bis T5. Das dritte ist ein Business Case für die Monetarisierung. Ein Business Case für ein Feierabendprojekt klingt übertrieben, aber die Frage, was kostenlos bleibt und was nicht, bestimmt später die Architektur. Wenn die Grenze von drei Gewohnheiten im kostenlosen Tarif erst nach einem halben Jahr dazukommt, muss man sie an zwanzig Stellen nachrüsten. Der BWLer in mir war jedenfalls zufrieden.
Wer meine Beiträge aus dem letzten Jahr gelesen hat, erinnert sich vielleicht an das Projekt mit den vagen Anforderungen, bei dem wir am Ende die Ziellinie näher an das Produkt geschoben haben. Diesen Fehler wollte ich im eigenen Projekt nicht wiederholen. Ein Szenario wie „Given the user has 5 active habits, when the user starts the daily reflection, then each question can be answered with a single tap“ lässt wenig Raum für Interpretation. Das hilft mir, und es hilft dem Agenten. Ein KI-Agent baut genau das, was man beschreibt. Ist die Beschreibung vage, bekommt man etwas Vages, nur eben sehr schnell.
Die technischen Entscheidungen sind schnell erzählt. Die App ist mit Expo und React Native gebaut, die Website mit Next.js, beides in einem Monorepo mit pnpm und Turborepo. Das Backend ist Supabase, also Postgres mit Anmeldung, in einer EU-Region. Drei Regeln stehen seit dem ersten Tag in der CLAUDE.md, der Datei, die der Agent in jeder Session liest. Erstens sind die Zod-Schemas in einem eigenen Paket die einzige Quelle für das Datenmodell. Zweitens liegt die Geschäftslogik, also Serien, Reflexionsablauf und Berichte, als reine, getestete Funktionen in einem Kernpaket und nie in der Oberfläche. Drittens bekommt jede Tabelle vom ersten Tag an Row Level Security. Wer in so einer App seinen Schlaf und seine Stimmung einträgt, vertraut ihr etwas an. Bewusst entschieden habe ich mich außerdem für REST statt tRPC. tRPC wäre bequemer gewesen, kettet aber Client und Server an TypeScript. Vielleicht will ich irgendwann einen Dienst in Go oder Rust dahinter hängen. Ob das je passiert, weiß ich nicht. Die Entscheidung hat aber nichts gekostet.
Dann ging es los, und zwar schneller, als ich es von irgendeinem Projekt bisher kannte. Am Sonntag, den 12. Juli, hat Claude vormittags das Grundgerüst angelegt. Am selben Tag folgten die Gewohnheitsverwaltung, die Anmeldung per Einmalcode, der Cloud-Sync und die Kontolöschung. Am Montag kamen die Ratings, die geführte Reflexion und eine Suite von Integrationstests gegen eine lokale Datenbank. Am Dienstag das Nachtragen vergangener Tage, die Trend-Diagramme und der Wochenbericht. Bis zum Wochenende waren Erinnerungen, Serien mit einem Joker pro Woche und die Offline-Erfassung fertig. Am 19. Juli, sieben Tage nach dem ersten Commit, habe ich Version 0.1.1 getaggt. Damit waren alle neun User Stories aus dem Anforderungsdokument umgesetzt.
Das klingt nach einem Wunder, ist aber keins. In dieser Woche stehen auch Commits wie „Fix ReferenceError“, „Strip trailing slash from Supabase URL“ und „Fix tab bar showing crossed boxes instead of icons on Android“. Die Erinnerungsfunktion hat beim ersten Versuch mit einem 404 geantwortet. Das Tempo kam nicht daher, dass alles auf Anhieb funktioniert hat. Es kam daher, dass die Entscheidungen vorher getroffen waren. Für jede User Story gab es ein Issue mit Akzeptanzkriterien, und nach jedem Fehler ein Test, der ihn festhält. Ich habe in der Woche selbst kaum Code geschrieben. Ich habe die App auf dem Handy benutzt, aufgeschrieben, was nicht stimmt, und entschieden, was als Nächstes kommt. Das ist eine andere Arbeit als Programmieren, aber es ist Arbeit. Sie ähnelt eher der Rolle des Product Owners, die ich aus dem Beruf kenne, als der des Entwicklers.
Was ich aus dieser ersten Woche mitnehme: Die zwei, drei Stunden für die Dokumente am Anfang waren die am besten investierte Zeit im ganzen Projekt. Nicht weil Dokumente so schön sind, sondern weil jede spätere Frage eine Stelle hatte, an der die Antwort schon stand. Darf die Reflexion ein Pflichtfeld haben? Nein, NFA-01. Wo liegt die Serienberechnung? Im Kernpaket. Solche Fragen stellt ein Agent nicht, er entscheidet sie einfach, wenn nichts dasteht. Also muss etwas dastehen.
Nach einer Woche war das MVP also fertig. Eine fertige App ist das noch lange nicht, und dabei geblieben ist es auch nicht. Im nächsten Teil geht es darum, wie ein Stolz-Moment, ein Urlaubsmodus, neun Stimmungen und ein Satz über das eigene Selbstbild in eine App gekommen sind, die eigentlich nur fünf Fragen stellen sollte.