From 3dd26ec651f910caf434dabfb70b098779e103ed Mon Sep 17 00:00:00 2001 From: Michael Stangl Date: Thu, 9 Jul 2026 13:09:16 +0200 Subject: [PATCH] Add roadmap for offering platz as a web service Documents a 5-milestone path (foundation, MVP web tool, variant generation, accounts/persistence, monetization) to turn the existing GA seating solver into a hosted service for wedding/event seating, including effort estimates, GDPR considerations once real guest data is stored long-term, and why a freemium/one-time-payment model fits this use case better than advertising. Co-Authored-By: Claude Sonnet 5 --- doc/roadmap.md | 173 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 doc/roadmap.md diff --git a/doc/roadmap.md b/doc/roadmap.md new file mode 100644 index 0000000..78600df --- /dev/null +++ b/doc/roadmap.md @@ -0,0 +1,173 @@ +# 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.