# 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 | --- ## 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.