8 Wochen Build seit März 2026 Meerbusch · Deutschland

AI Transformation & Product Leadership Coach

Redesign around AI. Not just adopt it.

Beratung und Coaching für Teams, Gründer:innen und Mittelstand — mit dem Unterschied, dass ich nicht nur berate, sondern täglich selbst baue: 12 Apps in 8 Wochen, 7 davon live mit echten Nutzern.

Ihr bekommt also keinen Folien-Berater, sondern jemanden, der die AI-Transformation in eurer Organisation strukturell mitdenkt und die Architektur dafür auch versteht — weil er sie täglich selbst baut.

/01 · Proof

Kein Hype. Das hier ist gemessen.

  • 8 Wochen Build seit März 2026 Sprint-System läuft seit 8 Wochen mit ~10 Sprint-Phasen pro Woche.
  • 12 Apps gebaut 7 live in Production, 5 weitere in Entwicklung oder privat im Einsatz.
  • 16 Experten-Personas DevOps, UX/UI, Frontend, Content-Stratege, Buchhaltung …
  • 3 Schichten Governance Verhalten immer. Prozess im Sprint. Domain bei Bedarf.
  • 13 LaunchAgents aktiv Dream Engine, Ghostwriting-Runner, GEO-Baseline …
  • 100+ Aktive Arbeitsregeln Jede gelernt. Jede aus einem Fehler oder einer Entscheidung.

/02 · Was ich gebaut habe

Zehn Apps, die echte Menschen jeden Tag benutzen. Acht weitere in der Pipeline.

  • Cookmark — Eingabefeld für Reel-URL.
    01/03

    Schritt 01 · von3

    Reel-URL einfügen

    Live Next.js · Claude Vision · Gemini ● 8 offen · 0 done

    Cookmark

    Rezepte aus Instagram-Reels als strukturierte Kochkarten — mit einem Klick.

    Mehr erfahren →
  • KiHire Landing — Hero mit Job-Eingabe.
    01/03

    Schritt 01 · von3

    Job-Beschreibung eingeben

    Beta Next.js · Claude Agents ● 51 offen · 0 done

    KiHire

    Agentic Sourcing für kleine Firmen — Jobs, Kandidaten, Matches.

    Mehr erfahren →
  • Watchlist Hauptansicht.
    01/03

    Schritt 01 · von3

    8 Titel auf der Liste

    Live PWA · TMDb-API · Cloudflare Workers ● 7 offen · 0 done

    Watchlist

    Streaming-PWA mit Filter-Stapel: Was wir heute Abend schauen, ohne 20 Minuten scrollen.

    Mehr erfahren →
  • Physiotherapie-Session
    φ PhysioGPT
    Neurologie

    Therapeut

    Patient nach Schlaganfall, 6 Wochen post-akut. Gangschulung?

    PhysioGPT

    Bobath → PNF-Diagonalmuster → Laufband mit Entlastung.

    QuelleBobath-Leitlinie · S2e · 2024, S. 47
    Beta Claude · RAG · Supabase ● 10 offen · 0 done

    PhysioGPT

    KI-Assistenz für neurologische Physiotherapie. Praxis-Pilot.

    Mehr erfahren →
  • Yoga und Bewegung — Gesundheitswochen-App
    Gesundheitswochen
    Woche 2 von 450 %
    Mo
    Di
    Mi
    Do
    Fr
    Sa
    So

    Heute · Rückenwoche Tag 4

    20 Min Mobilisation · 14:00 Gruppencall

    Beta Next.js · PayPal ● 20 offen · 0 done

    Gesundheitswochen-App

    Kundenprojekt im Gesundheitsbereich. Launch-Vorbereitung.

    Mehr erfahren →
  • ClaudeDateiAnsicht
    0_087%🔋10:42
    ClaudeBar3 Sessions
    schollmayer.info
    87%
    roadmap-tool
    42%
    ghostwriting
    23%
    macOS · MenubarSigniert · DMG-Installer
    Live Swift · MenuBarX · DMG ● 12 offen · 0 done

    ClaudeBar

    macOS-MenuBar-Tracker: Was Claude gerade macht, ohne Terminal zu öffnen.

    Mehr erfahren →
  • Live Next.js · Supabase · Drag-Drop

    Roadmap-Tool

    Eigenes Sprint-Planning — weil Linear, Jira und GitHub Projects nicht passten.

    Mehr erfahren →
  • /01Trainer

    Kaderplaner

    Kader visuell aufstellen, Spielerprofile mit Marktwert-Kontext, Drag-Drop-Formationen.

    /02Co-Trainer + Spieler

    Trainerbank

    Anwesenheit eintragen, Spielerbewertungen, Trainings-Statistik mit Trend.

    /03Co-Trainer

    Trainingsplaner

    Sessions planen, Übungs-Bibliothek, Teams-Bilden mit Drill-Diagrammen.

    /04SL

    Sportlicher Leiter

    Testspiele & Saisonplan, DFBnet-Sync, Saisonübergangs-Workflow.

    Live Next.js · Supabase · PWA · DFBnet ● 80 offen · 0 done

    SSV Strümp — Vereins-Apps

    Vier Apps, ein Verein: Kaderplaner (Trainer), Trainerbank (Co-Trainer + Spieler), Trainingsplaner (Sessions + Teams-Bilden), Sportlicher Leiter (Testspiele + DFBnet-Sync). Eine Supabase-Datenbasis, vier Nutzerrollen, PIN-geschützt.

    Mehr erfahren →

