Add go-live and go-to-market roadmaps

2026-06-15 17:52:08 +02:00
parent f1cc15a1f3
commit e4fa714419
4 changed files with 768 additions and 0 deletions
@@ -46,6 +46,9 @@ Organisation, waehrend Produktlogik, Betrieb und Vermarktung zentral bleiben.
 - [database/schema.sql](/config/workspace/kaffeeliste-neustart/database/schema.sql)
 - [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md)
 - [RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md)
 - [docs/go-live-checklist-netcup.md](/config/workspace/kaffeeliste-neustart/docs/go-live-checklist-netcup.md)
 - [docs/go-to-market-30-60-90.md](/config/workspace/kaffeeliste-neustart/docs/go-to-market-30-60-90.md)
 - [docs/next-steps-roadmap.md](/config/workspace/kaffeeliste-neustart/docs/next-steps-roadmap.md)
 - [docs/product-strategy.md](/config/workspace/kaffeeliste-neustart/docs/product-strategy.md)
 - [docs/marketing-ops.md](/config/workspace/kaffeeliste-neustart/docs/marketing-ops.md)
 - [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md)
@@ -0,0 +1,222 @@
 # Go-Live-Checkliste fuer Netcup Webspace
 Diese Checkliste ist fuer den ersten echten Betrieb auf Netcup Webspace gedacht.
 Sie baut auf [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md),
 [RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md) und
 [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md)
 auf, ist aber absichtlich strenger und operativer.
 ## 1. Go-Live-Scope festziehen
 - [ ] Entscheiden, ob der erste Livegang ein geschlossener Pilot oder ein oeffentliches SaaS-Launch ist.
 - [ ] Fuer einen oeffentlichen Launch Registrierung absichern oder vorerst deaktivieren.
  Das Repo nennt Mail-Verifikation, Passwort-Reset und Rate-Limits selbst als offene Punkte vor echtem Go-Live.
 - [ ] Falls diese Punkte noch fehlen: nur mit eingeladenen Testkunden oder manuell freigeschalteten Mandanten live gehen.
 - [ ] Einen Release-Owner und einen Restore-Owner benennen.
 - [ ] Ein Wartungsfenster fuer den Erststart und fuer kuenftige Releases definieren.
 ## 2. Environment-Modell festlegen
 Empfehlung fuer Netcup Webspace:
 - [ ] `local`: Entwicklung lokal.
 - [ ] `staging`: echte Netcup-Subdomain wie `staging.example.tld`, eigene DB, eigene `.env`.
 - [ ] `production`: produktive Domain, eigene DB, eigene `.env`.
 Pragmatisches Verzeichnislayout ohne Root-Zwang:
 - [ ] `staging` unter `/apps/kaffeekasse-stage/current`
 - [ ] `production` unter `/apps/kaffeekasse/current`
 - [ ] Offsite- oder Backup-Artefakte nicht im Webroot ablegen.
 Wichtig fuer dieses Repo:
 - [ ] `public/` bleibt der einzige Webroot.
 - [ ] `.env` wird aus dem Projektwurzelverzeichnis geladen.
 - [ ] Der Browser-Installer schreibt `.env` in das Projektwurzelverzeichnis und `storage/installed.lock` in `storage/`.
 - [ ] `bin/cron.php` schreibt `storage/cron.lock`.
 - [ ] Deshalb muessen Projektwurzel und `storage/` mindestens fuer den Deployment-User, besser auch fuer den Webspace-User, sauber beschreibbar sein.
 ## 3. Netcup vorbereiten
 - [ ] Domain oder Subdomain im CCP/WCP anlegen.
 - [ ] DNS frueh setzen und Aufloesung pruefen.
 - [ ] In Plesk/WCP pro Environment eine eigene Site mit eigenem Document Root anlegen.
 - [ ] Document Root fuer jedes Environment auf `.../current/public` setzen.
 - [ ] Pro Environment eine eigene MySQL-Datenbank und einen eigenen DB-User anlegen.
 - [ ] PHP-Version im WCP fest auf 8.3 oder 8.4 pinnen und nicht auf "System Default" lassen.
 - [ ] Dieselbe PHP-Hauptversion fuer Web und CLI verwenden.
 ## 4. Secrets und Konfiguration vorbereiten
 Pflichtwerte laut App:
 - [ ] `APP_URL`
 - [ ] `APP_ENV`
 - [ ] `APP_DEBUG=0`
 - [ ] `APP_TIMEZONE`
 - [ ] `APP_KEY`
 - [ ] `DB_HOST`
 - [ ] `DB_PORT`
 - [ ] `DB_NAME`
 - [ ] `DB_USER`
 - [ ] `DB_PASS`
 - [ ] `RFID_SHARED_SECRET`
 Empfehlung:
 - [ ] `staging` und `production` nie dieselben Secrets oder dieselbe DB teilen.
 - [ ] Admin-Zugang fuer die Plattform separat dokumentieren und im Passwortsafe ablegen.
 - [ ] Wenn der Browser-Installer verwendet wird: danach `.env` sichern und offsite ablegen.
 - [ ] Wenn `.env` manuell gepflegt wird: `.env` vor dem ersten Deploy lokal erzeugen und erst dann hochladen.
 ## 5. Erstes Staging-Deployment
 - [ ] Lokal oder in CI `scripts/build-release.sh` ausfuehren.
 - [ ] Release-Artefakt sicher ablegen. Es ist Teil des Rollback-Pfads.
 - [ ] Artefakt per FTPES oder SFTP nach Netcup hochladen.
 - [ ] Paket in den festen Environment-Pfad entpacken.
 - [ ] Pruefen, dass `.env`, `storage/uploads`, `storage/logs` und `storage/cache` nicht versehentlich ueberschrieben oder geloescht wurden.
  Das Build-Skript schliesst diese Pfade aus dem Release aus.
 - [ ] Falls der Browser-Installer genutzt wird: `/install` nur auf `staging` einmal durchlaufen.
 - [ ] Falls manuell installiert wird: `.env` hochladen und danach
  `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/migrate.php`
  oder die zu eurer PHP-Version passende Binary ausfuehren.
 - [ ] Pruefen, dass `storage/installed.lock` angelegt wurde.
 ## 6. Staging-Smoketest vor Production
 - [ ] Startseite laden.
 - [ ] `/admin/login` erfolgreich testen.
 - [ ] Einen Test-Mandanten anlegen.
 - [ ] Tenant-Login pruefen.
 - [ ] Eine Testbuchung und eine Test-Einzahlung anlegen.
 - [ ] `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/healthcheck.php` ausfuehren und JSON pruefen.
 - [ ] `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/cron.php` manuell ausfuehren.
 - [ ] Pruefen, dass `cron.lock` nach dem Lauf wieder verschwindet.
 ## 7. SSL und HTTPS
 - [ ] Erst SSL ausrollen, wenn DNS sauber auf Netcup zeigt.
 - [ ] Im WCP fuer jede produktive Domain ein Let's-Encrypt-Zertifikat ausstellen.
 - [ ] `www` nur dann mit absichern, wenn `www` auch wirklich genutzt werden soll.
 - [ ] Fuer den ersten Go-Live kein Wildcard-Zertifikat verwenden, wenn es nicht zwingend noetig ist.
  Bei Netcup werden Wildcard-Zertifikate nicht automatisch erneuert.
 - [ ] HTTPS fuer die produktive Domain erzwingen.
 - [ ] Nach Aktivierung pruefen, dass alle Logins und Formulare nur noch ueber HTTPS laufen.
 - [ ] Session-Cookies unter HTTPS pruefen, weil `secure` in der App vom HTTPS-Kontext abhaengt.
 ## 8. Backup-Strategie produktionsreif machen
 Minimum:
 - [ ] Taegliches DB-Backup einrichten.
 - [ ] Vor jedem Release ein frisches manuelles DB-Backup ziehen.
 - [ ] `.env` offsite sichern.
 - [ ] `storage/uploads` offsite sichern.
 - [ ] Letztes stabiles Release-Artefakt offsite sichern.
 Netcup-spezifisch:
 - [ ] Falls euer Tarif den Backup Manager anbietet: wiederkehrendes Backup in WCP aktivieren.
 - [ ] Backups regelmaessig herunterladen oder an einen zweiten Ort kopieren.
 - [ ] Backup Manager nicht als einzigen Disaster-Recovery-Pfad betrachten.
  Netcup dokumentiert, dass diese Backups nur auf demselben Hosting wiederhergestellt werden sollen.
 ## 9. Cron sauber einrichten
 - [ ] In WCP eine geplante Aufgabe fuer `bin/cron.php` alle 5 Minuten anlegen.
 - [ ] Dieselbe PHP-Version verwenden wie fuer die Website.
 - [ ] Den Task vor dem Speichern mit "Run Now" testen.
 - [ ] Wenn WCP auf eurem Tarif mit chroot oder relativen Pfaden zickt: den final funktionierenden Befehl direkt dokumentieren.
 - [ ] Eine zweite geplante Aufgabe fuer `bin/healthcheck.php` einrichten, mindestens stuendlich oder taeglich.
 - [ ] Task-Ausgaben in eine Mail oder Logdatei laufen lassen, statt sie still zu verwerfen.
 Wichtige Einschraenkung dieses Repos:
 - [ ] `bin/healthcheck.php` liefert JSON, setzt aber bei DB-Problemen derzeit keinen expliziten Exit-Code ungleich 0.
 - [ ] Fuer Alarmierung deshalb nicht nur auf "Errors only" bei Scheduled Tasks vertrauen.
 - [ ] Zusaetzlich einen externen HTTPS-Uptime-Check auf Startseite oder Login-Seite einrichten.
 ## 10. Monitoring-Minimum fuer den Start
 - [ ] Externes Uptime-Monitoring auf die produktive HTTPS-URL aktivieren.
 - [ ] Plesk-/PHP-Error-Logs in die Regelbetriebsroutine aufnehmen.
 - [ ] Nach dem Go-Live taeglich Audit-Ereignisse fuer fehlgeschlagene Logins und Access-Denied pruefen.
 - [ ] Wachstum der Tabellen `consumption_events`, `ledger_entries` und `audit_events` beobachten.
 - [ ] Offene RFID-Ereignisse aus dem Cron-Output beobachten, falls RFID pilotiert wird.
 - [ ] Einen klaren Empfaenger fuer Alarmmails hinterlegen.
 ## 11. Release-Prozess fuer echte Produktion festlegen
 Empfohlener erster Produktionsprozess auf Netcup Webspace:
 - [ ] Aenderungen auf `staging` komplett durchtesten.
 - [ ] Release-Artefakt mit Zeitstempel bauen.
 - [ ] Direkt vor dem Produktionsdeploy DB-Backup erstellen.
 - [ ] `.env` und persistente `storage/`-Inhalte zusatzlich sichern.
 - [ ] Release nach `production` hochladen.
 - [ ] `bin/migrate.php` ausfuehren.
 - [ ] `bin/healthcheck.php` ausfuehren.
 - [ ] Admin-Login, Tenant-Login und Testbuchung sofort pruefen.
 - [ ] Den naechsten automatischen Cron-Lauf beobachten.
 - [ ] Erst danach das Release als "stabil" markieren.
 Wichtige Einschraenkung dieses Repos:
 - [ ] `bin/migrate.php` spielt nur `database/schema.sql` erneut ein.
 - [ ] Das aktuelle `schema.sql` arbeitet mit `CREATE TABLE IF NOT EXISTS` und ist damit fuer Erstinstallation geeignet, aber kein vollwertiges inkrementelles Migrationssystem.
 - [ ] Vor dem ersten Release mit DB-Schema-Aenderungen eine klare Migrationskonvention festlegen, zum Beispiel versionierte SQL-Dateien plus Runbook-Schritt.
 ## 12. Fallback und Restore vorher ueben
 Rollback fuer einen fehlgeschlagenen Release:
 - [ ] Letztes stabiles Release-Artefakt erneut deployen.
 - [ ] Wenn noetig DB-Backup vom Start des Releases einspielen.
 - [ ] `.env` und `storage/uploads` wiederherstellen.
 - [ ] `bin/healthcheck.php` ausfuehren.
 - [ ] Admin-Login, Tenant-Login und Testbuchung pruefen.
 Restore fuer echten Ausfall:
 - [ ] Zielreihenfolge dokumentieren: Code, `.env`, Uploads, DB, Healthcheck, Smoke-Test.
 - [ ] Restore nicht nur theoretisch planen, sondern einmal auf `staging` ueben.
 - [ ] Ziel-RTO und Ziel-RPO festlegen, auch wenn sie anfangs noch pragmatisch sind.
 - [ ] Ansprechpartner und Zugangsdaten fuer Restore ausserhalb des Repos dokumentieren.
 ## 13. Finale Go-Live-Freigabe
 Nur live schalten, wenn alles abgehakt ist:
 - [ ] Production-Domain zeigt auf Netcup und loest korrekt auf.
 - [ ] SSL ist gueltig und HTTPS wird erzwungen.
 - [ ] `public/` ist einziger Webroot.
 - [ ] `.env`, Backups, Dumps und `.git` sind nicht oeffentlich erreichbar.
 - [ ] DB-Backup von heute existiert.
 - [ ] Cron laeuft erfolgreich.
 - [ ] Externes Monitoring prueft die Seite.
 - [ ] Admin-Login und ein Test-Tenant funktionieren.
 - [ ] Restore wurde mindestens einmal auf `staging` geprobt.
 - [ ] Es gibt eine bewusste Entscheidung, ob offene Registrierung bereits verantwortbar ist.
 ## Quellen
 - Repo-intern:
  [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md),
  [RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md),
  [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md),
  [app/bootstrap.php](/config/workspace/kaffeeliste-neustart/app/bootstrap.php),
  [config/app.php](/config/workspace/kaffeeliste-neustart/config/app.php),
  [app/Services/SetupService.php](/config/workspace/kaffeeliste-neustart/app/Services/SetupService.php),
  [bin/migrate.php](/config/workspace/kaffeeliste-neustart/bin/migrate.php),
  [bin/cron.php](/config/workspace/kaffeeliste-neustart/bin/cron.php),
  [bin/healthcheck.php](/config/workspace/kaffeeliste-neustart/bin/healthcheck.php),
  [scripts/build-release.sh](/config/workspace/kaffeeliste-neustart/scripts/build-release.sh)
 - Offizielle Doku:
  https://www.netcup.com/en/helpcenter/documentation/web-hosting/php-shell
  https://www.netcup.com/en/helpcenter/documentation/web-hosting/scheduled-tasks
  https://www.netcup.com/en/helpcenter/documentation/web-hosting/enabling-ssl-tls
  https://www.netcup.com/en/helpcenter/documentation/web-hosting/backup-manager
  https://docs.plesk.com/en-US/obsidian/customer-guide/scheduling-tasks.65207/
  https://www.plesk.com/kb/docs/managing-web-hosting-changing-the-document-root-directory/
