Michael Stangl
4c9f57db5a
Surveys wedding/event seating tools currently available: most are pure drag-and-drop editors with no optimization algorithm, while a smaller group (notably PerfectTablePlan) uses the same genetic algorithm / scoring approach as this project. Documents pricing patterns and identifies the gap this project could fill: a web-native SaaS with real optimization and a German/EU-focused, GDPR-friendly hosting story, which none of the surveyed competitors currently offer together. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
234 lines
14 KiB
Markdown
234 lines
14 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 |
|
||
|
||
---
|
||
|
||
## 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 (`<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.
|
||
|
||
- [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.
|