Zum Inhalt springen

Arbeitsweise

Vier Jahre habe ich Applikationen in einem Betrieb gebaut, seit dem Abschluss eigene Produkte, und zwar zu einem Teil AI-gestützt. Das ist der Grund, warum in neun Monaten sechs Projekte fertig geworden sind, und zugleich der Punkt, an dem berechtigte Fragen aufkommen. Deshalb steht hier nicht, dass ich sorgfältig arbeite, sondern woran man es nachprüfen kann.

Der Ablauf

Acht Schritte, jeder mit der Datei, die ihn belegt. Das Repository dieser Seite ist privat, Einsicht gebe ich auf Anfrage.

  1. Abklärung und Anforderungen

    Gespräch mit den Stakeholdern, bevor gebaut wird: Was soll das Vorhaben leisten, wer arbeitet damit, was ist gesetzt und was verhandelbar. Am Ende steht ein Umfang, den beide Seiten gleich verstehen.

    Belegt inDECISIONS.md

  2. Mockup

    Erst der Entwurf der Oberfläche, dann Code. Daran zeigt sich in einer Stunde, ob die Anforderung trägt; dieselbe Erkenntnis nach der Umsetzung kostet Tage.

    Liegt inEntrio-Repository, coach-dashboard-mockup.html

  3. Entscheidung vor dem Code

    Bei allem Strukturellen werden Kontext, geprüfte Optionen, Wahl und Konsequenz festgehalten, bevor gebaut wird. Später ist nachvollziehbar, warum etwas so ist, und nicht nur, dass es so ist.

    Belegt inDECISIONS.md

  4. Regeln und Skills

    Die Konventionen eines Projekts liegen im Projekt: Ordnerschnitt, Namen, Sprache, Teststrategie. Wiederkehrende Abläufe sind festgehalten, damit sie beim zehnten Mal so laufen wie beim ersten.

    Liegt inCLAUDE.md, dazu ~/.claude/skills

  5. Konvention aus der installierten Version

    Die Werkzeuge lesen die tatsächlich installierten Versionen und liefern die Vorgaben dazu. Sonst wird nach einem Stand gebaut, der älter ist als das Projekt selbst.

    Belegt in.mcp.json

  6. Umsetzung, AI-gestützt

    Der Teil, der delegiert werden darf. Geprüft wird das Ergebnis gegen die Entscheidungen und Regeln davor, nicht gegen Gedächtnis oder Gewohnheit.

    Belegt insrc/

  7. Prüfen und committen

    Vor jedem Commit laufen Formatierung, statische Analyse und die Projektregeln über die geänderten Dateien. Die Commit-Nachricht erklärt die Entscheidung, nicht die Zeilen.

    Belegt in.husky/pre-commit

  8. Automatisierte Prüfungen, dann live

    Bei jeder Änderung laufen statische Analyse, Tests, Produktionsbuild und Prüfungen im echten Browser durch. Einer der Schritte rechnet die Kontrastwerte aus den Farbtoken nach, statt sie zu schätzen. Fällt einer, wird nichts ausgeliefert.

    Belegt in.github/workflows/ci.yml

End-to-End gebaut und betrieben

Von der Architektur über die Zahlungsabwicklung bis zur signierten Windows-Distribution habe ich alle Schichten selbst gebaut und betrieben, mit echten Zahlungen seit März 2026 und Nutzern, die Fehler melden.