# 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//`) | 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](https://www.weddingwire.com/wedding-planning/wedding-seating-tables.html) | US, Hochzeit | kostenlos | Teil einer grossen Hochzeitsplaner-Plattform, Gästelisten-Import | | [Wedding Studio](https://www.wedding.studio/seating-chart) | US, Hochzeit | kostenlos, kein Login | 7 Vorlagen, unbegrenzte Gäste | | [Zola Seating Chart](https://www.zola.com/wedding-planning/seating-chart) | US, Hochzeit | kostenlos (Teil von Zola-Ökosystem) | RSVP-Integration | | [Wedibox](https://www.wedibox.com/tools/wedding-seating-chart-maker) | US, Hochzeit | kostenlos | Rund-/Rechtecktische, 4–16 Plätze konfigurierbar | | [SeatPlan.io](https://seatplan.io/) | International | Freemium, Designer $8 einmalig, Event Manager $25/Monat | CSV-Import, Echtzeit-Kollaboration, PWA | | [Simplify Tables](https://www.simplifytables.com/) | International | 30 Gäste kostenlos, danach $9.99/Event | Sitzplan per QR-Code mit Gästen teilen | | [Seating Chart Creator](https://seatingchartcreator.com/) | International | 50 Gäste/5 Tische kostenlos, danach bezahlt | — | | [Canva Seating Chart Maker](https://www.canva.com/create/seating-charts/) | International | Freemium (Teil von Canva) | Design-fokussiert, keine Optimierung | | [Find Your Seat](https://www.findyourseat.de/) | Deutschland | 20 Gäste kostenlos | RSVP-Verwaltung, deutschsprachig | | [Hochzeit Sitzplaner](https://hochzeitssitzplaner.de/) | Deutschland | kostenlos | einfaches deutsches Tool | | [Ja.de Sitzordnung-Planer](https://www.ja.de/hochzeits-planung/Planer-fuer-die-Sitzordnung_seating) | 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](https://www.perfecttableplan.com/) | **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](https://www.perfecttableplan.com/html/genetic_algorithm.html) nötig ist (kombinatorische Explosion) — deckt sich mit unserer eigenen Begründung. Kein Web-Dienst, sondern lokale Windows/Mac-App. | | [tableplan.io](https://www.tableplan.io/) | vermutlich verwandt/Web-Ableger von PerfectTablePlan | Abo-basiert | Web-Variante desselben Anbieters | | [Automated Seating](https://www.automatedseating.com/) | automatisierte Zuordnung | — | spezialisiert auf automatische Zuordnung | | [Social Tables / Cvent Event Diagramming](https://www.socialtables.com/) | eher Enterprise-Event-Diagramming als GA-Optimierung | Enterprise/B2B | Fokus auf grosse Konferenzen/Events, nicht speziell Hochzeit | | GitHub: [meganstiles/Seating_Chart](https://github.com/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 (``-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. - [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 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.