TL;DR
Ich starte ein größeres 3-Wochen-Projekt: eine vollautomatische Zeiterfassungs-App, die Browser- und Datei-Aktivitäten kombiniert und daraus selbstständig Arbeitszeiten berechnet. Diese Woche stand komplett im Zeichen der Planung: deutlich systematischer als bei meinen bisherigen Wochenprojekten.
Warum ich dieses Projekt baue
Die Idee für dieses Projekt entstand, weil mein Mann als Entwickler regelmäßig für verschiedene Kunden arbeitet und dabei schnell zwischen unterschiedlichen Kontexten wechselt. Mal bearbeitet er Dateien in einem Kundenordner, mal arbeitet er auf einer bestimmten Domain, mal auf dem Server oder in einer Cloud-Struktur. Das ist normaler Entwickleralltag, aber es bedeutet auch, dass man später viel Zeit darauf verwendet, die Tätigkeiten sauber zu rekonstruieren und korrekt aufzuschreiben.
Der entscheidende Punkt ist:
Jede echte Entwicklungsarbeit hinterlässt technische Spuren, die eindeutig einem Kunden oder Projekt zugeordnet werden können.
Speichert er eine Datei → gehört diese zu einem bestimmten Kundenordner.
Arbeitet er im Browser → gehört die Domain zu einem bestimmten Projekt.
Ändert er etwas in der Cloud oder auf dem Server → gehört der Pfad/Service ebenfalls zu einem Kunden.
Wenn man diese Events automatisch erfasst und sinnvoll zusammenführt, entsteht ein klarer Zeitstrahl:
„10 Minuten an Kunde A“
„30 Minuten an Kunde B“
„15 Minuten an Kunde A“
Diese zusammenhängenden Aktivitätsblöcke ergeben am Ende eine vollständige, präzise Zeiterfassung – komplett ohne Timer und ohne manuelle Eingaben.
Aus dieser Überlegung entstand die Idee:
Warum nicht ein Tool bauen, das genau diese Aktivitäten automatisch erkennt und in echte Arbeitszeiten übersetzt?
Und genau das setze ich jetzt als mehrwöchiges Projekt um.
Wie ich dieses Mal geplant habe
Dieses Projekt ist deutlich umfangreicher als meine üblichen Wochenprojekte. Deshalb wollte ich dieses Mal nicht sofort mit dem Code anfangen, sondern erst einmal eine vollständige technische Grundlage schaffen.
Dafür habe ich eine LLM-gestützte Planungsmethode genutzt: eine Mischung aus eigenen Überlegungen und einer sehr strukturierten Zusammenarbeit mit Claude Code.
Schritt 1: Die Grundidee skizzieren
Ich wusste bereits grob, welche Bausteine das System braucht:
Browserüberwachung
lokale Dateiüberwachung
Serverüberwachung
ein Backend zur Auswertung
und ein Dashboard zur Anzeige
Schritt 2: Claude Code als Planungsassistent
Ich habe Claude Code meine Idee erklärt und gepromptet:
„Erstelle mir eine HTML-Seite, die dieses komplette Projekt plant.“
Diese Seite war der Ausgangspunkt.
Danach habe ich jede Komponente schrittweise verfeinert.
Für jeden Teil – Browser Extension, File Watcher, Backend, Frontend – habe ich gesagt, was mir wichtig ist. Daraufhin hat Claude Code passende Vorschläge gemacht. Wenn es mehrere Optionen gab, habe ich mir die Vor- und Nachteile erklären lassen und dann bewusst entschieden, was für dieses Projekt sinnvoll ist.
Schritt 3: Eine Liste offener Fragen als zentrales Werkzeug
Parallel hat Claude Code die ganze Zeit eine Liste offener Fragen geführt.
Das war sehr hilfreich, weil dadurch keine Entscheidung verloren ging.
Wir haben diese Liste regelmäßig durchgearbeitet und die Antworten direkt in die HTML-Dokumentation übernommen.
Schritt 4: Eine vollständige, eigenständige Dokumentation
Am Ende ist eine komplette Sammlung von HTML-Seiten entstanden:
Überblick über alle Komponenten
Browser Extension
Dateiüberwachung
Backend
Frontend
Datenbankstruktur
Aufbereitungslogik
Wochenplan
Edge Cases
offene Fragen und deren Antworten
Diese Form der Planung fühlt sich an, als würde man mit einem kleinen Team arbeiten, nur dass das „Team“ aus dir selbst und Claude Code besteht. Und der große Vorteil:
Alle Informationen liegen in den HTML-Seiten. Das heißt, der Kontext ist dauerhaft gespeichert und unabhängig vom aktuellen Chat.
Was in Woche 1 entstanden ist
Diese Woche ging es ausschließlich um Planung, aber dafür extrem gründlich:
komplette Architektur des Systems
Datenbankdesign (Events, Activities, Kunden, Settings)
definierte API-Struktur
detaillierte Beschreibung der Aufbereitungslogik
Tools und Technologien ausgewählt
Übersicht über alle Edge-Cases
technische Entscheidungen dokumentiert
klare Trennung der kommenden Arbeitspakete
Plan für die nächsten Wochen
Woche 2 – Implementierung (Backend & Datenerfassung)
Backend & Datenbank
Node/Express (TypeScript) aufsetzen
MariaDB aufsetzen + Tabellen/Indizes anlegen
Endpoints für Web- und File-Events
Kundenverwaltung (Patterns: URL/Pfade)
Aufbereitungs-Service implementieren (Sessions, Matching, Validierung, Zusammenführung)
Activities/Settings API + Swagger
Datenerfassung
Browser Extension (Manifest V3)
Content Script (Scroll/Klick/Keydown)
Service Worker (Buffer, 30s-Sync, Badge)
File Watcher (lokal + Server; optional Drive später)
Woche 3 – Frontend & Testing (inkl. Go-Live)
Frontend
React/Vite Setup + Routing + Query
Dashboard (Zeit/Customer-Übersichten, Filter)
Kundenverwaltung + Settings/Admin (Processing triggern, Reset etc.)
Testing & Go-Live
Integration Tests (Extension/FileWatcher → Backend → Processing → Frontend)
End-to-End-Szenarien (Web-only, File-only, Both, Pausen/Session-Split, zu kurze Sessions)
Deployment
Fazit
Woche 22: ✅
Die Planungswoche war extrem hilfreich und aufschlussreich.
Ich habe jetzt eine saubere Grundlage, auf der ich in den nächsten Wochen aufbauen kann.
Nächste Woche geht es endlich los: Backend, File Watcher und die ersten echten Events.
Ich freue mich darauf, das System Schritt für Schritt umzusetzen!
Bis nächste Woche!
