Michael Stangl
38 KiB
38 KiB
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.xmlenthä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 | US, Hochzeit | kostenlos | Teil einer grossen Hochzeitsplaner-Plattform, Gästelisten-Import |
| Wedding Studio | US, Hochzeit | kostenlos, kein Login | 7 Vorlagen, unbegrenzte Gäste |
| Zola Seating Chart | US, Hochzeit | kostenlos (Teil von Zola-Ökosystem) | RSVP-Integration |
| Wedibox | US, Hochzeit | kostenlos | Rund-/Rechtecktische, 4–16 Plätze konfigurierbar |
| SeatPlan.io | International | Freemium, Designer $8 einmalig, Event Manager $25/Monat | CSV-Import, Echtzeit-Kollaboration, PWA |
| Simplify Tables | International | 30 Gäste kostenlos, danach $9.99/Event | Sitzplan per QR-Code mit Gästen teilen |
| Seating Chart Creator | International | 50 Gäste/5 Tische kostenlos, danach bezahlt | — |
| Canva Seating Chart Maker | International | Freemium (Teil von Canva) | Design-fokussiert, keine Optimierung |
| Find Your Seat | Deutschland | 20 Gäste kostenlos | RSVP-Verwaltung, deutschsprachig |
| Hochzeit Sitzplaner | Deutschland | kostenlos | einfaches deutsches Tool |
| Ja.de Sitzordnung-Planer | 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 | 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 nötig ist (kombinatorische Explosion) — deckt sich mit unserer eigenen Begründung. Kein Web-Dienst, sondern lokale Windows/Mac-App. |
| tableplan.io | vermutlich verwandt/Web-Ableger von PerfectTablePlan | Abo-basiert | Web-Variante desselben Anbieters |
| Automated Seating | automatisierte Zuordnung | — | spezialisiert auf automatische Zuordnung |
| Social Tables / Cvent Event Diagramming | eher Enterprise-Event-Diagramming als GA-Optimierung | Enterprise/B2B | Fokus auf grosse Konferenzen/Events, nicht speziell Hochzeit |
| GitHub: 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).
- Referenz-Preistabelle von 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:
- 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.
- 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).
- 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.
- Free-Tier: bis 40 Gäste, 1 Event, Export mit Wasserzeichen. (Ersetzt die ältere "z.B. 30"-Angabe in M4.)
- Konkrete Preispunkte: bewusst noch offen. Rahmen: Einmalzahlung im Korridor ~15–45 €, ein oder zwei Stufen; Festlegung erst bei M4-Start per Test/Umfrage.
- 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.
- 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.
- 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.
- 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.
- 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
Straflisteum 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. - Produktname: Zwei-Marken-Strategie (festgelegt 2026-07-10):
- Deutschland (Hauptmarkt B2C): "Sitz & Platz" — Wortspiel mit den
Hundekommandos, kurz und merkfähig. Domains
sitzundplatz.deundsitzundplatz.comwaren zum Prüfzeitpunkt frei. - Europa/international: "Sitzwunder" / "SeatWonder" — ein Markenkern, je
Markt übersetzt. Domains
sitzwunder.de,sitzwunder.com,seatwonder.deundseatwonder.comwaren 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.
- Deutschland (Hauptmarkt B2C): "Sitz & Platz" — Wortspiel mit den
Hundekommandos, kurz und merkfähig. Domains
Meilenstein 0 — Fundament (kein neues Feature, Vorbereitung)
Ziel: Der bestehende Kern läuft stabil, testbar und ist bereit für eine API-Hülle.
- Python 2 → 3 Migration (bereits erledigt)
- Unittest-Suite mit Kernszenarien (bereits erledigt)
Farmerweitern:TopN()statt nurBester()— Grundlage für "mehrere Varianten" später. Umgesetzt inlibs/ga.py(Farm.TopN(n): dienbesten Lösungen absteigend, geclamped auf[0, len(Pool)]).- Determinismus-Option:
random.seed()als Parameter durchreichen, damit ein Ergebnis bei Bedarf reproduzierbar ist (Support-Anfragen: "warum sitzt Tante Erna da?"). Umgesetzt als--seed <int>inlibs/platz.py. Wichtig: der RNG-Seed allein reichte nicht —Personhasht imset()einerGruppesonst überid()(Speicheradresse), wodurchset.pop()-Reihenfolge inGruppe.teilen()pro Prozess variierte. Behoben durch Id-basiertes__hash__/__eq__anPerson(libs/Strukturdaten.py); Integer-Ids sind zudemPYTHONHASHSEED-unabhängig. Aufwork/hochzeitverifiziert: gleicher Seed → bytegleicher Plan, anderer Seed → abweichend. - Rechtsform geklärt: Betrieb über die bestehende MiSta GmbH (Impressum), keine Neugründung — Ausgründung aus der Holding erst bei Erfolg (Konzeptentscheidung Nr. 7)
- 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) — umgesetzt in
web/main.py, Start perbin/run_web.bat/.sh(uvicorn --reload, Port 8000), Swagger unter/docsPOST /sitzung— legt eine Arbeits-Session an (in-memory, TTL 24h)POST /sitzung/{id}/tische— Tisch-Layout als JSON (Ersatz fürtische.ini); Nachbarliste wird aus räumlicher Nähe der Koordinaten abgeleitetPOST /sitzung/{id}/personen— CSV-Upload (Ersatz fürbestellung.xml)POST /sitzung/{id}/berechnen— startet die GA-Optimierung (jeder Aufruf = neue Variante)GET /sitzung/{id}/ergebnis+GET /sitzung/{id}/ergebnis.svg— Ergebnis als JSON/SVG
- CSV-Format definiert und Parser gebaut —
libs/CSVConfig.py(Adapter analogXMLConfig): SpaltenVorname;Nachname;Titel;Gruppe;Tisch;Anzahl;Tisch= VIP- Fixplatz,Anzahl= Sammelbuchungs-Expansion, leereGruppe= Einzelgast;MagNicht/MagGernwerden akzeptiert aber noch ignoriert (Konzeptentscheidung Nr. 10) - Einfache Browser-Testoberfläche (
web/static/index.html): Tisch-Tabelle mit Presets, CSV-Textfeld/-Upload, Berechnen-Button, Kennzahlen + SVG-Anzeige — Zwischenschritt, wird durch den Konva-Tisch-Editor (unten) abgelöst - Interaktiver Tisch-Editor (Frontend): Kreise per Drag & Drop platzieren,
Kapazität einstellen (+/−/Direkteingabe), Tische hinzufügen/löschen, Nachbarschaft
live aus räumlicher Nähe abgeleitet (gleiche Radius-Logik wie
_NachbarnAbleitenim Backend, Radius per Slider). Umgesetzt alsweb/static/editor.html— buildfrei, Inline-SVG + Vanilla-JS statt React/Konva, weil das bestehende Frontend keine Build-Toolchain (npm/package.json) hat; das State-Modell ({id, plaetze, x, y}) ist dasselbe wie für eine spätere Konva-Portierung. Backend umGET /sitzung/{id}/tische(Layout-Round-Trip) ergänzt, Session wird perlocalStoragemit der Testoberfläche geteilt. Nebenbei behoben: fehlenderimport configparserinweb/main.py(der/tische-datei-Upload wäre sonst mitNameErrorabgestürzt).- Baut direkt auf
alsSVG()-Geometrie auf (Radius-Berechnung ist bereits da)
- Baut direkt auf
- Undo/Redo im Editor: Snapshot-History (Stapel je Vor-Zustand von
state.tische), ein Drag zählt als ein Schritt; TastaturStrg+Z/Strg+Y(bzw.Strg+Shift+Z),Entflöscht den ausgewählten Tisch. "Variante neu berechnen" liegt bereits als wiederholterPOST .../berechnenin der Testoberfläche vor (jeder Klick = neue Variante). - 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:POST /berechnen?varianten=N(1–5, Default 3) nimmtTopNüber den ganzen Endpool und dedupliziert über eine Sitzordnungs-Signatur (frozensetaus Tisch-Id × Personen-Ids), damit Mutations-Verwandte mit identischer Sitzordnung nicht als "Varianten" zählen. Liefert der Pool weniger unterschiedliche Sitzordnungen, kommen weniger zurück; ein weiterer Berechnen-Klick startet einen frischen Lauf. Seed-parallele Läufe für noch mehr Diversität ("ggf.") waren nicht nötig — ein Lauf liefert im Test bereits 3 paarweise verschiedene Varianten.GET /ergebnis.svg?variante=krendert jede Variante einzeln.- Vergleichsansicht im Frontend: Varianten-Karten nebeneinander mit Kennzahlen
(Wertigkeit, getrennte Gruppen + Teilungen gesamt, allein sitzende Personen —
letzteres via
LeuteAllein(), zählt nur Personen aus mehrköpfigen Gruppen ohne Gruppenmitglied am Tisch); Klick auf eine Karte schaltet Tische-/Gruppen-Tabellen und den SVG-Raumplan auf die Variante um. - Performance: Lasttest erledigt (2026-07-12) —
work/innenhoefe(300 Gäste, 88 Tische) rechnet mit dem Adaptiv-Profil (Web-Default) in ~1,7–1,9 s (5–7 Generationen, inkl. Python-Start), Easy in ~0,3 s. Beides weit unter der 5-s-Schwelle →Zyklus-Parameter-Kopplung an die Problemgröße ist nicht nötig; erst wieder prüfen, falls Zyklen deutlich vergrößert werden (siehe Risiko Nr. 2). - Optional: Hintergrund-Job-Queue (z.B. Celery/RQ), falls Berechnung >5s dauert — entfällt nach dem Lasttest (s.o.): Adaptiv bleibt bei ~2 s, der Webserver blockiert nicht spürbar. Entscheidung dokumentiert, bei Bedarf reaktivierbar.
Tech-Debt / Modernisierung (Code-Review 2026-07-11): Beim Umbau bereits erledigt sind
eval() → ast.literal_eval (bzw. ein sicherer Mini-Auswerter für die String-Ausdrücke
in zyklus.cfg) und defaultdict(set) in Plaetze. Bewusst nicht umgesetzt, für M2 zu
prüfen: GA-Kern auf DEAP umstellen (fertige
Population/Selektion/Statistik — würde das eigene Farm/Entwicklung-Gerüst ablösen und
TopN sowie die Diversitäts-Seeds quasi geschenkt liefern); SVG-Erzeugung in
Sitzplatzverteilung.alsSVG/Entwicklung.alsSVG von String-Konkatenation auf svgwrite
oder Jinja2-Templates; Container-/Datenklassen (Person, Gruppe, …) als
@dataclass. Sitzplatzverteilung.TopX bleibt bewusst handgeschrieben (die monoton
sinkende Schwelle prägt das Mutationsverhalten, siehe Kommentar im Code).
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
- 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.
- GA-Performance bei großen Sälen — erster Datenpunkt (2026-07-11): das Beispiel
work/innenhoefemit 300 Gästen an 88 Tischen rechnet mit dem Easy-Zyklus in ~0,4 s durch — weit unter der 5-s-Schwelle, ab der M2 eine Job-Queue vorsieht. Zweiter Datenpunkt (2026-07-12, M2-Lasttest): dasselbe Beispiel mit dem Adaptiv-Profil (Web-Default) braucht ~1,7–1,9 s (5–7 Generationen, 3 Seeds, inkl. Python-Start) — Job-Queue und Parameter-Kopplung bleiben unnötig. Weiter offen ist nur die Lösungsgüte-Frage: bei 4er-Tischen mit großen Gruppen (Wertigkeit ~−560) legen die vielen Trennungen nahe, dass mehr GA-Iterationen (größereGeduld/Start-Werte) bessere Pläne liefern könnten — das würde die Laufzeit dann wieder Richtung 5-s-Schwelle schieben und wäre neu zu messen. - 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-<svg> im DOM, nicht <img src="...svg"> (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 (
<Tisch>,<Buehne>,<Stuhl>), State-Changes rendern automatisch neu. - Für Drag/Resize/Rotate/Selektion nicht bei Null anfangen, sondern eine Bibliothek
nutzen: Konva/
react-konva(Canvas-basiert, bringt Drag/Resize/Rotate fertig mit) oder svg.js/interact.js (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}/tischegeschickt — direkter Ersatz für die heutigetische.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<img>. 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
Straflisteum 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) 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:
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.