Substack · sh0ly
All →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.
-
01/03Step 01 · of3
Paste reel URL
Read more →Live Next.js · Claude Vision · Gemini ● 8 open · 0 doneCookmark
Recipes from Instagram reels as structured cooking cards — with one click.
-
01/03Step 01 · of3
Enter job description
Read more →Beta Next.js · Claude Agents ● 51 open · 0 doneKiHire
Agentic sourcing for small companies — jobs, candidates, matches.
-
01/03Step 01 · of3
8 titles on the list
Read more →Live PWA · TMDb-API · Cloudflare Workers ● 7 open · 0 doneWatchlist
Streaming PWA with filter stack: what to watch tonight, without 20 minutes of scrolling.
-
φ PhysioGPTNeurologieTherapeut
Patient nach Schlaganfall, 6 Wochen post-akut. Gangschulung?
PhysioGPT
Bobath → PNF-Diagonalmuster → Laufband mit Entlastung.
QuelleBobath-Leitlinie · S2e · 2024, S. 47Read more →Beta Claude · RAG · Supabase ● 10 open · 0 donePhysioGPT
AI assistance for neurological physiotherapy. Practice pilot.
-
GesundheitswochenWoche 2 von 450 %MoDiMiDoFrSaSoHeute · Rückenwoche Tag 4
20 Min Mobilisation · 14:00 Gruppencall
Read more →Beta Next.js · PayPal ● 20 open · 0 doneGesundheitswochen-App
Client project in the health space. Pre-launch.
- ClaudeDateiAnsicht0_0◆87%🔋10:42ClaudeBar3 Sessionsschollmayer.info87%roadmap-tool42%ghostwriting23%macOS · MenubarSigniert · DMG-InstallerRead more →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.
- /01Coach
Kaderplaner
Build the squad visually, player profiles with market-value context, drag-and-drop formations.
/02Assistant + PlayersTrainerbank
Track attendance, player ratings, training stats with trend.
/03AssistantTrainingsplaner
Plan sessions, exercise library, team-builder with drill diagrams.
/04DirectorSportlicher Leiter
Friendly matches & season plan, DFBnet sync, season-transition workflow.
Read more →Live Next.js · Supabase · PWA · DFBnet ● 80 open · 0 doneSSV 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.
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.
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-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.
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.
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.
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.
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
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 rulesLayer 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 /nowPhase 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 sprintEach 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 phasesDream 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
Start
Negotiate scope + deliverables + sign-off criteria
- B
Ideation
Clarify requirements, sketch solutions
- C
Planning
Files, order, risks, design gate
- D
Build
Execution with the IMMEDIATE rule — insights into personas now
- E
Review
Debug, refactor, test, deploy, customer sign-off (STOP duty)
- F
Retro
Update personas, document retro
- 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.
"No sprint goes to retro without customer acceptance. No memory entry without a learning cycle. No plugin that hasn't been code-read first."
/04.5 · Where I publish openly
Substack for long-form. GitHub for the apps.
Substack is my newsletter — one essay per week, ~2,000 words, in German or English depending on the topic. GitHub shows the commits from the apps below — what was actually built this week.
GitHub · escholly-ship-it
Profile →-
chore(smi-analytics): run 2026-05-04T06:31:44Z
schollmayer-info · 2e28aeb · May 04, 2026
-
sprint-261: Loesch-Plan Phase 1 — 5 obsolete GHA-Workflows entfernt
cowork · 3a72f64 · May 04, 2026
-
sprint-261: PushNotification-Migration in 3 Sprint-Skills + Use-Case-Mapping
claude-config · a86abb0 · May 04, 2026
As of May 04, 2026 · build-time aggregated
/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.
/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.





