todo: SaaS-Ausbau-Plan (Instance-per-Customer + GoCardless) dokumentiert
Detaillierter Plan für späteren SaaS-Umbau festgehalten, damit wir beim nächsten Mal nicht neu planen müssen: - Architektur: Instance-per-Customer (Weg C) → keine Multi-Tenancy im Code, pro Kunde eigene Docker-Instanz + DB → Isolation statt tenantId-Filter, DSGVO-freundlich - Admin-Portal (separate App) für Provisioning, Kundenverwaltung, Billing - Abrechnung über GoCardless (SEPA + Kreditkarte), 30-Tage-Trial - Plesk-Integration nutzen, KEIN eigener Mailserver - Technische Bausteine, Provisioning-Flow, Zeitschätzung (~3-4 Wochen) Status: erstmal nur auf der Todo, nicht angefangen. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
3fa1dce2dc
commit
075c095b8e
|
|
@ -10,6 +10,91 @@
|
||||||
|
|
||||||
### Security System testen
|
### Security System testen
|
||||||
|
|
||||||
|
### 🚀 SaaS-Ausbau: Instance-per-Customer + Admin-Portal + GoCardless
|
||||||
|
|
||||||
|
**Vision:** OpenCRM als SaaS anbieten. Jeder Kunde bekommt seine eigene
|
||||||
|
isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
|
||||||
|
über ein zentrales Admin-Portal.
|
||||||
|
|
||||||
|
**Architektur-Entscheidung:** Weg C (Instance-per-Customer)
|
||||||
|
- Pro Kunde eine eigene Docker-Instanz mit eigener DB
|
||||||
|
- Keine `tenantId` im CRM-Code → keine Security-Risiken durch vergessene Filter
|
||||||
|
- Komplette Datenisolation (DSGVO-freundlich)
|
||||||
|
- Updates können gestaffelt ausgerollt werden (erst 10% testen)
|
||||||
|
- Bei Kündigung: Docker-Image + DB-Export als "Mitnehm-Paket"
|
||||||
|
|
||||||
|
**Bewusst NICHT dabei:** eigener Mailserver. Stattdessen Plesk-Integration
|
||||||
|
(die wir schon haben) – Kunde bekommt Mail-Zugang über unseren Plesk bei Bedarf.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Admin-Portal (separate App, neben den CRM-Instanzen):**
|
||||||
|
- Kundenverwaltung: wer hat welchen Plan, Status (Trial/Active/Suspended/Cancelled)
|
||||||
|
- "Neuen Kunden anlegen" → Provisioning-Script
|
||||||
|
- DB anlegen (Master-DB kennt die Mapping)
|
||||||
|
- Docker-Container starten
|
||||||
|
- Subdomain konfigurieren (`kundenname.deincrm.de` via Caddy/Traefik)
|
||||||
|
- Initial-Admin-Account erstellen + Einladungs-Email senden
|
||||||
|
- Optional: Factory-Defaults für Stammdaten einspielen
|
||||||
|
- GoCardless-Integration (Webhook + Dashboard)
|
||||||
|
- Instanz-Management: Pause/Resume bei Zahlungsproblemen
|
||||||
|
- Logs & Metriken pro Instanz (optional)
|
||||||
|
- Support-Bereich (Tickets? oder einfach E-Mail)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Abrechnung mit GoCardless (gocardless.com):**
|
||||||
|
- Zahlungsmethoden: SEPA-Lastschrift (Hauptfokus) + Kreditkarte (über GoCardless Embedded/Success)
|
||||||
|
- 30 Tage kostenlose Testphase ohne Zahlungsmittel
|
||||||
|
- Nach Trial: Mandats-Erfassung → regelmäßige Abbuchung
|
||||||
|
- Mehrere Pläne (z.B. Basic / Pro / Enterprise) mit unterschiedlichen Features
|
||||||
|
- Webhook-Endpoint im Admin-Portal:
|
||||||
|
- `payment_confirmed` → Instanz aktiv lassen
|
||||||
|
- `payment_failed` → Banner im CRM, nach X Tagen pausieren
|
||||||
|
- `mandate_cancelled` → Kündigungs-Flow
|
||||||
|
- Rechnungsstellung: GoCardless liefert Zahlungsbelege, aber **echte Rechnungen**
|
||||||
|
(mit USt-ID, Rechnungsnummer etc.) müssen wir selbst generieren
|
||||||
|
(evtl. über das existierende PDF-Template-System aus dem CRM nutzen)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Provisioning-Flow (grober Entwurf):**
|
||||||
|
1. Kunde registriert sich auf Landing Page (Name, Firma, E-Mail, Wunsch-Subdomain)
|
||||||
|
2. Admin-Portal: Trial-Instanz starten
|
||||||
|
- DB erstellen, Docker-Container hochfahren, Caddy-Config für Subdomain
|
||||||
|
- Einladungs-Email mit Admin-Login + Passwort-Reset-Link
|
||||||
|
3. Tag 25: Erinnerungs-Email "Deine Trial läuft bald ab"
|
||||||
|
4. Tag 30: Banner im CRM "Jetzt bezahlen oder pausieren"
|
||||||
|
5. Kunde erfasst GoCardless-Mandat im Admin-Portal-Login
|
||||||
|
6. Bei erfolgreicher Zahlung: Instanz bleibt aktiv
|
||||||
|
7. Bei fehlender Zahlung nach 7 Tagen: Instanz pausiert (DB bleibt, UI zeigt Hinweis)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Technische Bausteine für später:**
|
||||||
|
- Master-DB mit Tenant-Tabelle (Name, Subdomain, DB-Name, Plan, Status, GoCardlessIDs)
|
||||||
|
- Caddy oder Traefik als Reverse-Proxy mit Auto-SSL (Let's Encrypt)
|
||||||
|
- Docker-Orchestrierung: einzelne `docker-compose.yml` pro Kunde oder Docker-Swarm/K8s
|
||||||
|
- Backup-Strategie: pro Tenant separate Backups + zentrale Master-DB-Backups
|
||||||
|
- Monitoring: ein Fail macht nicht alle down, aber wir müssen es mitbekommen
|
||||||
|
- Logs zentral: z.B. Loki + Grafana für aggregierte Logs aller Instanzen
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Grobe Zeitschätzung:**
|
||||||
|
- Admin-Portal (MVP): ~1 Woche
|
||||||
|
- GoCardless-Integration + Webhooks: ~3-5 Tage
|
||||||
|
- Provisioning-Automatisierung (Docker + Caddy): ~1 Woche
|
||||||
|
- Landing Page + Checkout: ~3-5 Tage
|
||||||
|
- Tests + Polishing: ~1 Woche
|
||||||
|
- **Gesamt: ~3-4 Wochen**
|
||||||
|
|
||||||
|
**Vorbereitung JETZT (einfach, macht später Arbeit leichter):**
|
||||||
|
- ✅ Factory-Defaults System (schon erledigt, hilft beim Provisioning)
|
||||||
|
- ✅ Domain/Label dynamisch per Provider (schon erledigt)
|
||||||
|
- Docker-Compose aufräumen, Env-Variablen dokumentieren (klein, ein Tag)
|
||||||
|
- Backup-Script robust + wiederherstellbar (haben wir schon weitgehend)
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## ✅ Erledigt
|
## ✅ Erledigt
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue