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

---

Marktübersicht — wer bietet das schon an? (recherchiert 2026-07-09)

Der Markt für Sitzplan-/Seating-Tools für Hochzeiten und Events ist bereits gut besetzt. Wichtigste Erkenntnis: die meisten Tools sind reine Drag-&-Drop-Editoren ohne Optimierungsalgorithmus — der Nutzer platziert Gäste manuell selbst. Ein kleiner Teil nutzt tatsächlich einen Optimierungsalgorithmus wie unser Programm (genetischer Algorithmus mit Punktebewertung), das ist also der eigentliche Differenzierungspunkt, nicht der Drag-&-Drop-Editor an sich (den bieten praktisch alle).

Reine Drag-&-Drop-Tools (kein Optimierungsalgorithmus, nur manuelle Platzierung)

Anbieter	Markt	Modell	Besonderheit
WeddingWire Seating Chart Tool	US, Hochzeit	kostenlos	Teil einer grossen Hochzeitsplaner-Plattform, Gästelisten-Import
Wedding Studio	US, Hochzeit	kostenlos, kein Login	7 Vorlagen, unbegrenzte Gäste
Zola Seating Chart	US, Hochzeit	kostenlos (Teil von Zola-Ökosystem)	RSVP-Integration
Wedibox	US, Hochzeit	kostenlos	Rund-/Rechtecktische, 4–16 Plätze konfigurierbar
SeatPlan.io	International	Freemium, Designer $8 einmalig, Event Manager $25/Monat	CSV-Import, Echtzeit-Kollaboration, PWA
Simplify Tables	International	30 Gäste kostenlos, danach $9.99/Event	Sitzplan per QR-Code mit Gästen teilen
Seating Chart Creator	International	50 Gäste/5 Tische kostenlos, danach bezahlt	—
Canva Seating Chart Maker	International	Freemium (Teil von Canva)	Design-fokussiert, keine Optimierung
Find Your Seat	Deutschland	20 Gäste kostenlos	RSVP-Verwaltung, deutschsprachig
Hochzeit Sitzplaner	Deutschland	kostenlos	einfaches deutsches Tool
Ja.de Sitzordnung-Planer	Deutschland	kostenlos (Teil von ja.de-Portal)	U-/E-/T-Form-Tischanordnungen

Tools mit echtem Optimierungsalgorithmus (direkteste Konkurrenz zu unserem GA-Ansatz)

Anbieter	Algorithmus	Modell	Bemerkung
PerfectTablePlan	Genetischer Algorithmus mit Punktebewertung — methodisch praktisch identisch zu unserem Ansatz (Strafliste/Sitzplatzverteilung)	Desktop-Software, $29.95 einmalig pro Nutzer:in	Erklärt selbst öffentlich, warum GA statt Brute-Force nötig ist (kombinatorische Explosion) — deckt sich mit unserer eigenen Begründung. Kein Web-Dienst, sondern lokale Windows/Mac-App.
tableplan.io	vermutlich verwandt/Web-Ableger von PerfectTablePlan	Abo-basiert	Web-Variante desselben Anbieters
Automated Seating	automatisierte Zuordnung	—	spezialisiert auf automatische Zuordnung
Social Tables / Cvent Event Diagramming	eher Enterprise-Event-Diagramming als GA-Optimierung	Enterprise/B2B	Fokus auf grosse Konferenzen/Events, nicht speziell Hochzeit
GitHub: meganstiles/Seating_Chart	Genetischer Algorithmus (Studienprojekt)	Open Source, kein Produkt	Bestätigt: GA-Ansatz für Hochzeits-Sitzpläne ist ein bekanntes, dokumentiertes Muster, nicht nur unsere Idee

Einordnung für die eigene Positionierung

• Der GA-Ansatz selbst ist kein Alleinstellungsmerkmal — PerfectTablePlan macht das methodisch sehr ähnlich und ist seit Jahren am Markt etabliert (Desktop, kein Web-SaaS). Das validiert aber den Ansatz: ein etablierter Wettbewerber löst dasselbe Problem mit derselben Technik.
• Lücke am Markt: ein Web-natives SaaS mit echtem Optimierungsalgorithmus (nicht nur Drag & Drop) und europäischem/deutschem Fokus inkl. DSGVO-Hosting scheint es aktuell nicht zu geben — die deutschen Anbieter (Find Your Seat, Hochzeit Sitzplaner, Ja.de) bieten nur manuelle Drag-&-Drop-Tools, die Optimierungs-Tools (PerfectTablePlan, tableplan.io) sind englischsprachig und teils Desktop-only.
• Eigene Stärken aus dem bestehenden Code, die sich als Verkaufsargument eignen: VIP-Fixplätze (<Tisch>-Bindung), differenzierte Strafpunkte für Gruppentrennung nach Gruppengrösse (Strafliste.GruppenTrennen), Nachbartisch-Bewertung (nichtNachbar-Strafe) — das geht über simples "möglichst wenig Trennungen" hinaus und ist detaillierter als das, was in den öffentlichen Beschreibungen der Konkurrenz auftaucht.
• Preise der Konkurrenz als Orientierung für M4: kostenlose Kontingente liegen meist bei 20–50 Gästen, Einmalzahlungen bei $8–30, Abo-Modelle bei ~$25/Monat für professionelle Nutzer:innen (Event-Planer:innen, nicht Privatpersonen).

---

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 ist real und etabliert — siehe Abschnitt "Marktübersicht" oben. PerfectTablePlan verfolgt seit Jahren denselben GA-Ansatz, allerdings als Desktop-Tool. Differenzierung muss über Web-nativ + DSGVO-Hosting + detailliertere Regeln (Gruppentrennungs-Strafalgorithmus, VIP-Fixplätze, Nachbartisch-Bewertung) laufen, nicht über "wir haben einen Algorithmus" allein.