150 lines
5.0 KiB
Markdown
150 lines
5.0 KiB
Markdown
# 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)
|