8 weeks of building since March 2026 Meerbusch · Germany

AI Transformation & Product Leadership Coach

Redesign around AI. Not just adopt it.

Advisory and coaching for teams, founders, and the mid-market — with the difference that I don't just advise, I build daily: 12 apps in 8 weeks, 7 live with real users.

You won't get a slide-deck consultant, but someone who thinks AI transformation through structurally and understands the architecture that goes with it — because he builds it daily.

/01 · Proof

No hype. This is measured.

  • 8 Weeks of building since March 2026 Sprint system has been running for 8 weeks with ~10 sprint phases per week.
  • 12 Apps built 7 live in production, 5 more in development or used privately.
  • 16 Expert personas DevOps, UX/UI, Frontend, Content Strategist, Bookkeeping …
  • 3 Governance layers Behavior always. Process per sprint. Domain on demand.
  • 13 LaunchAgents active Dream Engine, Ghostwriting runner, GEO baseline …
  • 100+ Active work rules Each one learned. Each one from a mistake or a decision.

/02 · What I've built

Ten apps real people use every day. Eight more in the pipeline.

  • Cookmark — input field for reel URL.
    01/03

    Step 01 · of3

    Paste reel URL

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

    Cookmark

    Recipes from Instagram reels as structured cooking cards — with one click.

    Read more →
  • KiHire landing — hero with job input.
    01/03

    Step 01 · of3

    Enter job description

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

    KiHire

    Agentic sourcing for small companies — jobs, candidates, matches.

    Read more →
  • Watchlist main view.
    01/03

    Step 01 · of3

    8 titles on the list

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

    Watchlist

    Streaming PWA with filter stack: what to watch tonight, without 20 minutes of scrolling.

    Read more →
  • 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 open · 0 done

    PhysioGPT

    AI assistance for neurological physiotherapy. Practice pilot.

    Read more →
  • 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 open · 0 done

    Gesundheitswochen-App

    Client project in the health space. Pre-launch.

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

    ClaudeBar

    macOS menu bar tracker: see what Claude is doing without opening the terminal.

    Read more →
  • Live Next.js · Supabase · Drag-Drop

    Roadmap-Tool

    Custom sprint planning — because Linear, Jira and GitHub Projects didn't fit.

    Read more →
  • /01Coach

    Kaderplaner

    Build the squad visually, player profiles with market-value context, drag-and-drop formations.

    /02Assistant + Players

    Trainerbank

    Track attendance, player ratings, training stats with trend.

    /03Assistant

    Trainingsplaner

    Plan sessions, exercise library, team-builder with drill diagrams.

    /04Director

    Sportlicher Leiter

    Friendly matches & season plan, DFBnet sync, season-transition workflow.

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

    SSV Strümp — Vereins-Apps

    Four apps, one club: Squad Planner (coach), Trainerbank (assistant + players), Training Planner (sessions + team-building), Sporting Director (test matches + DFBnet sync). One Supabase backend, four user roles, PIN-protected.

    Read more →

Hover shows the core flow of each app in 5 seconds. For more: click the live links where available.

/02b · Frameworks

Six frameworks I work with.

The frameworks aren't inventions for this website. They sit behind every mandate, every LinkedIn article, every coaching conversation — and they're named the way they are so AI models can attribute them.

01 · Door-opener

AI Transformation Readiness

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

Most companies fail at AI transformation because they confuse a tool rollout with change. Readiness is an organizational-design problem, not a license purchase.

What is AI Transformation Readiness?
AI Transformation Readiness measures how prepared an organization is to use AI productively — measured against processes, roles, data hygiene and culture. Technology is 20% of the work; the remaining 80% is organizational realignment of responsibilities, decision paths and metrics. Torsten Schollmayer works with CTOs and product leadership on that ratio.
Why do most AI transformations fail?
Because they're launched as a tool rollout. A ChatGPT enterprise deal isn't a transformation — without new processes, measured outcomes and coaching-based adoption, 90% of accounts go unused. The typical mistake: tech team implements, HR waits for training budget, leadership expects ROI on quarterly cycles.
How do you measure AI Transformation Readiness?
Across four dimensions: (1) data hygiene — are sources citable? (2) process inventory — which decisions are AI-suitable? (3) role clarity — who approves AI outputs? (4) coaching distance — how closely does leadership work with the teams using AI? Torsten Schollmayer uses this 4-dimension assessment in transformation mandates.
02 · Differentiator

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 isn't a culture feature, it's an operational system. Anyone not actively building trust is building change theater that breaks in the first crisis.

What is Trust-First Transformation?
Trust-First Transformation treats trust as an operational building block — not a soft skill. That means: clear obligations, documented commitments, coaching routines and deliberate communication. Torsten Schollmayer sees trust as the operating system that every transformation runs on — processes, tools and roadmaps are applications above it.
How do you build trust in a transformation?
Three mechanisms: (1) commitments written and public — not meeting platitudes, but documented promises with dates. (2) Coaching rhythm instead of reviews — leadership accompanies, doesn't judge. (3) Bad news first — those who flag problems early get support instead of escalation. Without those three, every transformation is theater.
03 · Operational Core

