Ich entwickle Software, die meine eigenen Probleme löst.

Taegliche stoische Reflexion in unter zwei Minuten - auf den echten Tag bezogen.

Stoizismus-Apps liefern generische Zitate ohne Bezug zum Alltag, Journal-Apps verlangen zu viel Input und fuehlen sich nach Arbeit an, und KI-Reflexionstools erfinden Zitate - bei philosophischen Quellen zerstoert das die Glaubwuerdigkeit sofort. Ambitionierte Nutzer wollen einen kurzen, praktischen Moment der Klarheit vor dem Tag: keine To-do-Liste, keinen Coach-Ton, keine erfundenen Weisheiten.

Alles end-to-end - Produktdefinition und PRD, modulare local-first Architektur, SwiftUI-Frontend, Domaenen- und Anwendungslogik als Swift Package, Kuratierung der geprueften Zitat-Datenbank, den gehaerteten Node-Backend-Endpoint fuer die KI-Generierung sowie Deployment, App-Store-Vorbereitung und Test-Strategie.

• Eine port-basierte, modulare Architektur haelt Produktregeln unabhaengig von SwiftUI und SwiftData testbar - die Domaenenschicht haengt von nichts ab und laesst sich ohne iOS-Simulator pruefen.
• Zitat-Halluzinationen sind kein Prompt-Problem, sondern ein Architektur-Problem: geloest durch eine deterministische Selektionspolicy, die der KI nur zulaessige Kandidaten uebergibt - die KI waehlt aus, erfindet nie.
• Die Generierung vom Client auf einen stateless Server-Endpoint zu verlagern, schuetzt den API-Key, deckelt die Kosten (ein Output pro Nutzer pro Tag) und erlaubt trotzdem einen lokalen Offline-Fallback.
• Text-Input-Latenz auf iOS ist real: eine eigene Untersuchung und Pufferung der Eingaben hat den Heute-Screen fluessig gehalten.

Ein wiederverwendbares Engineering-Setup für neue Projekte - professioneller Prozess ab Commit eins, ganz ohne Lock-in.

Jedes neue Projekt startet ohne Prozess: Git-Workflow, Quality Gate, Konventionen und KI-Leitplanken werden jedes Mal neu erfunden oder ganz weggelassen - gerade im Solo-Betrieb. Mit mehreren parallelen KI-Sessions kommt ein zweites Problem dazu: die Chats wechseln sich gegenseitig den Branch weg. Fertige Frameworks und Template-Repos lösen das nur um den Preis dauerhafter Bindung.

Alles - die Idee, die Extraktion des Prozesses aus einem echten Produktiv-Codebase, die stack-agnostische Kern-Doku, die Bash-CLI, die neun Stack-Varianten, das Bats-Test-Setup und die Agent-Integration (CLAUDE.md, --json, Setup-Skill).

• Ein wiederverwendbares Setup darf kein Framework sein: dokumentations-first, reine Dateien und kein Runtime schlagen jedes Template-Repo, weil das Projekt Eigentümer bleibt und nichts an DevBlueprint gebunden ist.
• Der Worktree-pro-Task-Ansatz ist der Punkt, an dem parallele KI-Sessions aufhören, sich gegenseitig den Branch wegzuziehen - ein einziges wt-Skript trägt den ganzen Workflow.
• Einen gemeinsamen Kern von dünnen Stack-Overlays zu trennen (core/ vs. variants/) hält neun Stacks wartbar: den Prozess ändert man an einer Stelle, nur das Stack-Spezifische liegt je Variante.
• Damit ein Agent ein Werkzeug bedienen kann, braucht es maschinenlesbaren Zustand (--json) und einen Dry-Run (plan == init --dry-run) - erst dann kann er vor dem Schreiben verlässlich bestätigen.
• Das eigene Setup auf sich selbst anzuwenden (Dogfooding) hat die Lücken am schnellsten gezeigt.