# 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)