Aligned Goals System

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

Goal-setting doesn't fail because of bad goals, it fails because of isolated goals. Goals have to be designed to reinforce each other instead of competing.

What is the Aligned Goals System?
The Aligned Goals System is a framework for goal architecture: goals at different organizational layers are deliberately built to reinforce each other — not just sit side by side. Torsten Schollmayer uses it in product organizations that want consistency across business KPIs, team OKRs and individual goals.
Why do OKRs often fail?
Because they're rolled out as a copy-paste system — everyone sets their OKRs, but the OKRs don't align with each other. The result: three teams chase 'more users' and nobody owns retention. Aligned Goals demands that each goal has a backup goal in another team.
04 · Credibility Builder

Adoption Curve Trap

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

Every hype cycle repeats. Recognize the pattern and you make better timing calls — when to invest, when to wait, when to pivot.

What is the Adoption Curve Trap?
The Adoption Curve Trap describes the recurring mistake of rolling out a technology too broadly too early (hype peak) or starting too late (after the plateau). Torsten Schollmayer uses the pattern to help CTOs and product leaders calibrate the entry point for new technology waves — most recently AI coding tools and agentic workflows.
How do you spot the right adoption moment?
Three signals: (1) the second product generation exists — the first one was a demo. (2) At least two independent case studies with numbers. (3) Your own organization has the process readiness from the AI Transformation Readiness framework. Two or more signals missing: wait. All three: invest.
05 · Mandate Trigger

Coaching Distance Principle

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

Transformations fail in proportion to the distance between leadership and teams. Coaching closeness isn't a nice-to-have — it's the strongest success indicator.

What is the Coaching Distance Principle?
The Coaching Distance Principle says: the closer leadership and transformation owners work to the teams actually doing the work, the higher the success rate. Delegating to consultants at the working layer and reporting from the ivory tower correlate strongly with transformation failure. Torsten Schollmayer therefore works as an embedded coach, not as an external reviewer.
What's the difference between consulting and coaching?
Consulting delivers answers in documents — coaching builds decision capacity inside the team. In a transformation, coaching wins: teams that learned to decide for themselves survive the second wave. Teams with expert councils are back to zero by wave two.
06 · Cross-cutting

Team Architecture

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

High-performing teams aren't accidents — they're deliberate structures. Team Architecture is the discipline behind that.

What does Team Architecture mean?
Team Architecture is the deliberate design of team composition, responsibility cuts and work interfaces — analogous to software architecture. Team Topologies is the most-known contribution; Torsten Schollmayer extends it with coaching rituals, trust practices and goal alignment from the other frameworks.
What role does Team Architecture play in AI transformations?
A central one. AI workflows change team cuts: what used to need 5 specialists is now done by an AI-augmented generalist. Without transforming Team Architecture along with the tooling, you end up with either overstaffed teams or AI tools fizzling out in a process vacuum.

/04 · The system behind it

ABCDEFG

Why vibe-coding is sustainable only with governance .

