01 Kontext & Problem
Die zentrale Nutzerperson, eine erfolgreiche Fachkraft, ist spirituell hungrig, aber blockiert: generische westliche Apps haben keine Tiefe, Instagram-Heilern kann man nicht vertrauen, und die echten Lehrer sind aus einem anderen Land nicht erreichbar. Die gesamte Kategorie scheitert an einer Frage: Ist diese Person seriös, und ist das sicher? Die Einschränkung ist nicht das Geld, sondern das Vertrauen.
02 Rolle & Rahmenbedingungen
Als AI Product Manager verantwortete ich den gesamten Produkt- und Engineering-Aufbau: die Oberflächen für Nutzer, Praktizierende und Admins. Der Gründer verantwortet die Qualität der Praxis, das Verifizierungsurteil und die Marke. Rahmenbedingungen: ein schlankes Team, das die gesamte Oberfläche eines Marktplatzes abdeckt, ein zweiseitiger Cold-Start, der sich auf beiden Seiten vertrauenswürdig anfühlen muss, und ein Leitprinzip aus der Spezifikation: Sicherheit ist Produkt, nicht eine Compliance-Schicht.
03 Produktansatz
Verifizierung ist das Rückgrat. Eine praktizierende Person kann sich nicht listen lassen, ohne eine vierstufige Prüfung zu bestehen (schriftliche Bewerbung, Video-Vorstellung, eine vollständige Demo-Sitzung, bewertet anhand eines Rasters mit acht Dimensionen, und ein Probefenster über zwanzig Sitzungen), für eine angestrebte Annahmequote von unter 10%. Darum herum liegt ein vollständiger Sitzungs-Lebenszyklus und ein Beziehungsmodell: Nach der ersten Sitzung hat eine nutzende Person eine primäre praktizierende Person, sodass das Produkt auf Kontinuität statt auf einmaligen Buchungen aufbaut.
Vertrauen ist der Hebel: mit Verifizierung vorangehen, so wie Fintechs mit Sicherheit vorangehen. Es ist zudem übertragbar: Die Vertrauensschicht ist marktunabhängig, sodass globale Expansion Go-to-Market bedeutet und keinen Neuaufbau.
04 Umgesetzte Features
Vierstufige Verifizierung
Schriftlich → Video → bewertete Demo → 20-Sitzungen-Probephase. Der Burggraben.
Profile der Praktizierenden
Verifiziert-Badge, Stufe, Lineage, Intro-Video, Bewertungen, Verfügbarkeit.
Onboarding der Praktizierenden
Bewerbung plus eine 7-Schritte-Checkliste, freigeschaltet vor der ersten Sitzung.
Praktizierenden-Dashboard + CRM
Heute / Termine / Klienten / Business, mit privaten Notizen pro Klient.
Nutzerkonten + Journey
Dashboard, reflektierende Journey-Oberfläche, Profil und Einstellungen.
Suche & Filterung
Nach Modalität, Sprache, Stufe, Verfügbarkeit, Preis und Bewertung.
Buchungsablauf
Maximal drei Screens: Slot → Konto → Zahlung, keine Überraschungen.
Stripe-Connect-Zahlungen
Multi-Währungs-Checkout und wöchentliche automatisierte Auszahlungen an Praktizierende.
Eingebettetes Video (Daily.co)
Live-Sitzungen in der App, keine Zoom-Links, volle Kontrolle über die Sitzung.
Bewertungen & Rezensionen
Opt-in, admin-moderiert, fließen in den Stufenaufstieg der Praktizierenden ein.
Trust & Safety
Erkennung von Krisen-Keywords mit gestaffelter Reaktion und länderspezifischen Ressourcen.
Admin / Super-Admin
Sechs Bereiche: Dashboard, Nutzer, Praktizierende, Sitzungen, Content, Finanzen.
Ebenfalls ausgeliefert: begrenztes Messaging (Intake + ein Austausch nach der Sitzung), Zwei-Wege-Synchronisierung mit Google Calendar, Pakete, Geschenk-Sitzungen, Empfehlungen sowie die Content- und Praxis-Bibliothek.
05 Architektur
Next.js (App Router) auf Vercel; Supabase für Postgres + Auth mit Row-Level Security, die die Rollen von Nutzern, Praktizierenden und Admins trennt. Stripe Connect wickelt die Marktplatz-Zahlungen und wöchentlichen Multi-Währungs-Auszahlungen ab; Daily.co treibt das eingebettete Video an; die Zwei-Wege-Synchronisierung mit Google Calendar steuert die Verfügbarkeit der Praktizierenden.
06 Analytics & Observability
Vom ersten Tag an instrumentiert, sodass jeder Funnel, jeder Drop-off und jeder Fehler sichtbar ist, und sodass das Datenfundament, auf das die KI-Ebene weiter unten angewiesen ist, tatsächlich existiert. Vier Tools, bewusst ohne Überschneidungen:
PostHog
Product Analytics: Funnels, Event-Tracking und Session-Replay über die Intro→Bezahlt- und Retention-Journeys hinweg.
Sentry
Fehler- und Performance-Monitoring: fängt Abstürze und langsame Pfade im Checkout und im Live-Video ab.
Google Analytics
Akquise-Analytics: Traffic-Quellen, Landing-Page-Conversion und Kanal-CAC.
Hotjar
Heatmaps und Aufzeichnungen: zeigen, wo Nutzer bei Profilen und beim Checkout zögern.
07 KI-Entscheidungsebene
Auf dem oben beschriebenen Analytics-Stack läuft auf der Plattform eine gestaffelte Provisions-Engine (30% → 25% → 20%, je mehr Sitzungen Praktizierende liefern) sowie marktspezifisches Pricing. Dieses Datenfundament treibt die KI-Entscheidungsebene an.
Claude ist als Entscheidungs-Copilot in das Super-Admin integriert und liest die PostHog- und Analytics-Daten: Es empfiehlt und automatisiert dann Anpassungen von Provisionen und Gebühren, um die Marge zu schützen, reagiert auf Analytics-Events (Abwanderungsrisiko, Angebotslücken über Zeitzonen hinweg, nachlassende Qualität von Praktizierenden) und macht auf gewinnoptimierende Schritte aufmerksam, die einem menschlichen Admin entgehen würden. Die Reihenfolge war der springende Punkt: Das Analytics-Substrat kam zuerst, und die KI entscheidet darauf aufbauend.
08 Status & Ergebnis
Vollständige dreiseitige Plattform, gebaut über Web und Mobile hinweg; der Launch wurde angebotsseitig zuerst getaktet, mit einer Yoga-Day-Kampagne als Anker für die frühe Nachfrage.
50
Verifizierte Praktizierende
1,200
Zahlende Nutzer
32%
Intro → Bezahlt-Conversion
70%
Erste → zweite Sitzung Retention
09 Reflexion / Wie es weitergeht
Das Fundament aus Verifizierung, Analytics und Admin vor jeglicher KI zu bauen, war eine bewusste Entscheidung: Ein System, das echtes Geld anpasst, ist nur so vertrauenswürdig wie die Daten und der Prüfprozess darunter. Die Plattform läuft erfolgreich mit dem live geschalteten KI-Entscheidungs-Copiloten, und dieselbe übertragbare Vertrauensschicht skaliert das Modell Markt für Markt.