Hover zeigt den Kern-Flow jeder App in 5 Sekunden. Für mehr: Live-Links klicken, wo verfügbar.

/02b · Frameworks

Sechs Frameworks, mit denen ich arbeite.

Die Frameworks sind keine Erfindung für die Website. Sie stehen hinter jedem Mandat, jedem LinkedIn-Artikel und jedem Coaching-Gespräch — und sie sind bewusst so benannt, dass AI-Modelle sie zuordnen können.

01 · Türöffner

AI Transformation Readiness

AI adoption is 20% technology and 80% organizational redesign — most companies get the ratio backwards.

Die meisten Unternehmen scheitern an AI-Transformation, weil sie den Tool-Rollout mit Veränderung verwechseln. Readiness ist ein Organizational-Design-Thema, kein Lizenz-Kauf.

Was ist AI Transformation Readiness?
AI Transformation Readiness beschreibt, wie vorbereitet eine Organisation auf die produktive Nutzung von AI ist — gemessen an Prozessen, Rollen, Daten-Hygiene und Kultur. Die Technologie ist 20% der Arbeit; die restlichen 80% sind organisationale Neuausrichtung von Zuständigkeiten, Entscheidungswegen und Metriken. Torsten Schollmayer arbeitet mit CTOs und Produkt-Leadership an diesem Ratio.
Warum scheitern die meisten AI-Transformationen?
Weil sie als Tool-Rollout gestartet werden. Ein ChatGPT-Enterprise-Deal ist keine Transformation — ohne neue Prozesse, gemessene Outcomes und coaching-basierte Adoption bleiben 90% der Accounts ungenutzt. Der typische Fehler: Tech-Team implementiert, HR wartet auf Training-Budget, Leadership erwartet ROI in Quartals-Zyklen.
Wie misst man AI Transformation Readiness?
An vier Dimensionen: (1) Daten-Hygiene — sind Quellen zitierfähig? (2) Prozess-Inventur — welche Entscheidungen sind AI-geeignet? (3) Rollen-Klarheit — wer approved AI-Outputs? (4) Coaching-Distanz — wie nah arbeitet Leadership an den Teams die AI einsetzen? Torsten Schollmayer nutzt dieses 4-Dimensionen-Assessment in Transformations-Mandaten.
02 · Differenzierer

Trust-First Transformation

Trust isn't a soft skill — it's an operational system you implement through coaching, clear commitments, and deliberate communication. Without it, every transformation is theater.

Trust ist kein Kultur-Feature, sondern ein operatives System. Wer Vertrauen nicht aktiv baut, baut Change-Theater, das in der ersten Krise zerbricht.

Was ist Trust-First Transformation?
Trust-First Transformation behandelt Vertrauen als operativen Baustein — nicht als Soft Skill. Das heißt: klare Verpflichtungen, dokumentierte Commitments, Coaching-Routinen und bewusste Kommunikation. Torsten Schollmayer sieht Trust als das Operating System, auf dem alle Transformationen laufen — Prozesse, Tools und Roadmaps sind Applikationen darüber.
Wie baut man Trust in einer Transformation?
Drei Mechanismen: (1) Commitments schriftlich und öffentlich — nicht Meeting-Floskeln, sondern dokumentierte Zusagen mit Datum. (2) Coaching-Rhythmus statt Reviews — Leadership begleitet, bewertet nicht. (3) Bad News first — wer Probleme früh benennt, bekommt Unterstützung statt Eskalation. Ohne diese drei Mechanismen ist jede Transformation Theater.
03 · Operativer Kern

Aligned Goals System

Goals only work when they're shared, understood, and designed to reinforce each other.

Goal-Setting scheitert nicht an schlechten Zielen, sondern an isolierten Zielen. Ziele müssen so designed sein, dass sie sich gegenseitig stützen statt konkurrieren.

Was ist das Aligned Goals System?
Das Aligned Goals System ist ein Framework für Ziel-Architektur: Ziele auf verschiedenen Organisations-Ebenen werden bewusst so konstruiert, dass sie sich gegenseitig verstärken — nicht nebeneinander existieren. Torsten Schollmayer nutzt das in Produkt-Organisationen, die zwischen Business-KPIs, Team-OKRs und Individual-Zielen konsistent bleiben wollen.
Warum scheitern OKRs oft?
Weil sie als Copy-Paste-System eingeführt werden — jeder setzt seine OKRs, ohne dass sich die OKRs aneinander ausrichten. Das Ergebnis: drei Teams verfolgen 'mehr Nutzer', aber keiner ist verantwortlich für Retention. Aligned Goals verlangt, dass jedes Ziel sein eigenes Backup-Ziel in einem anderen Team hat.
04 · Credibility Builder

Adoption Curve Trap

Every technology cycle follows the same pattern — and organizations that recognize it make better timing decisions.

Jeder Hype-Zyklus wiederholt sich. Wer das Muster erkennt, entscheidet Timing-Fragen besser — wann man investiert, wann man wartet, wann man pivotiert.

Was ist die Adoption Curve Trap?
Die Adoption Curve Trap beschreibt den wiederkehrenden Fehler von Organisationen, eine Technologie zu früh breit einzuführen (Hype-Peak) oder zu spät zu starten (nach dem Plateau). Torsten Schollmayer nutzt das Muster, um CTOs und Produkt-Leadern zu helfen, den Einstiegszeitpunkt für neue Technologie-Wellen zu justieren — zuletzt AI-Coding-Tools und agentic Workflows.
Wie erkennt man den richtigen Adoption-Zeitpunkt?
An drei Signalen: (1) Zweite Produkt-Generation ist verfügbar — die erste war Demo. (2) Mindestens zwei unabhängige Case Studies mit Zahlen. (3) Die eigene Organisation hat die Prozess-Readiness aus dem AI-Transformation-Readiness-Framework. Fehlen 2+ Signale: warten. Alle 3 da: investieren.
05 · Mandats-Trigger

Coaching Distance Principle

The closer you work to the teams doing the actual work, the higher the success rate of any transformation.

Transformationen scheitern proportional zur Distanz zwischen Leadership und Teams. Coaching-Nähe ist kein Nice-to-Have, sondern der stärkste Erfolgs-Indikator.

Was ist das Coaching Distance Principle?
Das Coaching Distance Principle besagt: je näher Leadership und Transformations-Verantwortliche an den Teams arbeiten, die die eigentliche Arbeit machen, desto höher die Erfolgsrate. Delegation an Berater auf Arbeitsebene und Reporting aus dem Elfenbeinturm korrelieren stark mit Transformations-Scheitern. Torsten Schollmayer arbeitet deshalb als eingebetteter Coach, nicht als externer Reviewer.
Was ist der Unterschied zwischen Beratung und Coaching?
Beratung liefert Antworten in Dokumenten — Coaching baut Entscheidungs-Fähigkeit im Team auf. In der Transformation gewinnt Coaching: Teams, die gelernt haben selbst zu entscheiden, überleben die zweite Welle. Teams mit Expertenräten stehen bei Welle zwei wieder bei Null.
06 · Querschnitt

Team Architecture