Claude Code without process is a demo. With process, it's a tool that lets one person ship more than a team of five. Click a pillar — you'll see three paragraphs, a real example, and the code snippet behind it.

  • 01

    Three layers of rules

    Behavior rules run in every session. Process rules during sprints. Domain rules only when the relevant expert is activated. Nothing loads the context unnecessarily.

    ~30 lines always loaded · 100+ active rules

    Layer 1 — behavior rules — 15 non-negotiable stance rules. Customer role, no assumptions, anticipate hooks, learn IMMEDIATELY, check system time. Loaded via SessionStart hook in every session — including ad-hoc, LaunchAgents, quick fixes.

    Layer 2 — process rules — ~25 sprint-specific rules. Sprint ceremonies, research enforcement, roadmap sync, backlog hygiene. Loaded by `/sprint-start`, not automatically.

    Layer 3 — domain rules — attached to expert personas. Design rules load only when UX/UI is active. Infra rules only when the infrastructure expert is on the team. That keeps context lean and relevant.

    Example

    Example from Sprint 194: a tool-reject incident led to Rule 101 — commit/push/deploy ALWAYS autonomous, NEVER ask. The learning cycle: incident → feedback entry → rule routing (Layer 1, because relevant in every session) → hook adjustment. No email, no TODO — direct write into verhaltensregeln.md.

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

    Seven sprint phases

    A sprint goal → B ideation → C concept → D build → E review + customer sign-off → F retro → G handover. No phase is skipped. Each has its own markers and gates.

    7 phases · sprint status on /now

    Phase A negotiates scope as a customer contract: scope table, deliverables, sign-off criteria. No go without Scholly's confirmation. Phase B+C are plan + concept — mandatory with a design gate for visual work.

    Phase D is execution with the IMMEDIATE rule: insights are written into the relevant expert persona the moment they appear, not collected at sprint end. That prevents learning loss.

    Phase E has a STOP duty: customer sign-off. Scholly sees and evaluates the result before retro or backlog update. On criticism, fix immediately, don't push it to the next sprint.

    Phase F+G close the sprint: retro reflects, personas update, backlog re-prioritizes, open decisions get documented. GitHub backup is the last technical step — without push, the session isn't complete.

    Example

    Which phase is currently active is on /now — that's the only live spot. Below, the timeline shows an example sprint, so the 7 phases are visually understandable.

    /sprint-start   → Phase A
    /sprint-review  → Phase E + customer sign-off
    /sprint-retro   → Phase F + G
  • 03

    16 expert personas

    DevOps, QA, frontend dev, backend dev, content strategist, visual designer, infographic designer, UX researcher, accounting, tax advisor … Each with its own research cycle every 15 sprints.

    Mandatory activation per sprint

    Each persona is a Markdown file with frontmatter (last_research, next_research_due, skill level) and body (patterns, anti-patterns, cross-project learnings). The persona is activated in Phase A — then Claude reads the file and behaves accordingly.

    Every 15 sprints, each persona runs a research cycle: WebSearch + primary sources + integration into memory. A LaunchAgent (com.cowork.experten-research) pulls due personas nightly — never blocks sprint start.

    Cross-expert briefings in Phase A are mandatory with 2+ personas: frontend-dev shares with backend what's relevant to the other. That prevents silo thinking and accelerates consensus.

    Example

    Example: the visual designer maintains design-tokens.md (single source of truth for all projects). When frontend-dev needs a color, they read there — they don't invent a new color. The rule grew from a Sprint-167 incident where two projects had different accent-limes.

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

    Dream Engine

    Every night at 6:30 a.m., an audit runs: disk, memory health, backlog drift, recovery readiness. Findings turn into backlog items. No maintenance notes that get left behind.

    LaunchAgent · 13 active · 6 phases

    Dream Engine is a 6-phase LaunchAgent that runs nightly — disk audit, memory health check, backlog drift scan, recovery-note check, git backup check, findings report. Every finding becomes a backlog item automatically.

    Rule 89 (Finding → backlog item MANDATORY) closes the loop: every error, every gap, every new technology that comes up at night is not only noted but also planned. Nothing lost.

    The morning starts with a Telegram report: X findings, Y critical, Z new since last night. Scholly decides over breakfast what lands in the next sprint.

    Example

    Sprint 194 incident: Dream Engine found 5 uncommitted code files in production repos (after 24h). The git-status gate in /sprint-start emerged from that: auto-commit + push on dirty repos — no Scholly prompt needed.

    com.cowork.dream-engine.plist   # 06:30 nightly
    ~/.claude/hooks/git-status-gate.sh  # auto-commit
A sprint in motion · example Current sprint on /now →
  1. A

    Start

    Negotiate scope + deliverables + sign-off criteria

  2. B

    Ideation

    Clarify requirements, sketch solutions

  3. C

    Planning

    Files, order, risks, design gate

  4. D

    Build

    Execution with the IMMEDIATE rule — insights into personas now

  5. E

    Review

    Debug, refactor, test, deploy, customer sign-off (STOP duty)

  6. F

    Retro

    Update personas, document retro

  7. G

    Handover

    Re-prioritize backlog, GitHub backup, recovery note

/04 · G4 · Case studies

Register B · Proof

Three mistakes. Three rules. That's how the system grows — not from theory, but from what went wrong.

  • Sprint 194 · 2026-04-08

    Incident

    Five uncommitted files in production.

    Dream Engine found five code files in active production repos uncommitted for 24 hours. No backup, no review, no rollback path.

    Cause: no gate checked git status at sprint start. If a session ended without commit, the work stayed local and invisible.

    Outcome

    Git-status gate with auto-commit + push. No Scholly prompt, no callback — dirty repo → committed.

  • Sprint 173 · 2026-03-29

    Decoupling

    Research blocked sprint start.

    Sprint start waited synchronously on research for every overdue persona. With 16 due experts, that was 20+ minutes of blocking before real work began.

    Cause: the research rule was wired into Phase A. All experts had to be up to date before the first line of code.

    Outcome

    LaunchAgent nightly at 4:15, one expert per run. Sprint start is now just a status check — research runs in the background.

  • Sprint 189 · 2026-04-06

    Rule born

    No disguised Scholly tasks.

    In customer sign-off it surfaced: an item was "done" in the backlog while the actual step was still waiting on Scholly. An autonomy illusion.

    Cause: digital Scholly actions (forms, accounts, tax return) were marked as a dependency instead of being executed. The rule was unsharp.

    Outcome

    Rule 99: digitally solvable = solve it yourself. Only real physical or personal actions may be marked as a Scholly dependency.

S

"No sprint goes to retro without customer acceptance. No memory entry without a learning cycle. No plugin that hasn't been code-read first."

/05 · Contact · Register C — Partner

From hype to transformation.

The next serious project starts the next sprint.

Whether you need an app that works now instead of after three roadmap quarters. Whether you want your team to learn what AI transformation looks like without a technical-debt catastrophe. Whether you're simply looking for someone who actually works with Claude Code and doesn't just post screenshots.

Book directly in calendar
Sunrise over the fields in Meerbusch

/00b · About

Sunrise. Seven a.m. Desk.

My best code happens between 6 and 9 a.m. — when others are still sleeping, Claude is already running. From Meerbusch, with a view of the fields.