platz/doc/roadmap.md

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.

• Python 2 → 3 Migration (bereits erledigt)
• 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.