@@ -0,0 +1,394 @@
 # Go-to-Market 30-60-90 Tage
 Stand: 2026-06-15
 ## Kurzfazit
 Die naechsten 90 Tage sollten nicht mit breitem Marketing, sondern mit einem
 scharfen Beachhead beginnen:
 - Primaere Zielgruppe: Teams, Vereine und kleine Community-Standorte mit 10-50
  aktiven Nutzern, die heute Papier, Excel oder lose Strichlisten verwenden.
 - Sekundaere Zielgruppe: Coworking-Standorte nur als sales-assistierter Pilot,
  nicht als Hauptbotschaft auf der allgemeinen Startseite.
 - Kernversprechen: `Papier bleibt moeglich. Abrechnung wird sauber. RFID kommt,
  wenn es sich wirklich lohnt.`
 Das Ziel bis Tag 90 ist nicht Reichweite, sondern belastbares Marktfeedback:
 - 10+ Discovery-Gespraeche
 - 3-5 aktive Pilotkunden
 - 2 zahlungsbereite Referenzen oder Verlangerungen
 - ein belastbarer Preiskorridor
 - ein sauber messbarer Lead-zu-Aktivierungs-Funnel
 ## Repo-basierte Diagnose
 Das Produkt ist fuer fruehe Pilotkunden weiter als die Vermarktung.
 - Die Startseite erklaert das System technisch stark, aber den operativen Nutzen
  noch zu wenig. In [resources/views/home/index.php](../resources/views/home/index.php)
  stehen aktuell `PHP/MySQL`, `Netcup-Webspace` und `RFID-Roadmap` sehr weit
  vorne.
 - Die CTA-Struktur ist zu hart fuer Erstkontakt. Auf der Startseite gibt es
  aktuell primaer `Mandant starten`, aber keinen sichtbaren `Demo ansehen`,
  `Pilot anfragen` oder `Kontakt`.
 - Die Paketsektion nennt Pakete, aber keine oeffentlich validierte Preislogik,
  keine Mitgliedergrenzen und keine Testzusage.
 - Tracking ist in [docs/marketing-ops.md](./marketing-ops.md) sauber gedacht,
  aber im Produkt noch nicht sichtbar umgesetzt.
 - Gleichzeitig ist das Produkt onboardingfaehig:
  [app/Services/TenantRegistrationService.php](../app/Services/TenantRegistrationService.php)
  legt beim Signup bereits Owner, Standardprodukte, Quellen und Grundeinstellungen
  an. Das ist eine gute Basis fuer Demo, Trial und Pilot.
 ## Positionierung
 ### Empfehlung
 Nicht `Kaffeekasse fuer alle` vermarkten. Stattdessen ein klares Einstiegsproblem
 verkaufen:
 - `Wir ersetzen nicht eure Gewohnheit auf einen Schlag.`
 - `Wir machen aus Papier, Nachtrag und Selbstbedienung eine saubere Abrechnung.`
 - `Wenn ihr spaeter RFID wollt, muesst ihr nicht neu anfangen.`
 ### Empfohlene Marktansprache
 - Primaer: Vereinsvorstand, Getraenkewart, Office Manager, Team-Admin,
  Community Manager, die heute Fehler, Rueckfragen und fehlende Einzahlungen
  manuell klaeren.
 - Sekundaer: Coworking-Betreiber mit Community-Kueche oder Honesty Bar. Hier
  ist das Produkt eher eine schlanke Beverage-Operations-Loesung als eine
  komplette Coworking-Plattform.
 ### Messaging-Hierarchie
 - Hauptclaim: `Die Kaffeekasse fuer Teams und Vereine, die noch nicht ganz auf
  Papier verzichten wollen.`
 - Unterclaim: `Digitale Buchungen, Papier-Nacherfassung und spaeter RFID - alles
  in einer nachvollziehbaren Abrechnung.`
 - Beweis 1: `Mitglieder, Produkte, Einzahlungen und Salden in einem Ablauf`
 - Beweis 2: `Sofort startklar im Browser, Tablet oder Kiosk`
 - Beweis 3: `RFID nicht heute noetig, aber morgen anschliessbar`
 ### Was nicht in die Hero-Message gehoert
 - `PHP/MySQL`
 - `Netcup`
 - `mandantenfaehig`
 - `Ledger`
 Diese Begriffe sind sinnvoll fuer Betrieb, Doku und Technikvertrauen, aber nicht
 fuer den ersten Kaufimpuls.
 ## Demo-Setup
 ### Warum das jetzt Prioritaet hat
 Aktuelle Wettbewerber kombinieren sehr oft Demo oder Trial mit sehr einfacher
 Preislogik. Stand 2026-06-15:
 - Getraenkewart kommuniziert eine sofortige Demo und eine kostenlose kleine
  Einstiegsstufe.
 - Clubfridge stellt ein Testsystem und 30 Tage Gratis-Test in den Vordergrund.
 - Cobot kombiniert `Try it for free` und `Schedule a demo`.
 Die Lehre daraus: Frueher Markt will erst sehen, dann glauben, dann kaufen.
 ### Empfohlenes Demo-Setup
 - Ein `Team-Demo` mit 12 Mitgliedern, 4 Produkten, 30 Buchungen und 3
  Einzahlungen
 - Ein `Verein-Demo` mit Papierliste als Entwurf plus verbuchter Papierliste
 - Ein `Coworking-Demo` mit vorbereiteten RFID-Geraeten, Tags und Events, aber
  ohne die RFID-Roadmap als Hauptverkaufspunkt zu missbrauchen
 ### Empfohlene Demo-Artefakte
 - Oeffentliche Browser-Demo mit taeglichem oder stuendlichem Reset
 - 7-Minuten-Live-Demo-Skript
 - 90-Sekunden-Klickpfad fuer die Startseite:
  `Mitglied anlegen -> Buchung erfassen -> Einzahlung buchen -> Papierliste
  verbuchen`
 - Einseitiges Pilot-PDF:
  `Was wird in 14 Tagen gemeinsam getestet?`
 ### Demo-Story
 - Problem: `Striche fehlen, Spaetzahler fehlen, niemand will am Monatsende
  rechnen`
 - Heute: `Papier bleibt erlaubt`
 - Morgen: `Digitale Selbstbuchung spart Rueckfragen`
 - Spaeter: `RFID ist ein Upgrade, kein Neuanfang`
 ## Landingpage-Verbesserungen
 ### Sofort priorisieren
 - Hero von technischer auf operative Sprache drehen
 - Primaere CTA auf `Demo ansehen` oder `Pilot anfragen`
 - Sekundaere CTA auf `Kostenlos testen`
 - Einen Abschnitt `Fuer wen ist das?` mit drei Kacheln:
  `Team`, `Verein`, `Coworking-Kueche`
 - Einen Abschnitt `So startet ihr in 1 Nachmittag`
 - Einen Abschnitt `Papier heute, digital morgen, RFID spaeter`
 ### Danach
 - Preissektion mit realen Stufen statt nur Paketnamen
 - FAQ zu `Brauchen wir App-Downloads?`, `Kann Papier bleiben?`, `Was kostet
  RFID spaeter?`, `Wie schnell sind wir live?`
 - Vertrauenselemente:
  `Hosting in DE/EU`, `Datenschutz`, `keine Kreditkarte fuer Pilot`, `persoenliche
  Begleitung`
 - Spater: Logos, Zitate und Mini-Case-Studies von echten Piloten
 ### Konkrete Copy-Richtung fuer die Hero
 - Headline: `Die Kaffeekasse ohne Zettelchaos`
 - Subline: `Erfasst Kaffee, Getraenke und Einzahlungen digital, fuehrt
  Papierlisten weiter und haltet Salden sauber nachvollziehbar - fuer Teams,
  Vereine und Community-Standorte.`
 - CTA 1: `Demo ansehen`
 - CTA 2: `Pilot starten`
 ## Lead-Funnel
 ### Zielbild
 Nicht direkt von `Landing Visit` zu `voller Self-Service-Registrierung`
 optimieren. Dazwischen braucht es eine niedrigere Huerde.
 Empfohlener Funnel:
 1. Landing Visit
 2. CTA Klick auf `Demo ansehen` oder `Pilot anfragen`
 3. Lead erfasst
 4. Demo angesehen oder Termin gebucht
 5. Pilot zugesagt
 6. Tenant angelegt
 7. Erste Buchung innerhalb von 24 Stunden
 8. Erste Einzahlung oder erste Papierliste innerhalb von 7 Tagen
 9. Verlaengerung oder Upgrade
 ### Minimaler Funnel fuer die ersten 90 Tage
 - Kanal 1: Warmes Netzwerk
 - Kanal 2: Direktansprache lokaler Vereine, Coworking-Spaces, Bueros,
  Feuerwehren, Gemeinschaftsraeume
 - Kanal 3: 2-3 kurze Content-Stuecke mit konkretem Problemfokus:
  `Excel vs. Kaffeeliste`, `Papierliste sauber nacherfassen`, `Wann lohnt sich
  RFID wirklich?`
 ### Tracking, das sofort noetig ist
 Die Eventnamen existieren schon in [docs/marketing-ops.md](./marketing-ops.md).
 Fuer die ersten 90 Tage reicht:
 - `landing_view`
 - `demo_clicked`
 - `pilot_requested`
 - `register_started`
 - `tenant_registered`
 - `first_consumption_recorded`
 - `first_payment_recorded`
 - `paper_sheet_created`
 ### CRM-Minimum
 Noch kein grosses CRM-Projekt starten. Eine einfache Tabelle oder ein sehr
 schlankes CRM reicht mit diesen Feldern:
 - Organisation
 - Segment
 - Ansprechpartner
 - Problem heute
 - Anzahl Nutzer
 - Heute Papier, digital oder gemischt
 - Interesse an RFID spaeter: ja/nein
 - Status: `neu`, `demo`, `pilot`, `aktiv`, `verloren`
 - Grund fuer Verlust
 ## Pricing-Validierung
 ### Marktbeobachtung am 2026-06-15
 - Getraenkewart kommuniziert eine einfache Preislogik von `20 Cent pro Mitglied
  und Monat`, mit `0 EUR` fuer sehr kleine Teams und `5 EUR / Monat` fuer 25
  Mitglieder.
 - selbstbedienBar zeigt eine kostenlose Einstiegsstufe mit bis zu 5 Usern.
 - Clubfridge bewirbt 30 Tage Gratis-Test und argumentiert ueber geringe
  laufende Kosten und klare Einsparung von Verwaltungsaufwand.
 - Cobot liegt als Coworking-Management-Plattform deutlich hoeher und eignet sich
  eher als Referenz fuer den sales-assistierten Coworking-Pfad als fuer die
  breite Preiserwartung im Vereins- und Teamsegment.
 ### Schlussfolgerung
 Der Team-/Vereinsmarkt ist preissensibel. Eine `normale B2B-SaaS-Optik` mit
 hohem Einstiegspreis wird dort frueh bremsen. Gleichzeitig ist Coworking als
 Segment eher bereit, fuer operative Zuverlaessigkeit und spaetere Integrationen
 mehr zu zahlen.
 ### Validierungsansatz
 Nicht sofort eine endgueltige Preisarchitektur festschreiben. In den ersten
 Piloten zwei Preislogiken testen:
 - Variante A: flache Standortpreise
  - Beispiel: `9 EUR`, `19 EUR`, `39 EUR`
 - Variante B: faire Mitgliederlogik
  - Beispiel: `0,20 EUR pro aktivem Mitglied/Monat` mit Mindestpreis
 ### Was oeffentlich sichtbar sein sollte
 - 30 Tage Pilot oder Testphase
 - Kein Kreditkarten-Zwang am Anfang
 - RFID nicht oeffentlich festpreisen, sondern `auf Anfrage / Pilot`
 - Klarer Satz: `Fuer groessere Standorte oder RFID-Szenarien sprechen wir kurz
  direkt miteinander`
 ### Was in jedem Gespraech abgefragt werden sollte
 - Wie viele aktive Nutzer gibt es wirklich?
 - Wie viel Verwaltungszeit spart das pro Monat?
 - Ist eher `pro Mitglied` oder `pro Standort` gefuehlt fair?
 - Wuerde man ohne RFID schon zahlen?
 - Ist Papier-Nacherfassung kaufentscheidend oder nur hilfreich?
 ## Erster Pilotkundenprozess
 ### Idealer Pilotkunde
 - 10-50 aktive Nutzer
 - klares heutiges Problem mit Papier, Excel oder Nachbuchungen
 - ein verantwortlicher Owner
 - Bereitschaft, 14 Tage aktiv zu testen
 - Bereitschaft fuer 2 Feedback-Termine
 ### Pilotablauf
 1. 20-Minuten-Qualifizierung
 2. 30-Minuten-Demo entlang des echten Prozesses
 3. Pilotzusage mit klarem Testziel
 4. Tenant anlegen und Owner live einrichten
 5. Binnen 24 Stunden erste echte Buchung
 6. Tag 7: Check-in zu Aktivierung, Rueckfragen, Widerstaenden
 7. Tag 14 oder 21: Review, Preisgespraech, Verlaengerung oder Abschluss
 ### Pilot-Erfolgskriterien
 - Owner ist aktiv
 - mindestens 5-10 Mitglieder angelegt
 - mindestens 20 echte Buchungen
 - mindestens 1 Einzahlung oder 1 Papierlisten-Posting
 - kein schwerer Vertrauensbruch in Salden oder Nachvollziehbarkeit
 - klare Aussage: `Wuerden wir dafuer zahlen?`
 ### Pilotangebot
 - `Begleiteter Pilot fuer 14 oder 30 Tage`
 - `Einrichtung gemeinsam in 30 Minuten`
 - `Keine Datenmigration noetig`
 - `Feedback gegen guenstige Early-Adopter-Konditionen`
 ## Priorisierte 30-60-90-Tage-Empfehlung
 ## Tage 1-30
 Ziel: Message klaeren, Demo faehig machen, erste Gespraeche starten.
 - Einen Beachhead final auswaehlen:
  `Teams/Vereine mit Hybrid-Prozess` sollte aktuell gewinnen.
 - Startseite sprachlich neu ausrichten und technische Begriffe aus der Hero nach
  unten verschieben.
 - Demo-Umgebung mit 2-3 vorbereiteten Tenants aufsetzen.
 - CTA-Struktur erweitern:
  `Demo ansehen`, `Pilot anfragen`, `Kostenlos testen`
 - Minimales Tracking fuer Landing, Demo, Signup und Aktivierung einbauen.
 - Outreach-Liste mit 50 passenden Erstkontakten aufbauen, zuerst warm, dann
  lokal-kalt.
 - 10 Discovery-Gespraeche fuehren.
 - 3 Pilotkunden anbahnen.
 Messbar bis Tag 30:
 - 10 Gespraeche
 - 3 qualifizierte Pilotkandidaten
 - 1 funktionierende Browser-Demo
 - 1 Landingpage-Version mit klarer Botschaft
 ## Tage 31-60
 Ziel: Piloten aktivieren, Preissignale einsammeln, erste Beweise erzeugen.
 - 2-3 Piloten live nehmen.
 - Zwei Pricing-Frames in Gespraechen testen:
  `pro Standort` vs. `pro Mitglied`
 - Erste Landingpage-Variante nach Segment pruefen:
  `Verein/Team` gegen `Coworking`
 - Pilot-Onboarding standardisieren:
  Checkliste, Demo-Skript, Follow-up-Mail, Tag-7-Review
 - Ein erstes Mini-Case-Study-Format bauen:
  Problem, Einfuehrung, erste Ergebnisse, Zitat
 - Die haeufigsten Einwaende und Kaufgruende dokumentieren.
 Messbar bis Tag 60:
 - 2-3 aktive Piloten
 - 70% der Piloten mit erster Buchung in 24 Stunden
 - 2 belastbare Preisreaktionen pro Segment
 - 1-2 verwertbare Kundenstimmen
 ## Tage 61-90
 Ziel: Gewinner schaerfen, erste bezahlte Wiederholbarkeit bauen.
 - Gewinner-Positionierung oeffentlich festziehen.
 - Eine oeffentliche Preislogik veroeffentlichen, aber RFID weiter als
  gesonderten Sales-Pfad lassen.
 - Referenzen und Vertrauenselemente auf die Startseite bringen.
 - Den Pilotprozess in einen wiederholbaren `Demo -> Pilot -> Paid` Ablauf
  ueberfuehren.
 - 2 Piloten in bezahlte Kunden oder verlaengerte Nutzung umwandeln.
 - Entscheiden, ob Coworking eine eigene Unterseite und eigene Sales-Story
  verdient oder vorerst nur Upside bleibt.
 Messbar bis Tag 90:
 - 3-5 aktive Pilotkunden insgesamt
 - 2 zahlungsbereite oder zahlende Referenzkunden
 - 1 veroeffentlichte Preislogik
 - klarer Entscheid zur Rolle von Coworking im GTM
 ## Klare Priorisierung
 Wenn nur wenig Kapazitaet da ist, dann in genau dieser Reihenfolge:
 1. Positionierung fuer einen Beachhead
 2. Demo und Pilotprozess
 3. Landingpage-CTA und Tracking
 4. Pricing-Validierung in echten Gespraechen
 5. Erst danach breitere Content- oder Paid-Massnahmen
 ## Was ich explizit nicht priorisieren wuerde
 - Paid Ads vor dem ersten wiederholbaren Pilotprozess
 - eine zu breite Positionierung fuer Teams, Vereine und Coworking gleichzeitig
 - oeffentliche RFID-Versprechen, die noch keine echte Kaufhuerde geloest haben
 - grosse CRM- oder Marketing-Automation-Projekte vor den ersten 3-5 Piloten
 ## Externe Referenzen
 Stand 2026-06-15:
 - Getraenkewart Startseite: https://getraenkewart.com/
 - Getraenkewart Preise: https://getraenkewart.com/preise/
 - Getraenkewart FAQ: https://getraenkewart.com/faq
 - Clubfridge Startseite: https://clubfridge.com/
 - Clubfridge Testsystem / Testen: https://clubfridge.com/clubfridge-testen/
 - Clubfridge RFID-Artikel: https://clubfridge.com/rfid-kuehlschrank-im-vereinsheim-einrichten-so-funktioniert-die-digitale-getraenkekasse/
 - selbstbedienBar Preise: https://www.selbstbedienbar.de/preise/
 - Cobot Pricing: https://www.cobot.me/en/pricing
 - Cobot Startseite: https://www.cobot.me/en/
