Fallstudie
White-Label Coaching & Journey Platform
Architektur- und interaktive Produktfallstudie — Implementierung in Arbeit.
Status & Reifegrad
- Architektur-Freeze erreicht
- Build-Phase aktiv
- Kein Produktivsystem
Ausgangsidee
Eine Coach- oder Studio-Marke möchte strukturierte Programme, personalisierte Schritte und Reflexionen unter eigener Marke liefern. Die erste Idee lautete: „eine eigene Coaching-App."
Marktkorrektur
Bestehende Plattformen decken generische Kurse, Mitgliederbereiche, Community und Branding bereits ab. Die Frage verschob sich: Welche Abläufe brauchen wirklich eigene Produktlogik?
- Generische Kurse & Mitgliederbereiche — durch bestehende Plattformen abgedeckt
- Community & Branding — durch bestehende Plattformen abgedeckt
- Strukturierte Journeys mit Coach-Logik — Kandidat für eigenes Produkt
- White-Label-Mandantenisolation — erfordert explizite Architektur (nicht als live angenommen)
Rollenmodell
Vier Rollen mit unterschiedlichen Verantwortlichkeiten und Berechtigungsgrenzen.
-
Client
Konsumiert Journeys, erledigt Schritte, reflektiert
-
Coach
Weist Programme zu, prüft Fortschritt, kommuniziert
-
Mandanten-Admin
Brand-Konfiguration, User-Provisioning, Content-Scope
-
Platform Ops
Mandantenübergreifende Operationen (nur Spezifikation)
Golden Journey
End-to-End-Flow vom Blueprint bis zum Coach-Update — Spezifikation, kein Live-Betrieb.
-
Blueprint
Programmstruktur definiert
-
Journey
Client wird Pfad zugewiesen
-
Safety
Grenzen & Einwilligung geprüft
-
Provision
Mandantenspezifischer Zugang (Spec)
-
Step
Client erledigt Einheit
-
Reflect
Journal-Eintrag erfasst
-
Coach-Update
Coach benachrichtigt & antwortet
Anforderungsergebnis
Kuratierte öffentliche Auszüge — nicht das vollständige private Dokumentationspaket.
- Capability Map mit rollenbasierten Berechtigungen
- Zustandsmodell für Journey-, Schritt- und Reflexions-Lebenszyklus
- NFRs: Datentrennung, Audit-Trail (Spezifikation)
- Akzeptanzkriterien für Golden-Journey-Szenarien
- Nachvollziehbarkeit: Anforderung → Testszenario → Abnahme-Gate
Architektur & Daten-Grenzen
Zielarchitektur (Spezifikation)
Client-, Coach- und Mandanten-Oberflächen; Java/Spring-Ziel-Backend; Next.js-Ziel-Frontend; PostgreSQL/Supabase-Ziel-Persistenz. Trennung von Laufzeit, Shared Core und Canonical Knowledge. Deployment und Laufzeitbetrieb sind nicht nachgewiesen.
Interaktiver Prototyp
Produktprototyp zur Demonstration — keine Produktionssoftware.
KI-unterstützte Methode
KI unterstützte Quellenkonsolidierung, Alternativen und Konsistenzprüfungen. Produktentscheidungen, Claim-Grenzen, Architektur-Verantwortung und Freigaben blieben beim Menschen.
-
Aufnahme & Scope
Mensch definiert Mandat und Grenzen
-
Recherche
KI-unterstützte Quellenkonsolidierung
-
Strukturierung
Alternativen und Capability Map
-
Konsistenzprüfung
KI markiert Lücken; Mensch entscheidet
Was existiert / was nicht
Existiert (öffentlich belegbar)
- Entwicklungs-Blueprint mit Nachvollziehbarkeit
- Interaktiver Produkt-Prototyp (keine Produktionssoftware)
- Anforderungs- und Akzeptanzartefakte (kuratierte Auszüge)
Existiert nicht (Stand heute)
- Live-SaaS mit Mandantenisolation im Betrieb
- Aktive n8n-Workflows in Produktion
- Abgeschlossene Nutzer-Validierung / Product-Market-Fit
- ISO-Zertifizierung oder formale Compliance-Bestätigung
- Durchgeführte Testläufe aller spezifizierten Testfälle
Erkenntnisse
Die Arbeit lieferte einen nachvollziehbaren Blueprint und korrigierte eine frühe Annahme: Generische Brand-Apps sind bereits günstig verfügbar. Der nächste rationale Schritt ist Nutzer-Validierung — nicht breitere Implementierung ohne Evidenz.
Projekt oder Anforderung besprechen
Kontakt aufnehmen- Antwort in 24h
- Unverbindlich
- Direkt mit dem Team