Michael Stangl
3dd26ec651
Documents a 5-milestone path (foundation, MVP web tool, variant generation, accounts/persistence, monetization) to turn the existing GA seating solver into a hosted service for wedding/event seating, including effort estimates, GDPR considerations once real guest data is stored long-term, and why a freemium/one-time-payment model fits this use case better than advertising. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
174 lines
8.6 KiB
Markdown
174 lines
8.6 KiB
Markdown
# Platz als Web-Dienst — Roadmap
|
||
|
||
*Sitzplatz-Optimierung für Hochzeiten & Events als SaaS*
|
||
|
||
---
|
||
|
||
## Status Quo (verifiziert 2026-07-09)
|
||
|
||
Der bestehende Python-Kern verarbeitet **bereits vollständig echte Personendaten**:
|
||
|
||
- `work/test2/bestellung.xml` enthält reale Einzelpersonen (Name, Vorname, Titel), eine
|
||
VIP-Gruppe mit fest zugewiesenem Tisch, und eine anonyme Sammelbuchung — alle Pfade
|
||
wurden end-to-end getestet und funktionieren korrekt.
|
||
- Output (`TischePersonen.txt`, `PersonenTische.csv`, `Sitzplatzverteilung.svg`) enthält
|
||
korrekt durchgereichte Namen inkl. Titel.
|
||
|
||
**Das ist also kein offener Kern-Bug** — die Lücke liegt woanders:
|
||
|
||
| Was schon geht | Was fehlt für den Web-Dienst |
|
||
|---|---|
|
||
| Personen mit Namen/Titel/Gruppe verarbeiten | Web-Formular / CSV-Import statt Hand-XML |
|
||
| GA erzeugt eine gute Sitzordnung | Mehrere Varianten parallel vergleichen |
|
||
| SVG-Visualisierung einer Verteilung | Interaktiver Tisch-Editor (Drag & Drop) |
|
||
| CLI + Dateisystem (`work/<name>/`) | Multi-User, Projekte, Accounts, DB |
|
||
| — | Bezahlmodell, DSGVO-Konformität |
|
||
|
||
---
|
||
|
||
## Meilenstein 0 — Fundament (kein neues Feature, Vorbereitung)
|
||
|
||
**Ziel:** Der bestehende Kern läuft stabil, testbar und ist bereit für eine API-Hülle.
|
||
|
||
- [x] Python 2 → 3 Migration (bereits erledigt)
|
||
- [x] Unittest-Suite mit Kernszenarien (bereits erledigt)
|
||
- [ ] `Farm` erweitern: `TopN()` statt nur `Bester()` — Grundlage für "mehrere Varianten"
|
||
später. Kleine, risikoarme Änderung am bestehenden Code.
|
||
- [ ] Determinismus-Option: `random.seed()` als Parameter durchreichen, damit ein Ergebnis
|
||
bei Bedarf reproduzierbar ist (Support-Anfragen: "warum sitzt Tante Erna da?")
|
||
- [ ] Rechtsform/Namensfrage klären, Firmengründung falls Umsatz geplant ist (Impressumspflicht
|
||
bei einem öffentlichen Dienst mit Personendaten Dritter)
|
||
|
||
**Aufwand:** ~1 Woche. **Kein Nutzer sieht das noch.**
|
||
|
||
---
|
||
|
||
## Meilenstein 1 — MVP: Single-User Web-Tool, keine Accounts
|
||
|
||
**Ziel:** Eine Person kann übers Web eine Hochzeit planen, ohne Login. Ergebnis: PDF/SVG-Export.
|
||
Session-basiert, nichts wird dauerhaft gespeichert (schont Datenschutz-Aufwand in dieser Phase).
|
||
|
||
- [ ] REST-API um den bestehenden Kern (FastAPI empfohlen: async, OpenAPI-Doku gratis,
|
||
gut für Traffic-Spitzen an Wochenenden)
|
||
- `POST /sitzung` — legt eine Arbeits-Session an (Tische + Personen)
|
||
- `POST /sitzung/{id}/tische` — Tisch-Layout (Ersatz für `tische.ini`)
|
||
- `POST /sitzung/{id}/personen` — CSV-Upload (Ersatz für `bestellung.xml`)
|
||
- `POST /sitzung/{id}/berechnen` — startet die GA-Optimierung
|
||
- `GET /sitzung/{id}/ergebnis.svg` — liefert `alsSVG()`-Resultat
|
||
- [ ] **CSV-Format definieren und Parser bauen** (Analogon zu `XMLConfig`):
|
||
Spalten z.B. `Vorname;Nachname;Titel;Gruppe;Tisch(optional=VIP)`
|
||
→ wird zu `Personen`/`Gruppen`/VIP-Map, exakt wie `XMLConfig.HandleBestellung()`
|
||
heute — reiner Adapter, kein Kernumbau.
|
||
- [ ] **Interaktiver Tisch-Editor** (Frontend, React/Vue + SVG):
|
||
Kreise per Drag & Drop platzieren, Kapazität einstellen, Nachbarschaft automatisch
|
||
aus räumlicher Nähe ableiten (statt manueller `Nachbarliste`-Pflege in `tische.ini`)
|
||
- Baut direkt auf `alsSVG()`-Geometrie auf (Radius-Berechnung ist bereits da)
|
||
- [ ] Undo/Redo, "Variante neu berechnen"-Button
|
||
- [ ] Hosting: einfacher Single-Server-Betrieb reicht (kein Kubernetes-Overkill für MVP)
|
||
|
||
**Aufwand:** ~6–8 Wochen für 1 Entwickler:in (Backend-API + einfaches Frontend).
|
||
**Rechtlich:** Solange keine Daten dauerhaft gespeichert werden (nur Session-Storage,
|
||
TTL von z.B. 24h), ist der DSGVO-Aufwand überschaubar (kein Account = kein
|
||
Personenbezug zum Betreiber über die Sitzung hinaus). Trotzdem: Auftragsverarbeitungsvertrag
|
||
mit Hosting-Provider und eine Datenschutzerklärung sind Pflicht, sobald IP-Adressen
|
||
verarbeitet werden (was bei jedem Webserver der Fall ist).
|
||
|
||
---
|
||
|
||
## Meilenstein 2 — Varianten-Generierung für größere Säle
|
||
|
||
**Ziel:** Nutzer bekommt mehrere Vorschläge statt einer festen Lösung, kann vergleichen.
|
||
|
||
- [ ] `Farm.TopN(n)` nutzen, um z.B. 3–5 unterschiedliche gute Lösungen zurückzugeben
|
||
(ggf. mit verschiedenen Zufalls-Seeds parallel starten für Diversität)
|
||
- [ ] Vergleichsansicht im Frontend: Varianten nebeneinander, Kennzahlen sichtbar machen
|
||
(Wertigkeit, Anzahl Gruppentrennungen, "Alleine sitzende Personen")
|
||
- [ ] Performance: bei sehr großen Sälen (200+ Personen) ggf. `Zyklus`-Parameter
|
||
(Anzahl Generationen/Population) an Problemgröße koppeln, damit Antwortzeit
|
||
im Web-Kontext (Sekunden, nicht Minuten) bleibt — Lasttest nötig
|
||
- [ ] Optional: Hintergrund-Job-Queue (z.B. Celery/RQ), falls Berechnung >5s dauert,
|
||
damit der Webserver nicht blockiert
|
||
|
||
**Aufwand:** ~3–4 Wochen, aufbauend auf Meilenstein 1.
|
||
|
||
---
|
||
|
||
## Meilenstein 3 — Accounts & dauerhafte Personendaten
|
||
|
||
**Ziel:** Registrierte Nutzer:innen können Projekte speichern, später weiterbearbeiten,
|
||
Gäste-CSV wiederverwenden (z.B. für mehrere Event-Teile: Trauung, Feier).
|
||
|
||
- [ ] Nutzerkonten (E-Mail/Passwort oder OAuth), Projekt-Persistenz in einer DB
|
||
(Postgres passt gut: Tische/Gruppen/Personen als relationale Tabellen)
|
||
- [ ] **Datenschutz wird jetzt zentral, nicht mehr nebensächlich:**
|
||
- Betroffene sind Dritte (Hochzeitsgäste), nicht der Account-Inhaber → besondere
|
||
Sorgfaltspflicht, da die Gäste dem Dienst nie selbst zugestimmt haben
|
||
- Löschkonzept: automatische Löschung X Monate nach dem Event-Datum anbieten
|
||
- Datenexport/-löschung auf Anfrage (Art. 15/17 DSGVO)
|
||
- Verschlüsselung ruhender Daten, falls sensible Zusatzfelder (Allergien,
|
||
Sitzwünsche mit Konfliktpotential) erfasst werden
|
||
- AVV mit Hosting-Provider (z.B. bei EU-Hosting: Hetzner, IONOS — vermeidet
|
||
Standardvertragsklauseln-Diskussion bei US-Anbietern)
|
||
- [ ] Sharing: Account-Inhaber:in lädt Co-Planer:in (Partner, Wedding-Planner) mit
|
||
eingeschränkten Rechten ein
|
||
|
||
**Aufwand:** ~4–6 Wochen Entwicklung + juristische Beratung (Datenschutzerklärung,
|
||
ggf. Verarbeitungsverzeichnis) einplanen, bevor das live geht.
|
||
|
||
---
|
||
|
||
## Meilenstein 4 — Monetarisierung
|
||
|
||
**Empfehlung: Freemium statt Werbung** (Begründung siehe unten).
|
||
|
||
- [ ] Kostenlos: bis N Personen (z.B. 30) und 1 gespeichertes Projekt, mit Wasserzeichen
|
||
auf PDF-Export
|
||
- [ ] Bezahlt (einmalig pro Event, nicht Abo — passt zum Nutzungsmuster):
|
||
- Größere Gästezahlen
|
||
- Mehrere Varianten gleichzeitig
|
||
- PDF/Druckvorlagen ohne Wasserzeichen, Tischkarten-Export
|
||
- Priorisierte Berechnung (schneller bei Stoßzeiten)
|
||
- [ ] Payment-Provider integrieren (Stripe/Mollie — Einmalzahlung reicht, kein
|
||
Abo-Billing nötig für MVP dieses Modells)
|
||
- [ ] Später denkbar: B2B-Linzenz für Hochzeitsplaner:innen/Locations (mehrere Events,
|
||
White-Label) — deutlich höherer Wert pro Kunde als Einzelnutzer
|
||
|
||
**Warum nicht Werbung:**
|
||
Hochzeitsplanung ist eine seltene, emotional hochwertige Nutzung (im Schnitt einmal
|
||
im Leben, wenige Sitzungen über Wochen verteilt). Das ergibt sehr wenige Ad-Impressions
|
||
pro Nutzer:in — Werbenetzwerke zahlen nach Impressions/Klicks, hier fehlt schlicht
|
||
das Volumen für nennenswerte Einnahmen. Gleichzeitig wirkt Werbung in einem emotional
|
||
aufgeladenen Kontext (Hochzeit) unpassend und schadet eher der Zahlungsbereitschaft
|
||
für ein Freemium-Upgrade. Eine kleine, spitze Zielgruppe mit klarem Zahlungsanlass
|
||
(einmal fürs eigene Fest) passt besser zu Einmalzahlungen als zu Werbe-Reichweite.
|
||
|
||
**Aufwand:** ~2–3 Wochen für Payment-Integration + Plan-Limits im Backend.
|
||
|
||
---
|
||
|
||
## Zeitliche Gesamtschätzung (1 Entwickler:in, Vollzeit)
|
||
|
||
| Meilenstein | Dauer | Kumuliert |
|
||
|---|---|---|
|
||
| M0 Fundament | 1 Woche | 1 Woche |
|
||
| M1 MVP (Web, kein Account) | 6–8 Wochen | ~2 Monate |
|
||
| M2 Varianten | 3–4 Wochen | ~3 Monate |
|
||
| M3 Accounts + DSGVO | 4–6 Wochen | ~4,5 Monate |
|
||
| M4 Monetarisierung | 2–3 Wochen | ~5 Monate |
|
||
|
||
**Realistischer Fahrplan bis zum ersten zahlenden Kunden: ~5–6 Monate**, wenn M1 und M2
|
||
teilweise parallel mit einem zweiten Paar Hände (Frontend/Backend-Split) laufen.
|
||
|
||
---
|
||
|
||
## Wichtigste Risiken
|
||
|
||
1. **Datenschutz wird unterschätzt** — sobald echte Gästelisten dauerhaft gespeichert
|
||
werden (ab M3), ist das kein Nebenthema mehr. Frühzeitig Rechtsberatung einholen,
|
||
nicht erst kurz vor Launch.
|
||
2. **GA-Performance bei großen Sälen** — noch nicht lastgetestet mit z.B. 300+ Personen
|
||
und vielen Tischen; ggf. Optimierungsbedarf vor M2.
|
||
3. **Wettbewerb prüfen** — es gibt bereits kommerzielle Seating-Planner-Tools
|
||
(z.B. für Hochzeiten und Corporate Events); Differenzierung (z.B. der
|
||
Gruppentrennungs-Strafalgorithmus, VIP-Fixplätze) sollte klar herausgestellt werden.
|