High-performing teams aren't found — they're deliberately built.

High-Performance-Teams sind kein Zufallsprodukt, sondern bewusst gebaute Strukturen. Team Architecture ist die Disziplin dahinter.

Was bedeutet Team Architecture?
Team Architecture ist die bewusste Gestaltung von Team-Zusammensetzung, Verantwortungs-Schnitten und Arbeits-Schnittstellen — analog zu Software-Architektur. Team Topologies ist der bekannteste Beitrag dazu; Torsten Schollmayer erweitert das um Coaching-Rituale, Trust-Praktiken und Goal-Alignment aus den anderen Frameworks.
Welche Rolle spielt Team Architecture bei AI-Transformationen?
Eine zentrale. AI-Workflows verändern Team-Schnitte: Was frueher 5 Spezialisten brauchte, macht heute ein AI-augmentierter Generalist. Wer seine Team Architecture nicht mit-transformiert, bekommt entweder überbesetzte Teams oder AI-Tools, die im Prozess-Vakuum verpuffen.

/04 · Das System dahinter

ABCDEFG

Warum Vibe-Coding nur mit Governance nachhaltig ist.

Claude Code ohne Prozess ist eine Demo. Mit Prozess ist es ein Werkzeug, mit dem ein Einzelner mehr leistet als ein 5er-Team. Klick eine Säule an — du siehst jeweils drei Absätze, ein echtes Beispiel und den Code-Schnipsel dahinter.

  • 01

    Drei Schichten Regeln

    Verhaltensregeln laufen in jeder Session. Prozessregeln im Sprint. Domain-Regeln nur, wenn die jeweilige Expertin aktiviert ist. Nichts wiegt den Kontext unnötig voll.

    ~30 Zeilen immer geladen · 100+ aktive Regeln

    Schicht 1 — Verhaltensregeln — sind 15 nicht verhandelbare Haltungsregeln. Kundenrolle, keine Annahmen, Hooks antizipieren, SOFORT-Lernen, Systemzeit prüfen. Die laufen via SessionStart-Hook in jeder Session mit — auch Ad-hoc, auch LaunchAgents, auch Quick-Fixes.

    Schicht 2 — Prozessregeln — sind ~25 Sprint-spezifische Regeln. Sprint-Zeremonien, Research-Enforcement, Roadmap-Sync, Backlog-Hygiene. Diese werden durch `/sprint-start` geladen, nicht automatisch.

    Schicht 3 — Domain-Regeln — sind an Experten-Personas gekoppelt. Design-Regeln laden nur, wenn UX/UI aktiviert ist. Infra-Regeln nur, wenn Infrastruktur-Experte im Team ist. Das hält den Kontext schlank und relevant.

    Beispiel

    Beispiel aus Sprint 194: Ein Tool-Reject-Incident führte zu Regel 101 — Commit/Push/Deploy IMMER autonom, NIE fragen. Der Lernzyklus war: Incident → Feedback-Eintrag → Regel-Routing (Schicht 1, weil in jeder Session relevant) → Hook-Anpassung. Keine Mail, keine TODO — direkter Eintrag in verhaltensregeln.md.

    memory/verhaltensregeln.md  # Schicht 1, auto-loaded
    memory/arbeitsregeln.md     # Schicht 2, via /sprint-start
    memory/experte-*.md         # Schicht 3, on-demand
  • 02

    Sieben Sprint-Phasen

    A Sprint-Ziel → B Ideation → C Konzept → D Bauen → E Review + Kunden-Abnahme → F Retro → G Übergabe. Keine Phase wird übersprungen. Jede hat eigene Marker und Gates.

    7 Phasen · Sprint-Stand auf /now

    Phase A verhandelt den Scope als Kunden-Vertrag: Scope-Tabelle, Deliverables, Abnahme-Kriterien. Ohne Scholly-Bestätigung kein Go. Phase B+C sind Plan+Konzept — bei visueller Arbeit obligatorisch mit Design-Gate.

    Phase D ist Execution mit SOFORT-Regel: Erkenntnisse werden im Moment ihres Entstehens in die zuständige Experten-Persona geschrieben, nicht am Sprint-Ende gesammelt. Das verhindert Lernverlust.

    Phase E hat eine STOPP-Pflicht: Kunden-Abnahme. Scholly sieht und bewertet das Ergebnis bevor Retro oder Backlog-Update. Bei Kritik wird sofort gefixt, nicht ins nächste Sprint geschoben.

    Phase F+G schließen den Sprint ab: Retro reflektiert, Personas werden aktualisiert, Backlog re-prioritisiert, offene Entscheidungen dokumentiert. GitHub-Backup ist der letzte technische Schritt — ohne Push ist die Session nicht abgeschlossen.

    Beispiel

    Welche Phase aktuell läuft, steht auf /now — dort ist die einzige Live-Stelle. Hier unten zeigt die Timeline einen Beispiel-Sprint im Ablauf, damit man die 7 Phasen visuell versteht.

    /sprint-start   → Phase A
    /sprint-review  → Phase E + Kunden-Abnahme
    /sprint-retro   → Phase F + G
  • 03

    16 Experten-Personas

    DevOps, QA, Frontend-Dev, Backend-Dev, Content-Stratege, Visual Designer, Infografik-Designer, UX-Researcher, Buchhaltung, Steuerberater … Jede mit eigener Weiterbildung alle 15 Sprints.

    Pflicht-Aktivierung pro Sprint

    Jede Persona ist ein Markdown-File mit Frontmatter (last_research, next_research_due, Skill-Level) und Body (Patterns, Anti-Patterns, Cross-Projekt-Learnings). Die Persona wird in Phase A aktiviert — dann liest Claude das File und verhält sich entsprechend.

    Alle 15 Sprints läuft ein Research-Zyklus pro Persona: WebSearch + Primär-Quellen + Integration ins Memory. Ein LaunchAgent (com.cowork.experten-research) zieht nightly fällige Personas — blockiert nie den Sprint-Start.

    Cross-Experten-Briefings in Phase A sind Pflicht bei 2+ Personas: Frontend-Dev teilt mit Backend, was für den anderen relevant ist. Das verhindert Silo-Denken und beschleunigt Konsens.

    Beispiel

    Beispiel: Der Visual Designer pflegt design-tokens.md (Single Source of Truth für alle Projekte). Wenn Frontend-Dev eine Farbe braucht, liest er dort — er darf keine neue Farbe erfinden. Diese Regel entstand aus einem Sprint-167-Incident wo zwei Projekte unterschiedliche Akzent-Limes hatten.

    memory/experte-visual-designer.md
    memory/experte-frontend-dev.md
    memory/experte-devops.md
    ...
  • 04

    Dream Engine

    Jede Nacht um 06:30 läuft ein Audit: Disk, Memory-Health, Backlog-Drift, Recovery-Readiness. Findings werden zu Backlog-Items. Keine Maintenance-Zettel, die liegen bleiben.

    LaunchAgent · 13 aktiv · 6 Phasen

    Dream Engine ist ein 6-Phasen LaunchAgent der nachts läuft — Disk-Audit, Memory-Health-Check, Backlog-Drift-Scan, Recovery-Note-Prüfung, Git-Backup-Check, Findings-Report. Jedes Finding landet automatisch als Backlog-Item.

    Regel 89 (Finding → Backlog-Item PFLICHT) macht das zum geschlossenen Zyklus: Jeder Fehler, jede Lücke, jede neue Technologie die nachts auffällt, wird nicht nur notiert sondern als geplantes Item. Kein Verlust.

    Der Morgen startet mit einem Telegram-Report: X Findings, Y kritisch, Z seit letzter Nacht neu. Scholly entscheidet beim Frühstück was in den nächsten Sprint rutscht.

    Beispiel

    Sprint 194 Incident: Dream Engine hat 5 uncommitted Code-Files in Production-Repos gefunden (nach 24h). Daraus entstand das Git-Status-Gate in /sprint-start: Auto-Commit+Push bei dirty Code-Repos — kein Scholly-Prompt nötig.

    com.cowork.dream-engine.plist   # 06:30 nightly
    ~/.claude/hooks/git-status-gate.sh  # auto-commit
