# 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). - Referenz-Preistabelle von [automatedseating.com](https://www.automatedseating.com/) (Abo-Modell, **nicht** unser Modell — siehe Konzeptentscheidungen unten): | Plan | Description | Price | Features | |---|---|---:|---| | Free | Perfect for trying out | $0/month | 1 event; Up to 40 guests | | Starter | Perfect for occasional events | $20/month | 1 event; Max 300 guests; Export PDF and Excel | | Pro | Unlimited events and no guest limit | $40/month | Unlimited events; Unlimited guests; Export to PDF and Excel | | Enterprise | Tailored solutions | Custom | Everything in Pro; Unlimited guests; Custom features; White-labeled solutions and exports; On-premise option | --- ## Konzeptentscheidungen (festgelegt 2026-07-10) Die folgenden Grundsatzfragen sind entschieden und gelten für alle Meilensteine: 1. **Zielgruppe für den Launch: Brautpaare (B2C, DACH).** Deutschsprachige UI, niedrigschwellige Preise, DSGVO/deutsches Hosting als zentrales Verkaufsargument — passt zur identifizierten Marktlücke. B2B (Wedding-Planner, Locations) bleibt eine spätere Ausbaustufe (siehe M4), verwässert aber nicht den MVP-Fokus. 2. **Bezahlmodell: Einmalzahlung pro Event, kein Abo.** Der frühere Widerspruch zur Abo-Preistabelle (automatedseating.com-Vorbild, siehe Marktübersicht) ist damit aufgelöst: die Tabelle dient nur noch als Konkurrenz-Referenz. Ein Abo passt nicht zum B2C-Nutzungsmuster (einmalige Hochzeit, 2–3 Monate Planungszeitraum). 3. **Payment über einen Merchant of Record** (Paddle oder Lemon Squeezy statt Stripe/Mollie direkt): Der MoR tritt als Verkäufer auf und übernimmt EU-VAT/OSS, Rechnungsstellung und Steuer-Compliance komplett — bei etwas höheren Gebühren (~5 %) minimaler Verwaltungsaufwand, ideal für Solo-Betrieb. 4. **Free-Tier: bis 40 Gäste, 1 Event**, Export mit Wasserzeichen. (Ersetzt die ältere "z.B. 30"-Angabe in M4.) 5. **Konkrete Preispunkte: bewusst noch offen.** Rahmen: Einmalzahlung im Korridor ~15–45 €, ein oder zwei Stufen; Festlegung erst bei M4-Start per Test/Umfrage. 6. **Hosting: Hetzner** (deutsches Unternehmen, Rechenzentren in DE/FI, AVV vorhanden, Cloud-VPS ab ~5 €/Monat). Deckt das Differenzierungsmerkmal "DSGVO-Hosting in Deutschland" ab; Single-Server-MVP (M1) und spätere Skalierung möglich. 7. **Rechtsform: Betrieb über die bestehende MiSta GmbH** (steht im Impressum) — keine Neugründung nötig, Haftungsbegrenzung besteht damit ab Tag 1. Falls der Dienst gut läuft, kann später eine eigene GmbH aus der Holding ausgegründet werden. Die Namensfrage (Produktname/Domain) bleibt als M0-Punkt offen. 8. **M1 wird zu zweit parallel entwickelt** (Frontend/Backend-Split): eine Person Backend-API + CSV-Import, eine Person Tisch-Editor. Verkürzt M1 entsprechend der Parallelisierungs-Option aus der Gesamtschätzung. 9. **App-Store-Präsenz erst nach M4:** Die PWA-Fähigkeit (Manifest, Service Worker, Touch, responsive) wird in M1 von Anfang an mitgebaut, der Capacitor-Store-Wrapper aber erst nach der Monetarisierung angegangen — spart Store-Gebühren/Review-Aufwand in der MVP-Phase; Gäste kommen ohnehin per QR-Link ohne Store-Installation. 10. **Personen-Vorlieben ("wen mag X nicht / besonders gern") kommen ins Backlog (M4+):** Die im Gäste-Screen skizzierten CSV-Vorlieben-Spalten erfordern eine echte Kern-Erweiterung der `Strafliste` um Personenpaar-Regeln. Erst Kernprodukt validieren; danach als Premium-Feature zum Event-Pass denkbar. Das CSV-Format aus M1 sieht die Spalten bereits vor (werden bis dahin ignoriert), damit später kein Formatbruch nötig ist. 11. **Produktname: Zwei-Marken-Strategie** (festgelegt 2026-07-10): - **Deutschland (Hauptmarkt B2C): "Sitz & Platz"** — Wortspiel mit den Hundekommandos, kurz und merkfähig. Domains `sitzundplatz.de` und `sitzundplatz.com` waren zum Prüfzeitpunkt frei. - **Europa/international: "Sitzwunder" / "SeatWonder"** — ein Markenkern, je Markt übersetzt. Domains `sitzwunder.de`, `sitzwunder.com`, `seatwonder.de` und `seatwonder.com` waren zum Prüfzeitpunkt frei. "Sitzwunder" wird bisher nur generisch für Sitzmöbel verwendet, ein Markenauftritt existiert nicht. - Das englische Pendant des Hundekommando-Witzes ("Sit & Stay") ist als Domain vergeben (Pet-Branche) — daher international SeatWonder statt einer 1:1-Übersetzung von Sitz & Platz. - Geprüfte Alternativen (frei, als Fallback notiert): Platzharmonie (.de/.com), Sitzfee (.de/.com), Tafelplan (.de — Nähe zu tableplan.io), Tafelwunder, Platzzauber, Platzmagie; englisch: theseatinggame.com, seatwhisperer.com, seatedeverafter.com, mindtheseat.com, seatingsorted.com. Claim-/Kampagnen-Ideen: "Wo sitzt Tante Erna?" (wositzttanteerna.de frei), "nie wieder Reise nach Jerusalem". Naheliegende Namen (sitzplan.de, platzplan.de, sitzordnung.de, …) sind sämtlich vergeben. --- ## 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?") - [x] Rechtsform geklärt: Betrieb über die bestehende **MiSta GmbH** (Impressum), keine Neugründung — Ausgründung aus der Holding erst bei Erfolg (Konzeptentscheidung Nr. 7) - [x] Namensfrage geklärt: **"Sitz & Platz"** für Deutschland, **Sitzwunder/SeatWonder** für Europa/international (Konzeptentscheidung Nr. 11; Kandidaten-Recherche und Domain-Verfügbarkeit geprüft 2026-07-10) - [ ] Domains zeitnah registrieren (alle am 2026-07-10 frei — Verfügbarkeit ist flüchtig, nicht bis M4 warten): `sitzundplatz.de`, `sitzundplatz.com`, `sitzwunder.de`, `sitzwunder.com`, `seatwonder.de`, `seatwonder.com` - [ ] Markenregister-Check auf "Sitz & Platz" und "Sitzwunder"/"SeatWonder" in den relevanten Klassen (Software/SaaS, Kl. 9/42): DPMA (dpma.de-Registerauskunft) für Deutschland, EUIPO (eSearch) für die EU-weite Variante — bevor Geld in Branding fließt **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 bei **Hetzner** reicht (Konzeptentscheidung Nr. 6 — kein Kubernetes-Overkill für MVP) **Aufwand:** ~6–8 Wochen für 1 Entwickler:in (Backend-API + einfaches Frontend). Beschlossen ist die Umsetzung **zu zweit parallel** (Konzeptentscheidung Nr. 8): Backend-API + CSV-Import und Tisch-Editor laufen gleichzeitig, realistisch also ~4–5 Wochen Kalenderzeit. **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 — Hetzner ist als Hoster beschlossen (Konzeptentscheidung Nr. 6); EU-Hosting vermeidet die 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 **Freemium statt Werbung** (Begründung siehe unten), Details siehe Konzeptentscheidungen oben: Einmalzahlung pro Event, Merchant of Record, Free-Grenze 40 Gäste. - [ ] Kostenlos: bis 40 Gäste und 1 Event/gespeichertes Projekt, mit Wasserzeichen auf PDF-Export (Konzeptentscheidung Nr. 4) - [ ] Bezahlt (einmalig pro Event, nicht Abo — Konzeptentscheidung Nr. 2; konkrete Preisstufen bei M4-Start festlegen, Korridor ~15–45 €, Konzeptentscheidung Nr. 5): - Größere Gästezahlen - Mehrere Varianten gleichzeitig - PDF/Druckvorlagen ohne Wasserzeichen, Tischkarten-Export - Priorisierte Berechnung (schneller bei Stoßzeiten) - [ ] Payment über Merchant of Record integrieren (Paddle oder Lemon Squeezy, Konzeptentscheidung Nr. 3 — übernimmt EU-VAT/OSS und Rechnungsstellung; Einmalzahlung reicht, kein Abo-Billing nötig) - [ ] Später denkbar: B2B-Lizenz für Hochzeitsplaner:innen/Locations (mehrere Events, White-Label, dann ggf. als Abo) — deutlich höherer Wert pro Kunde als Einzelnutzer; bewusst *nicht* Teil des Launch-Fokus (Zielgruppe B2C, Konzeptentscheidung Nr. 1) **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.** Der Frontend/Backend-Split mit einem zweiten Paar Hände ist beschlossen (Konzeptentscheidung Nr. 8), M1 verkürzt sich damit auf ~4–5 Wochen Kalenderzeit und M2 kann teilweise parallel anlaufen — eher ~4–4,5 Monate bis M4-Abschluss. --- ## 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. ## Pricing **Entschieden: Einmalzahlung pro Event statt Abo** (siehe Konzeptentscheidungen Nr. 2/4/5). Die frühere Abo-Tabelle nach dem Vorbild von automatedseating.com steht jetzt als Konkurrenz-Referenz in der Marktübersicht und ist **nicht** unser Modell. | Plan | Preis | Leistung | |---|---:|---| | Free | 0 € | 1 Event, bis 40 Gäste, Export mit Wasserzeichen | | Event-Pass | einmalig, Korridor ~15–45 € (Stufen offen, Nr. 5) | unbegrenzte Gäste, mehrere Varianten, PDF/Excel/Tischkarten ohne Wasserzeichen, priorisierte Berechnung | | B2B (später) | offen, ggf. Abo | Wedding-Planner/Locations: mehrere Events, White-Label — nach dem B2C-Launch | --- ## Anhang: Namensrecherche (Stand 2026-07-10) Vollständige Kandidatenliste zur Namensentscheidung (Konzeptentscheidung Nr. 11). Verfügbarkeit geprüft am 2026-07-10 per DNS-NXDOMAIN (.de — DENIC verlangt für registrierte Domains funktionierende Nameserver) bzw. Verisign-RDAP (.com) — Verfügbarkeit ist flüchtig, vor Registrierung erneut prüfen. ### Entschiedene Marken | Markt | Marke | Domains (frei am 2026-07-10) | |---|---|---| | Deutschland (B2C-Hauptmarkt) | **Sitz & Platz** | sitzundplatz.de, sitzundplatz.com | | Europa/international | **Sitzwunder / SeatWonder** | sitzwunder.de, sitzwunder.com, seatwonder.de, seatwonder.com | ### Deutsche Kandidaten (seriös) | Name | .de | .com | Bemerkung | |---|---|---|---| | Sitzwunder | frei | frei | → gewählt für Europa-Variante; bisher nur generischer Möbel-Begriff, kein Markenauftritt | | Platzharmonie | frei | frei | beschreibt das Optimierungsziel, Fallback Nr. 1 | | Sitzfee | frei | frei | charmant, evtl. zu verspielt für B2B | | Tafelplan | frei | vergeben | seriös, aber Nähe zum Wettbewerber tableplan.io | | Tafelwunder | frei | frei | — | | Platzzauber | frei | frei | — | | Platzmagie | frei | frei | — | | Sitzharmonie / Tischharmonie | frei | ungeprüft | — | | Sitzmagie | frei | ungeprüft | — | | Sitzplatzwunder | frei | ungeprüft | lang | | Gutgesetzt | frei | frei | — | | Gaesteplatz | frei | frei | Umschreibung wegen Umlaut-Domain | | Feintafel | frei | frei | — | | Sitzo / Setzo | frei | vergeben | Kunstwort, SaaS-Klang | | sitzplan.de, platzplan.de, sitzordnung.de, tischordnung.de, sitzplaner.de, tischplaner.de, platzwunder.de, platzkarte.de, tischlein.de, … | vergeben | — | alle naheliegenden beschreibenden Namen sind weg | ### Witzige deutsche Namen (Film-/Kultur-Anspielungen) | Name | Anspielung | .de | Bemerkung | |---|---|---|---| | **Sitz & Platz** | Hundekommandos | frei | → gewählt als deutsche Hauptmarke | | Ein Platz an der Tafel | "Ein Platz an der Sonne" | einplatzandertafel.de + platzandertafel.de frei | auch als Claim stark | | Wo sitzt Tante Erna? | Insider aus dieser Roadmap (M0, Determinismus-Option) | wositzttanteerna.de frei | Kampagnen-/Claim-Material | | Herr der Tische | "Der Herr der Ringe" (Doppelbezug: Trauringe) | herrdertische.de + derherrdertische.de frei | Markenrecht-Risiko (Middle-earth Enterprises) | | Game of Tables | Game of Thrones ("Red Wedding") | frei | Markenrecht-Risiko (HBO), nur Blog/Kampagne | | Tischpate | "Der Pate" | frei | — | | Vier Hochzeiten | "4 Hochzeiten und ein Todesfall" | frei | Kollision mit VOX-Show "4 Hochzeiten und eine Traumreise" | | Wer sitzt denn da? | Quizshow-Klang | frei | — | | Und ewig sitzt die Tante | "Und ewig grüßt das Murmeltier" | frei | — | | Reise nach Jerusalem, Tischgeflüster, Platz da!, Tante Erna, Tafelrunde, Dinner for All, Setzkasten | — | vergeben | die wären gut gewesen | ### Englische Kandidaten (.com) | Name | Anspielung | Status | Bemerkung | |---|---|---|---| | **SeatWonder** | Zwilling von Sitzwunder | seatwonder.com + .de + seatingwonder.com frei | → gewählt als internationale Marke | | The Seating Game | "The Dating Game" / "The Crying Game" | frei | verspielt-ironisch | | Seat Whisperer | "Der Pferdeflüsterer" | frei | — | | Seated Ever After | "…happily ever after" | frei | hochzeitlichste Variante | | Mind the Seat | "Mind the Gap" | frei | britisch-trocken | | Seating Sorted | britisches "Sorted!" | frei | eher B2B-Ton | | Seat and Smile | "Meet & Greet"-Nachbarschaft | frei | generisch | | Sit & Stay (sitandstay.com, sitstay.com) | Hundekommandos — 1:1-Pendant zu Sitz & Platz | vergeben (Pet-Branche) | Grund für SeatWonder statt Übersetzung | | pleasebeseated, haveaseat, takeyourseat, beseated, seatyourself, sithappens, seatandgreet, seatmagic, seatharmony, seatcupid, happilyseated, seatfairy, … | — | vergeben | alle klassischen Usher-Phrasen/Puns sind weg | ### Chinesische Pendants (Fun Fact, kein Roadmap-Ziel) | Ausdruck | Pinyin | Bedeutung | Eignung | |---|---|---|---| | 对号入座 | duì hào rù zuò | "Nummer abgleichen, Platz einnehmen" — feststehende Redewendung fürs Finden des zugewiesenen Sitzplatzes; übertragen: "sich angesprochen fühlen" | Das idiomatische Pendant zu "Sitz & Platz" — als Name eines Seating-Tools für Muttersprachler sofort witzig | | 坐 / 座 | zuò / zuò | "sitzen" / "Sitzplatz" — perfekte Homophone (座 ist historisch aus 坐 entstanden) | eingebautes Wortspiel für Claims/Wortmarken | | 坐下 / 别动 | zuòxià / bié dòng | Hundekommandos "Sitz!" / "Bleib!" | 1:1-Übertragung des Hundekommando-Witzes scheitert: 别动 hat keine Sitzplatz-Bedeutung | | 婚宴座位表 | hūnyàn zuòwèi biǎo | "Hochzeitsbankett-Sitzplan" (Fachbegriff) | SEO-/Suchbegriff, kein Markenname | Ein China-Launch wäre ein eigenes Vorhaben (ICP-Lizenz, Datenlokalisierung nach PIPL, WeChat-Mini-Programm statt PWA) und ist bewusst **nicht** Teil dieser Roadmap. ## Wichtige Features ### Screen zur Eingabe der Tische - Vordefinierte Auswahl von Räumen und fertigen Konfigurationen, Räume mit einer Bühne und Musik daneben, Sitze im Halbkreis, Sitze im Parallelen zur Bühne und aussen im Kreis, Zentrale Bühne mit Tischen drum herum, Eingänge rechts, links oben unten per Klick und zum Verschieben an der Wand, Hufeisen Tafel, normale Tafel etc. -> Auswahl bzw. Verschiebung der Elemente. Verlängerung oder Verkürzung der Tische - Die Bühne ist in Ausdehnung und Breite ebenfalls anpassbar. Mehrere Bühnen sind möglich (z.B. Tanzfläche, separat davon die Band) - Vordefinierte Auswahl von Tischen, Gerade mit n - Sitzen, einreihig bestuhlt, zweireihig bestuhlt, M-Form (rechteckig zueinander gestellt), Kreissegment mit Radius R und N Sitzen darauf, Elliptische Sitze, Runde Sitze, Rechteckige Sitze - Anzahl der Stühle durch Anwahl einer Tischkante definierbar, durch Auswahl des ganzen Tisches, Selektion einer Reihe oder einzelner Stühle und dann löschbar - Einzelne Platzierung von Stühlen an einem Tisch siehe auch https://www.perfecttableplan.com/html/tour.html #### Technische Umsetzung (beantwortet 2026-07-09) Inline-`` im DOM, nicht `` (statisch, nicht klickbar) und nicht reines Canvas (pixelbasiert, kein Objekt pro Tisch/Stuhl im DOM). Jeder Tisch/Stuhl/jede Bühne ist ein eigenes SVG-Element, das Klick-/Drag-Events, Selektions-Highlighting per Style-Attribut bekommt und sich geometrisch an `alsSVG()` aus `Strukturdaten.py` anlehnt (Radius-/Platzierungsberechnung ist server-seitig schon vorhanden und dient als Ausgangslayout). - **State-getrieben rendern:** Ein JS-Array von Tisch-Objekten (`{id, typ, x, y, radius, plaetze, rotation, nachbarn}`) ist die Wahrheit; das SVG wird aus diesem State erzeugt, nicht umgekehrt aus dem SVG gelesen. - **React + SVG als JSX** für die Komponentenstruktur (``, ``, ``), State-Changes rendern automatisch neu. - Für Drag/Resize/Rotate/Selektion **nicht bei Null anfangen**, sondern eine Bibliothek nutzen: [Konva](https://konvajs.org/)/`react-konva` (Canvas-basiert, bringt Drag/Resize/Rotate fertig mit) oder [svg.js](https://svgjs.dev/)/[interact.js](https://interactjs.io/) (bleiben bei echtem SVG als gemeinsamer Quelle für Editor UND Export). - **Vordefinierte Layouts/Formen** (Hufeisen, M-Form, Kreissegment, Bühne mittig, …) sind reine **Presets, die den State vorbefüllen** — kein Sonderfall im Rendering, nur unterschiedliche Ausgangs-Arrays von Tisch-Objekten. - **Speichern:** Der State wird als JSON an `POST /sitzung/{id}/tische` geschickt — direkter Ersatz für die heutige `tische.ini`; "Nachbarliste" wird aus der räumlichen Nähe der Koordinaten abgeleitet statt manuell gepflegt. - **Ergebnis-Anzeige nach der GA-Berechnung** ist dagegen bewusst *kein* editierbarer Canvas-State mehr, sondern das serverseitig generierte `alsSVG()` — reine Anzeige/Export, direkt einbettbar oder als ``. Damit gibt es zwei klar getrennte Pfade: einer zum Bearbeiten (Konva/SVG+JS im Frontend), einer zum Anzeigen/Drucken (`alsSVG()` server-seitig) — kein Aufwand, den Editor-State rückwärts in druckfähiges SVG zu konvertieren. **Empfehlung:** React + react-konva für den editierbaren Tisch-Editor, plus Weiterverwendung von `alsSVG()` für read-only Ergebnisdarstellung und Druck-Export. ### Screen zur Eingabe der Gäste - als anonyme Gruppe mit einer Menge von enthaltenen Leuten - als benannte Gruppe (Familie Heiner) - als Liste von einzelnen Personen die eine Gruppe sind und gemeinsam sitzen wollen - als csv Liste mit einer eigenen Spalte mit der Angabe mit Vorliebe der Gäste (wen diese Person nicht mag und einer Spalte wen sie besonders mag, Kommasepariert). **Backlog M4+ (Konzeptentscheidung Nr. 10):** die Auswertung dieser Spalten erfordert eine Kern-Erweiterung der `Strafliste` um Personenpaar-Regeln; das CSV-Format sieht die Spalten ab M1 vor, ausgewertet werden sie erst später (Premium-Feature-Kandidat). ### VIP Angabe - Das Brautpaar und die Brauteltern oder spezielle Gäste haben fixe Sitzplätze die sich nicht ändern sollen ### Visualisierung des Ergebnisses Raumplan mit Gruppen, Familien, VIP in mehreren Farben Mehrere Pläne durch Umschalten im Vergleich (Anzahl der gefundenen Lösungen und Rankings werden angezeigt) ### druckbare Ergebnis Listen - alphabetische Liste der Gäste und welcher Tisch - Alphabetische Liste der Gruppennamen und welche Tisch(e) - Liste der Tische und zugehörige Liste der Namen - QR Code für das Event und die zugehörige App, welche zu einem Namen den Tisch verrät - Tischkarten mit vordefinierten Designbereichen (Bild, Namen, Mittig) und verschiedenen Fonts - vordefinierten Designs die automatisch befüllt werden. Font anpassbar ### Kuchendiagramme im Dashboard für die Orga - Verteilung Männlich/Weiblich, Alter - befüllte unbefüllte Tische - noch nicht zugewiesene Gäste/ freie Sitze ## Technik Fragen (beantwortet 2026-07-09) ### Eine Webseite, per App (iOS/Android) UND Browser nutzbar Empfehlung: **kein separater App-Code**, sondern die Web-App (aus M1) als **installierbare PWA** bauen und zusätzlich per **WebView-Wrapper** (z.B. [Capacitor](https://capacitorjs.com/)) in den App Store / Play Store bringen. Capacitor packt eine bestehende Web-App 1:1 in eine native Hülle — dieselbe Codebasis, kein Flutter/React-Native-Zweitprojekt. - Praktische Konsequenz für M1: Frontend von Anfang an PWA-fähig auslegen (Manifest, Service Worker, responsives Layout, Touch-Bedienung für den Tisch-Editor testen) — nachträglich draufzusetzen ist deutlich teurer als von Beginn an mitzudenken. - QR-Code-Feature (siehe "druckbare Ergebnis Listen") passt gut dazu: Link öffnet die PWA im Browser oder in der installierten App, kein Store-Zwang für Gäste. - Store-Present (native Wrapper-App) macht vor allem für den **Organisator/Wedding-Planner** Sinn (regelmäßige Nutzung, Push-Benachrichtigungen bei Änderungen); Gäste kommen i.d.R. einmalig über den QR-Link und brauchen keine Store-Installation. - Aufwand Capacitor-Wrapper: klein (~1–3 Tage) *sobald* die PWA steht. **Beschlossen (Konzeptentscheidung Nr. 9): der Store-Wrapper kommt erst nach M4** — bis dahin nur PWA. Achtung bei der späteren Umsetzung: das Gebühren-/In-App-Purchase- Modell von Apple/Google kollidiert ggf. mit der Einmalzahlung im Web (Kauf dann nur im Browser anbieten, App als reiner Viewer). ### Lokale Testinstanz für FastAPI (Hugo-Server-Äquivalent) Ja, das geht direkt und ohne Docker: ```bash uvicorn main:app --reload ``` `--reload` beobachtet Dateiänderungen und lädt automatisch neu, läuft standardmäßig auf `localhost:8000`. FastAPI liefert zusätzlich unter `/docs` eine interaktive Swagger-UI, mit der sich alle Endpunkte (`POST /sitzung`, `.../tische`, `.../personen`, `.../berechnen`, …) ohne eigenes Frontend durchklicken/testen lassen — praktisch für die Backend-Entwicklung in M1, bevor der Tisch-Editor existiert. **Docker ist für die lokale Testinstanz nicht nötig** — erst relevant, sobald: - eine echte DB (Postgres, ab M3) oder weitere Services (Redis/Celery, ab M2 bei Hintergrund-Jobs) lokal mit reproduzierbarem Setup laufen sollen, - die Produktionsumgebung 1:1 nachgebildet werden soll (Nginx davor, gleiche Python-Version wie im Deployment), - mehrere Entwickler:innen ein identisches Setup brauchen. Aufwand dann: ein `Dockerfile` für FastAPI (~10 Zeilen) + `docker-compose.yml` für DB/Redis (~20–30 Zeilen) — überschaubar, aber erst ab M2/M3 sinnvoll, nicht für M1. **Empfehlung für M0/M1:** `uvicorn --reload` reicht für die gesamte MVP-Phase (M1, keine Accounts/DB). Docker-Compose erst einführen, wenn M2 (Job-Queue) oder M3 (Postgres) ansteht.