Add roadmap for offering platz as a web service

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>

doc/roadmap.md

@@ -0,0 +1,173 @@
+# 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.