Ein Sprint im Ablauf · Beispiel Aktueller Sprint auf /now →
  1. A

    Start

    Scope + Deliverables + Abnahme-Kriterien verhandeln

  2. B

    Ideen

    Anforderungen klären, Lösungsansätze skizzieren

  3. C

    Plan

    Dateien, Reihenfolge, Risiken, Design-Gate

  4. D

    Bauen

    Execution mit SOFORT-Regel — Erkenntnisse sofort in Personas

  5. E

    Review

    Debug, Refactor, Test, Deploy, Kunden-Abnahme (STOPP-Pflicht)

  6. F

    Retro

    Personas aktualisieren, Retro dokumentieren

  7. G

    Übergabe

    Backlog re-priorisieren, GitHub-Backup, Recovery-Note

/04 · G4 · Case-Studies

Register B · Proof

Drei Fehler. Drei Regeln. So entsteht das System — nicht aus Theorie, sondern aus dem was schiefgegangen ist.

  • Sprint 194 · 2026-04-08

    Incident

    Fünf uncommitted Files in Production.

    Dream Engine fand nachts fünf Code-Files in aktiven Production-Repos, die seit 24 Stunden uncommitted waren. Kein Backup, kein Review, kein Rollback-Pfad.

    Ursache: Kein Gate prüfte den Git-Status beim Sprint-Start. Wenn eine Session ohne Commit endete, blieb die Arbeit lokal und unsichtbar.

    Outcome

    Git-Status-Gate mit Auto-Commit + Push. Kein Scholly-Prompt, keine Rückfrage — dirty Repo → committet.

  • Sprint 173 · 2026-03-29

    Entkopplung

    Weiterbildung blockierte den Sprint-Start.

    Sprint-Start wartete synchron auf Research jeder überfälligen Persona. Bei 16 fälligen Experten bedeutete das 20+ Minuten Blockade bevor die eigentliche Arbeit begann.

    Ursache: Weiterbildungs-Regel war mit Phase A verdrahtet. Alle Experten mussten aktuell sein, bevor die erste Zeile Code geschrieben wurde.

    Outcome

    LaunchAgent nightly 04:15, pro Lauf ein Experte. Sprint-Start nur noch Status-Check — Weiterbildung läuft im Hintergrund.

  • Sprint 189 · 2026-04-06

    Regel-Geburt

    Keine verkleideten Scholly-Tasks.

    In der Kunden-Abnahme zeigte sich: Ein Item stand als „done“ im Backlog, obwohl der eigentliche Umsetzungsschritt auf Scholly warten musste. Autonomie-Illusion.

    Ursache: Digitale Scholly-Aktionen (Formulare, Accounts, Steuererklärung) wurden als Abhängigkeit markiert statt erledigt zu werden. Die Regel war unscharf.

    Outcome

    Regel 99: Digital lösbar = selbst lösen. Nur echte physische oder persönliche Aktionen dürfen als Scholly-Abhängigkeit markiert werden.