@@ -0,0 +1,149 @@
 # Naechste Schritte Roadmap
 Stand: 2026-06-15
 Diese Roadmap verdichtet die Empfehlungen mehrerer Fach-Agenten fuer Produkt,
 Sicherheit, Betrieb, QA und Go-to-Market in einen konkreten Fahrplan fuer das
 hochgeladene Repository.
 ## Leitplanke
 Der erste echte Einsatz soll **kein breiter oeffentlicher SaaS-Launch** sein,
 sondern ein **kontrollierter Pilot** mit 1-2 Mandanten.
 Vor Day 1 gewinnt nicht die groesste Funktionsbreite, sondern der Hybrid-Kern:
 - Mitglieder
 - Produkte und Preise
 - digitale Buchungen
 - Einzahlungen
 - Papierlisten-Nacherfassung
 - saubere Salden und Auditierbarkeit
 RFID bleibt fuer den ersten Produktivstart vorbereitet, aber nicht
 automatisiert.
 ## Phase 1: Vor dem Pilot hart absichern
 Diese Punkte sollten vor einem echten Testkunden produktionsnah erledigt sein.
 ### Muss
 - serverseitige Ownership-Pruefung fuer alle `tenant_id`-bezogenen IDs
  bei Buchungen, Einzahlungen, Papierlisten und RFID
 - Self-Service-Rollenmodell schaerfen:
  `member` soll nur fuer sich selbst buchen und nur eigene Daten sehen
 - PINs nicht mehr im Klartext speichern oder anzeigen
 - Rate-Limits fuer Login und Registrierung
 - Passwort-Reset fuer Owner und Mitglieder
 - Registrierung entweder als geschlossenen Pilot betreiben oder erst nach
  Mail-Verifikation oeffnen
 - Korrektur-/Storno-Flow fuer Fehlbuchungen, Einzahlungen und Papierlisten
 - Mitglieder-Saldenliste und Buchungshistorie pro Mitglied
 - CSV-Exporte fuer Salden und Buchungen
 - RFID-Intake fuer Day 1 deaktivieren oder explizit haerten
 ### Soll
 - inkrementellen Migrationspfad einfuehren statt reinem `schema.sql`-Replay
 - Healthcheck um klaren Monitoring-Pfad erweitern
 - Audit-Retention und datensparsame Audit-Metadaten definieren
 - Netcup-Hardening technisch erzwingen:
  HTTPS, Header, Session-Secure-Handling, Installer-Lockdown
 ### Abnahme
 - ein neuer Tenant kann ohne DB-Eingriff eingerichtet werden
 - ein verlorenes Passwort ist ohne manuelle SQL-Hilfe loesbar
 - eine Fehlbuchung laesst sich im Produkt sauber korrigieren
 - Salden in UI, Export und DB stimmen ueberein
 - Cross-Tenant-Zugriffe sind negativ getestet
 ## Phase 2: Staging, Go-Live-Readiness und Pilot-UAT
 ### Betrieb
 - Staging-Umgebung auf Netcup anlegen
 - produktionsnahes Deployment durchspielen
 - SSL, Cron, Healthcheck und Backup auf Staging pruefen
 - Restore einmal wirklich testen
 - Release- und Rollback-Ablauf dokumentiert ueben
 ### QA
 - Smoke-Tests fuer Installation, Admin-Login, Tenant-Registrierung,
  Owner-Login, Mitglieder, Produkte, Buchungen, Einzahlungen und Papierlisten
 - DB-Stichproben fuer `consumption_events`, `ledger_entries`, `ledger_lines`
 - Rechte- und Mandantentrennung negativ testen
 - RFID nur als optionalen Inbox-Test behandeln
 ### Pilotkundenprozess
 - 1 kleiner digitaler Pilotmandant
 - 1 Hybrid-Pilotmandant mit Papierliste
 - 5-7 Tage UAT mit echten oder realistisch simulierten Buchungen
 - Freigabe durch Owner und Admin des Piloten
 ### Abnahme
 - alle Smoke-Tests bestanden
 - keine kritischen Fehler offen
 - Backup, Cron und Restore nachweislich geprueft
 - mindestens 10 Buchungen, 2 Einzahlungen und 1 Papierlisten-Posting pro Pilot
 ## Phase 3: 30-60-90 Tage nach dem Upload
 ## 30 Tage
 - Beachhead-Segment festziehen:
  Teams und Vereine mit Hybrid-Prozess
 - Landingpage verkaufsnaher schaerfen:
  Problem, Demo, Pilot statt Technik zuerst
 - Demo-Setup bauen:
  Team-Demo, Vereins-Demo, 7-Minuten-Skript
 - 10+ Discovery-Gespraeche fuehren
 - 3 Pilotkunden anbahnen
 ## 60 Tage
 - 2-3 Piloten aktiv im System
 - Preisvalidierung zwischen Standortpreis und Mitgliederpreis
 - Tracking fuer `demo_clicked`, `pilot_requested`,
  `tenant_registered`, `first_consumption_recorded`,
  `first_payment_recorded`, `paper_sheet_created`
 - wiederholbaren `Demo -> Pilot -> Aktiv` Ablauf aufbauen
 ## 90 Tage
 - 2 zahlungsbereite Referenzen oder Verlaengerungen
 - erste oeffentliche Preislogik festziehen
 - Landingpage mit Vertrauenselementen und FAQ erweitern
 - Pilot-Feedback in priorisierte Produktarbeit ueberfuehrt
 ## Bewusst spaeter
 Diese Punkte sind sinnvoll, aber nicht noetig fuer den ersten kontrollierten
 Pilot:
 - MFA fuer Owner/Admin
 - Einladungs-Workflow
 - RFID-Autobuchung und Event-Regeln
 - White-Labeling
 - automatisches Billing
 - groessere CRM- oder Marketing-Automation
 ## Sofort als naechste 5 Arbeitspakete
 1. Ownership-Checks, Rollenmodell und PIN-Hardening umsetzen.
 2. Passwort-Reset, Rate-Limits und Pilot-Registrierungsmodus bauen.
 3. Korrekturen/Stornos, Saldenansichten und CSV-Exporte ergaenzen.
 4. Staging auf Netcup aufsetzen und die Go-Live-Checkliste durchgehen.
 5. Demo-Setup plus 1-2 Pilotmandanten vorbereiten.
 ## Verwandte Dokumente
 - [docs/go-live-checklist-netcup.md](/config/workspace/kaffeeliste-neustart/docs/go-live-checklist-netcup.md)
 - [docs/go-to-market-30-60-90.md](/config/workspace/kaffeeliste-neustart/docs/go-to-market-30-60-90.md)
 - [docs/product-strategy.md](/config/workspace/kaffeeliste-neustart/docs/product-strategy.md)
 - [docs/marketing-ops.md](/config/workspace/kaffeeliste-neustart/docs/marketing-ops.md)
 - [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md)