Initial Kaffeekasse SaaS restart

docs/marketing-ops.md

@@ -0,0 +1,51 @@
+# Marketing-Operations
+
+## Ziel
+
+Der Produktauftritt soll nicht nur schoen aussehen, sondern einen messbaren
+Pfad von `Interesse` zu `aktivem Tenant` schaffen.
+
+## Funnel-Stufen
+
+1. `Landing Visit`
+2. `CTA Klick auf Registrierung`
+3. `Tenant registriert`
+4. `Erster Login`
+5. `Erste Buchung`
+6. `Erste Papierliste oder erstes RFID-Setup`
+
+## Tracking-Ereignisse
+
+- `landing_view`
+- `pricing_view`
+- `register_started`
+- `tenant_registered`
+- `tenant_login_success`
+- `first_consumption_recorded`
+- `paper_sheet_created`
+- `rfid_device_created`
+
+## Tooling-Empfehlung
+
+- datenschutzfreundliches Web-Analytics statt schwerem Adtech-Setup
+- Formular-Events serverseitig oder ueber schlankes Frontend-Tracking mitschreiben
+- CRM-Anbindung zunaechst ueber CSV-Export oder Webhook-Fassade
+- spaeter: automatisch segmentierte Onboarding-Mails pro Paket
+
+## Operative Fragen fuer den Go-Live
+
+- Welche CTA-Version konvertiert fuer Vereine besser: `Digitale Strichliste` oder
+  `Kaffeekasse digitalisieren`?
+- Wie viele registrierte Tenants legen binnen 24 Stunden Mitglieder und Produkte
+  an?
+- Wo brechen Interessenten ab: auf der Landingpage, im Signup oder erst beim
+  Login?
+
+## Direkt im Produkt nutzbar
+
+Die Landingpage im Repo ist bereits auf diese Funnel-Logik abgestimmt:
+
+- klares Problem-Narrativ
+- Paketdarstellung
+- direkter CTA zur Registrierung
+- technischer Vertrauensaufbau ueber Netcup-, Papier- und RFID-Kompatibilitaet

docs/product-strategy.md

@@ -0,0 +1,48 @@
+# Produkt- und Vermarktungsstrategie
+
+## Zielgruppen
+
+- kleine und mittlere Teams mit gemeinsamer Kaffeekasse
+- Vereine mit klassischer Strichliste
+- Coworking- und Mehrraum-Standorte mit spaeterer RFID-Option
+
+## Kernbotschaft
+
+`Eine Kaffeekasse fuer analog und digital.`  
+Die Anwendung ersetzt Papier nicht abrupt, sondern verbindet Papierliste,
+digitale Selbstbedienung und spaetere Geraeteanbindung in einem nachvollziehbaren
+Buchungssystem.
+
+## Positionierung
+
+- weniger Tool-Fragmentierung als Eigenbau aus Excel, Zetteln und Einzelapps
+- verstaendlichere Einfuehrung als reine Hardware- oder RFID-Produkte
+- realistischer Betrieb auf klassischem Webhosting statt VPS-Pflicht
+
+## Paketlogik
+
+- `Starter`: digitale Buchungen, Mitglieder, Produkte, Einzahlungen
+- `Team`: zusaetzlich Papierlisten-Workflow und staerkeres Backoffice
+- `Business`: RFID-Roadmap, Betriebshooks, White-Label-/Integrationsvorstufe
+
+## Marketing-Funnel
+
+1. Landingpage erklaert den analogen und digitalen Use Case in einem Satz.
+2. CTA fuehrt direkt in Mandanten-Registrierung oder Demo-Setup.
+3. Der Self-Service legt sofort einen nutzbaren Tenant mit Default-Produkten an.
+4. Plattform-Admin kann spaeter Vertrieb, Support und Paketwechsel steuern.
+
+## Messaging-Elemente
+
+- `Digitale Strichliste fuer Teams und Vereine`
+- `Papierliste bleibt moeglich`
+- `RFID spaeter anschliessen, ohne neu zu bauen`
+- `Nachvollziehbare Salden und Buchungsverlaeufe`
+
+## Vertriebsnahe KPIs
+
+- Registrierungen pro Paket
+- Anteil aktivierter Tenants
+- erste Buchung innerhalb von 24 Stunden
+- Anteil Tenants mit aktiver Papierlisten-Nutzung
+- Nachfrage nach RFID-/Standortintegration

docs/production-blueprint.md

@@ -0,0 +1,37 @@
+# Produktions-Blueprint
+
+## Architektur
+
+- modularer Monolith in PHP
+- gemeinsame MySQL-Datenbank mit `tenant_id`
+- Frontcontroller unter `public/index.php`
+- Services fuer Setup, Registrierung, Ledger und RFID
+
+## Sicherheitsgrundlagen
+
+- serverseitige PHP-Sessions
+- CSRF-Schutz fuer alle schreibenden Formulare
+- `password_hash()` mit moderner Hash-Funktion
+- Audit-Log fuer Login, Registrierung, Buchungen und RFID-Ereignisse
+- path-basierte Tenant-Isolation ueber Memberships
+
+## Betriebsmodell
+
+- Installation per Browser oder `bin/migrate.php`
+- Cron-basierte technische Haken ueber `bin/cron.php`
+- Healthcheck als JSON ueber `bin/healthcheck.php`
+- Release-Pakete ueber `scripts/build-release.sh`
+
+## Was vor echtem Go-Live noch folgen sollte
+
+- Mail-Verifikation und Passwort-Reset-Flow
+- MFA fuer Admin- und Owner-Rollen
+- Login- und Registrierungs-Rate-Limits
+- strukturiertes Logging in Datei oder externem Ziel
+- abgesicherter Support-Zugriff fuer Plattform-Admins
+
+## Git- und CI-Gedanke
+
+Das Repo ist absichtlich neutral gehalten, damit spaeter auf `git.ctb-it.de`
+entweder GitLab- oder Gitea-CI angedockt werden kann. Die eigentliche
+Deploy-Logik steckt in Skripten und Doku, nicht in einem proprietaeren CI-Format.

docs/rfid-roadmap.md

@@ -0,0 +1,28 @@
+# RFID-Roadmap
+
+## Heute schon vorhanden
+
+- `rfid_devices` fuer Standortgeraete
+- `rfid_tags` fuer Karten/Chips pro Mitglied
+- `rfid_events` als technische Inbox
+- `/api/rfid/intake` fuer rohe Events
+
+## Warum das sinnvoll ist
+
+Die spaetere Hardware kann kommen, ohne dass sich das Kernmodell fuer Salden,
+Konsum und Einzahlungen aendert. RFID ist nur ein weiterer Erfassungsweg in
+dieselbe Buchungslogik hinein.
+
+## Nächste Ausbaustufen
+
+1. Geraet aktivieren und Token-Rotation einfuehren
+2. Dublettenschutz ueber `event_id` und Zeitfenster haerten
+3. Mapping-Regeln `Tag -> Mitglied -> Standardprodukt`
+4. optionale Freigabe- oder Double-Tap-Regeln
+5. Uebernahme von `rfid_events` in echte `consumption_events`
+
+## Produktionshinweis
+
+Wenn spaeter mehr als HTTPS-Webhooks noetig werden, sollte ein kleiner externer
+Relay-Service zwischen Lesegerät und Webspace geschaltet werden. Das eigentliche
+SaaS-Ledger kann trotzdem auf Netcup-Webspace bleiben.