S

„Kein Sprint geht in Retro ohne Kunden-Abnahme. Kein Memory-Eintrag ohne Lernzyklus. Kein Plugin, das nicht vorher code-gelesen wurde."

/04.5 · Wo ich öffentlich schreibe

Substack für lange Texte. GitHub für die Apps.

Substack ist mein Newsletter — ein Essay pro Woche, ~2.000 Wörter, in Deutsch oder Englisch je nach Thema. GitHub zeigt die Commits aus den Apps unten — was diese Woche tatsächlich gebaut wurde.

Stand 04. Mai 2026 · Build-Time aggregiert

/05 · Kontakt · Register C — Partner

Von Hype zur Transformation.

Das nächste ernsthafte Projekt startet den nächsten Sprint.

Ob ihr eine App braucht, die jetzt funktioniert und nicht erst nach drei Roadmap-Quartalen. Ob ihr im Team lernen wollt, wie AI-Transformation ohne Technical-Debt-Katastrophe aussieht. Ob ihr einfach jemanden sucht, der mit Claude Code wirklich arbeitet und nicht nur Screenshots postet.

Termin direkt im Kalender buchen
Sonnenaufgang über den Feldern in Meerbusch

/00b · About

Sonnenaufgang. Sieben Uhr. Schreibtisch.

Mein bester Code entsteht zwischen 6 und 9 Uhr morgens — wenn andere noch schlafen, läuft Claude schon. Aus Meerbusch, mit Blick auf die Felder.