From 6f99e7246ddeab2ddbd3b3bbf26755ae2396a256 Mon Sep 17 00:00:00 2001 From: Clemens Creutzburg Date: Sat, 11 Jul 2026 20:10:01 +0200 Subject: [PATCH] dokumentation erstellt --- docs/saas-umstrukturierungsplan.md | 625 +++++++++++++++++++++++++++++ 1 file changed, 625 insertions(+) create mode 100644 docs/saas-umstrukturierungsplan.md diff --git a/docs/saas-umstrukturierungsplan.md b/docs/saas-umstrukturierungsplan.md new file mode 100644 index 0000000..1ee396c --- /dev/null +++ b/docs/saas-umstrukturierungsplan.md @@ -0,0 +1,625 @@ +# SaaS-Umstrukturierungsplan Kaffeeliste + +Stand: 2026-07-11 + +Dieses Dokument beschreibt den geplanten Umbau der bestehenden Kaffeelisten-App zu +einer mehrkundenfaehigen SaaS-Anwendung mit oeffentlicher Landingpage, +Kundenregistrierung und geschuetzter App. Die bestehende Bedienlogik und das +visuelle Grunddesign sollen bewusst erhalten bleiben. + +## Zielbild + +- Mehrere Kunden koennen eigene Kaffeelisten betreiben. +- Jeder Kunde hat isolierte Daten, Einstellungen, Mitglieder und Buchungen. +- Neue Kunden koennen sich ueber eine oeffentliche Landingpage registrieren. +- Die operative App bleibt optisch nah am aktuellen Bestand: Sidebar, Tabellen, + schlichte Formulare, HTML5-UP-Anmutung. +- Authentifizierung, Rollen, Mandantenkontext und Sicherheitspruefungen werden + zentralisiert. +- Finanznahe Vorgaenge werden nachvollziehbar und revisionsfreundlich + gespeichert. + +## Nicht-Ziele fuer den ersten Umbau + +- Kein kompletter Design-Relaunch. +- Keine verspielte Marketing-App statt der bestehenden Arbeitsoberflaeche. +- Kein gleichzeitiger Neubau aller Randmodule, wenn diese fuer den MVP nicht + benoetigt werden. +- Kein Dual-Write zwischen Legacy und neuer App als Standardbetrieb. +- Keine Mandanten-ID aus Formularfeldern oder URL-Parametern als alleinige + Sicherheitsbasis. + +## Ist-Zustand + +Die aktuelle App ist eine flache PHP/sqlsrv-Legacy-App im Webroot. + +Wichtige Bereiche: + +- `index.php`: persoenliches Dashboard. +- `stricheintragen.php`: Sammelerfassung von Kaffee-Strichen. +- `einzahlung.php`: Sammelerfassung von Einzahlungen. +- `kaffeeliste.php`: Gesamtuebersicht. +- `mitarbeiterverwalten.php`: Mitglieder- und Adminpflege. +- `letzteneintraege.php`: Korrektur beziehungsweise Loeschung letzter Buchungen. +- `csvupload.php`: Zahlungsimport. +- `exportKaffeeliste.php`: PDF-/Listenexport. +- `mailversenden.php`: Massenmail. +- `hinweise.php`: Hinweise. +- `faq.php`: FAQ. + +Zentrale technische Beobachtungen: + +- Authentifizierung haengt an Windows/IIS `AUTH_USER` und LDAP. +- Die Mailadresse des Nutzers wird in `functionsLDAP.php` ermittelt. +- Rollen liegen als Boolean `admin` direkt auf `kl_Mitarbeiter`. +- Datenzugriff findet direkt in den einzelnen PHP-Seiten per `sqlsrv_query` + statt. +- Es gibt kein sichtbares Migrationssystem und kein DB-Schema im Repository. +- Fachliche Tabellen haben aktuell keinen Mandantenbezug. +- Das Design kommt vor allem aus `assets/css/main.css` und dem HTML5-UP-Layout. +- Die App-Navigation sitzt faktisch in `footer.php`; `nav.php` ist leer. + +## Grundsatzentscheidung + +Der Umbau sollte nicht mit einer rein kosmetischen Landingpage starten, sondern +mit einem stabilen SaaS-Fundament: + +1. Bestand dokumentieren und fachliche Ergebnisse einfrieren. +2. Mandantenmodell, Auth und Rollen sauber aufbauen. +3. Bestehende Fachlogik schrittweise tenant-sicher uebernehmen. +4. Landingpage und App-Shell trennen, ohne das App-Design neu zu erfinden. + +So bleibt die vertraute Kaffeelisten-Oberflaeche erhalten, waehrend die +Datenbasis und Sicherheit SaaS-faehig werden. + +## Zielarchitektur + +### Public-Bereich + +Der Public-Bereich ist ohne Login erreichbar und laedt keine Mandantendaten. + +Empfohlene Routen: + +- `/`: Landingpage. +- `/preise` oder spaeter `/pricing`: optional, falls Tarife eingefuehrt werden. +- `/faq`: oeffentliche FAQ oder FAQ-Auszug. +- `/registrieren`: Kundenregistrierung. +- `/login`: Login. +- `/passwort-vergessen`: Passwort-Reset. + +Landingpage-Inhalte: + +- Hero mit Name `Kaffeeliste` und kurzer Nutzenbeschreibung. +- Drei Kernablaeufe: Kaffee nehmen, Strich setzen, bei Bedarf bezahlen. +- Kurzer Blick auf Funktionen: Mitglieder, Guthaben, Einzahlungen, Export, + Hinweise. +- App-Screenshot oder Demo-Ansicht im bestehenden Stil. +- FAQ-Auszug. +- Call-to-Action zu Registrierung und Login. + +### Geschuetzte App + +Die geschuetzte App bleibt die operative Arbeitsoberflaeche. + +Empfohlene Routen: + +- `/app`: Dashboard oder Weiterleitung auf `/app/dashboard`. +- `/app/dashboard`: Meine Kaffeeliste. +- `/app/striche`: Eigene Striche erfassen, falls erlaubt. +- `/app/einzahlungen`: Zahlungen und PayPal-Optionen. +- `/app/mitglieder`: Mitgliederverwaltung. +- `/app/liste`: Gesamtuebersicht. +- `/app/buchungen`: Letzte Eintraege und Korrekturen. +- `/app/importe`: CSV-Importe. +- `/app/export/pdf`: PDF-/Listenexport. +- `/app/hinweise`: Hinweise. +- `/app/einstellungen`: Tenant-Einstellungen. + +Die App sollte eine Sidebar behalten, aber besser gruppiert werden: + +- Persoenlich: Meine Kaffeeliste, Namensanpassung, FAQ. +- Erfassung: Striche, Einzahlungen. +- Auswertung: Kaffeeliste, Buchungen, Export. +- Administration: Mitglieder, Hinweise, Einstellungen, Importe. + +## Datenmodell + +Empfohlen wird ein Shared-Database/Shared-Schema-Modell mit verpflichtendem +`tenant_id` auf allen fachlichen Tabellen. + +Kernschema: + +```text +tenants( + id, slug, name, status, timezone, locale, currency_code, + created_at, updated_at +) + +tenant_settings( + tenant_id, mark_price_cents, self_entry_enabled, paypal_enabled, + paypal_url_template, sheet_window_days, negative_warning_cents, + positive_highlight_cents, branding_json, updated_by_user_id +) + +users( + id, email_norm, password_hash, name, email_verified_at, + mfa_enabled, disabled_at, last_login_at, created_at, updated_at +) + +tenant_memberships( + id, tenant_id, user_id, role, status, invited_at, joined_at, + created_at, updated_at, + UNIQUE(tenant_id, user_id) +) + +participants( + id, tenant_id, user_id NULL, display_name, email_norm NULL, + paypal_name NULL, active, legacy_mitarbeiter_id, + created_at, updated_at, + UNIQUE(tenant_id, email_norm) +) + +ledger_entries( + id, tenant_id, participant_id, type, amount_cents, marks_count, + unit_price_cents, booked_at, source, note, created_by_user_id, + import_batch_id NULL, legacy_table, legacy_id, + voided_at NULL, reversal_of_entry_id NULL, + created_at +) + +notices( + id, tenant_id, message, valid_from, valid_until, + created_by_user_id, deleted_at, created_at, updated_at +) + +payment_import_batches( + id, tenant_id, original_filename, checksum, status, + created_by_user_id, created_at +) + +payment_import_rows( + id, batch_id, row_number, participant_id NULL, raw_name, + amount_cents, booked_at, status, raw_json +) + +audit_log( + id, tenant_id, actor_user_id, action, subject_type, subject_id, + metadata_json, ip, created_at +) + +outbound_emails( + id, tenant_id, participant_id, template, subject, status, + sent_at, error, created_at +) +``` + +Wichtige Modellierungsregeln: + +- `users` sind Login-Konten. +- `participants` sind Kaffee-Teilnehmer. +- Ein Teilnehmer kann, muss aber nicht, ein Login-Konto haben. +- Rollen gehoeren in `tenant_memberships`, nicht direkt auf Teilnehmer. +- Buchungen sollten nicht hart geloescht werden. +- Korrekturen laufen ueber Storno- oder Reversal-Eintraege. +- Legacy-IDs werden bei Migration gespeichert, damit Ergebnisse vergleichbar + bleiben. +- Geldwerte sollten als Cent-Integer gespeichert werden, nicht als Float. + +## Rollenmodell + +Empfohlene Rollen: + +- `owner`: Kunde verwalten, Billing, Admins, Loeschung, Grundeinstellungen. +- `admin`: Mitglieder, Hinweise, fachliche Einstellungen, Auswertungen. +- `treasurer`: Zahlungen, CSV-Import, Korrekturen, Exporte, Mails. +- `member`: eigenes Dashboard, eigene Striche, eigener Anzeigename. +- `viewer`: lesende Auswertungen. + +Alle Rollen sind tenant-scoped. Ein User kann also bei Kunde A Admin und bei +Kunde B nur Mitglied sein. + +## Authentifizierung und Sicherheit + +SaaS-Basis: + +- E-Mail/Passwort-Login mit `password_hash`. +- E-Mail-Verifikation. +- Passwort-Reset. +- Sichere Session-Cookies. +- CSRF-Schutz fuer alle schreibenden Aktionen. +- Rate-Limits fuer Login, Registrierung und Passwort-Reset. +- Zentrale Funktionen oder Middleware: `requireLogin`, `requireTenant`, + `requireRole`, `csrfToken`. + +Tenant-Aufloesung: + +- Primaer serverseitig aus Subdomain, Custom Domain oder tenantgebundener + Auswahl nach Login. +- Nicht allein aus Hidden Inputs oder frei manipulierbaren IDs. +- Jede fachliche Query braucht einen Tenant-Scope. + +Spaeter moeglich: + +- LDAP/AD oder SSO pro Kunde als optionaler Identity Provider. +- MFA fuer Owner/Admins. +- Row-Level-Security in der Datenbank. + +## Design-Leitplanken + +Das bestehende Design soll erhalten bleiben. + +Beibehalten: + +- Gruener Akzent `#38761d`. +- Weiss/Grau als ruhige Grundflaeche. +- Roboto Slab fuer Ueberschriften. +- Open Sans fuer Fliesstext. +- Sidebar fuer die geschuetzte App. +- Tabellen als primaere Darstellung fuer operative Daten. +- Schlichte Formularfelder und Buttons. + +Verbessern ohne Relaunch: + +- Hinweise als wiederverwendbare Komponente statt Inline-Style. +- Einheitliche Erfolgs-, Fehler- und Warnmeldungen. +- Dashboardwerte als kompakte Statusbereiche. +- Aktionsleisten ueber Tabellen. +- Sidebar-Gruppierung und aktive Navigation. +- FAQ strukturieren, aber Inhalte nicht stark veraendern. + +Nicht tun: + +- Kein komplett neues Farbsystem. +- Keine dekorative Marketingoptik in der App. +- Keine App-Tabellen in Kartenlandschaften aufloesen. +- Keine Navigationsstruktur, die die heutigen Kernablaeufe versteckt. + +## Meilensteinplan + +Uebersicht: + +| Meilenstein | Schwerpunkt | Hauptergebnis | +| --- | --- | --- | +| M0 | Baseline | Bestand, Sicherheit und Designreferenz sind dokumentiert | +| M1 | Golden Master | Legacy-Ergebnisse sind als Vergleichsbasis eingefroren | +| M2 | Technisches Fundament | Public-/App-Struktur, Bootstrap, Session und CSRF stehen | +| M3 | SaaS-Basis | Tenants, User, Registrierung, Login und Rollen funktionieren | +| M4 | Datenmigration | Legacy-Daten sind tenant-sicher im Zielmodell abgebildet | +| M5 | App-Kern | Dashboard, Striche, Einzahlungen, Mitglieder und Liste laufen | +| M6 | Betriebsflows | Import, Export, Mail und Jahresprozesse sind auditierbar | +| M7 | Landingpage | Werbliche Seite und Registrierung sind oeffentlich nutzbar | +| M8 | Haertung | Betrieb, Datenschutz, Monitoring und Isolation sind geprueft | +| M9 | Cutover | Produktivumstellung ist vorbereitet und Legacy ist read-only | + +### M0: Planungs- und Sicherheitsbaseline + +Ziel: +Den aktuellen Zustand verlaesslich dokumentieren, bevor umgebaut wird. + +Schritte: + +- Live-DB-Schema exportieren. +- Tabellen, Spalten, Indizes und Constraints dokumentieren. +- Bekannte Jobs/Skripte erfassen, zum Beispiel Mailversand und Jahresauswertung. +- Secrets inventarisieren und rotieren, insbesondere hart codierte Zugangsdaten. +- Bestehende Seiten und UI-Zustaende per Screenshots festhalten. +- Fachliche Kernregeln dokumentieren: Saldo, Jahreswerte, Preis pro Strich, + 100-Tage-Listen, CSV-Deduplizierung, PDF-Ausgabe. + +Ergebnis: + +- Datenkatalog. +- Prozesslandkarte. +- Designreferenz. +- Liste kritischer Sicherheitsrisiken. + +Abhaengigkeiten: + +- Zugriff auf echte oder anonymisierte Datenbank. +- Kenntnis der Produktivumgebung. + +### M1: Golden-Master-Validierung + +Ziel: +Sicherstellen, dass spaetere neue Berechnungen dieselben Ergebnisse wie der +Bestand liefern. + +Schritte: + +- Referenzdatensatz aus Legacy erzeugen. +- Pro Mitglied berechnen: Gesamteinzahlungen, Gesamtausgaben, Gesamtstriche, + aktueller Stand, Jahreswerte. +- PDF-/Export-Summen als Referenz sichern. +- CSV-Importfaelle sammeln: Treffer, Dubletten, unbekannte Namen. +- Testfaelle fuer Guthaben, Schulden, Nullsaldo und inaktive Teilnehmer + anlegen. + +Ergebnis: + +- Golden-Master-Daten. +- Vergleichsqueries oder Vergleichsskript. +- Akzeptanzkriterien fuer Migration und neue App. + +Abhaengigkeiten: + +- M0 abgeschlossen. + +### M2: Technisches Fundament + +Ziel: +Eine saubere Basis fuer App, Public-Seiten, Auth und Mandanten schaffen. + +Schritte: + +- Projektstruktur festlegen: Public-Routes, App-Routes, Views/Templates, + Services/Repositories. +- Zentrales Bootstrap fuer Config, DB-Verbindung, Session und Fehlerbehandlung. +- Layouts trennen: Public-Layout und App-Layout. +- Bestehende Assets weiterverwenden. +- CSRF- und Session-Basis einziehen. +- Konfigurationswerte aus Code in Umgebung oder Settings verschieben. + +Ergebnis: + +- Grundgeruest fuer neue SaaS-App. +- Kein fachlicher Rewrite, aber klare Struktur fuer die Migration. + +Abhaengigkeiten: + +- Entscheidung, ob PHP nativ weitergefuehrt oder ein Framework genutzt wird. + +### M3: Mandanten, Registrierung und Login + +Ziel: +Mehrkundenfaehigkeit und Kunden-Onboarding technisch aktivieren. + +Schritte: + +- Tabellen fuer `tenants`, `users`, `tenant_memberships` und + `tenant_settings` anlegen. +- Registrierung: Tenant + Owner-User + Default-Settings erzeugen. +- Login, Logout, Passwort-Reset und E-Mail-Verifikation bauen. +- Tenant-Aufloesung definieren. +- Rollenpruefung zentralisieren. +- Erste Admin-/Owner-Seite fuer Grundeinstellungen. + +Ergebnis: + +- Ein neuer Kunde kann sich registrieren und in seine eigene App gelangen. +- Rollen und Tenant-Kontext sind serverseitig verfuegbar. + +Abhaengigkeiten: + +- M2 abgeschlossen. + +### M4: Migration des fachlichen Kerns + +Ziel: +Bestehende Kaffeelisten-Daten tenant-sicher uebernehmen. + +Schritte: + +- Initialen Tenant fuer den bisherigen Bestand anlegen. +- `kl_Mitarbeiter` nach `participants` migrieren. +- `admin`-Informationen in `tenant_memberships` oder Admin-Rollen ueberfuehren. +- `kl_config` nach `tenant_settings` migrieren. +- `kl_Einzahlungen` und `kl_Kaffeeverbrauch` nach `ledger_entries` migrieren. +- Legacy-IDs speichern. +- Salden gegen Golden-Master vergleichen. + +Ergebnis: + +- Bestehender Datenbestand ist im neuen Modell abgebildet. +- Saldenparitaet ist nachweisbar. + +Abhaengigkeiten: + +- M1 und M3 abgeschlossen. + +### M5: Geschuetzte App-Funktionen + +Ziel: +Die operativen Kernseiten im neuen Modell bereitstellen. + +Schritte: + +- Dashboard `Meine Kaffeeliste` umsetzen. +- Eigene Stricherfassung umsetzen. +- Zahlungs-/PayPal-Bereich umsetzen. +- Mitgliederverwaltung tenant- und rollenbasiert umsetzen. +- Gesamtuebersicht umsetzen. +- Letzte Eintraege und Korrekturen als Storno statt Delete umsetzen. +- Hinweise als tenant-spezifische Notices umsetzen. + +Ergebnis: + +- Ein Kunde kann seine Kaffeeliste operativ nutzen. +- App sieht weiterhin nach bestehender Kaffeeliste aus. + +Abhaengigkeiten: + +- M4 abgeschlossen. + +### M6: Import, Export und Mail + +Ziel: +Admin- und Treasurer-Flows produktionsreif machen. + +Schritte: + +- CSV-Import mit Vorschau, Dublettenpruefung und Audit bauen. +- Uploads ausserhalb des Webroots speichern. +- PDF-/Listenexport aus neuem Datenmodell bauen. +- Mailversand als nachvollziehbaren Versandjob mit Dry-Run und Versandlog + gestalten. +- Jahresauswertung beziehungsweise Jahresbuchungen tenant-sicher abbilden. + +Ergebnis: + +- Kassenverwaltung ist fuer reale Betriebsablaeufe vollstaendig. +- Import/Export/Mail sind auditierbar. + +Abhaengigkeiten: + +- M5 fuer die Kernansichten. + +### M7: Oeffentliche Landingpage + +Ziel: +Werbliche Einstiegseite und Registrierung verfuegbar machen, ohne die App-Optik +zu verwischen. + +Schritte: + +- Public-Layout mit bestehender Typografie und gruenem Akzent bauen. +- Landingpage-Inhalte erstellen. +- Demo-Screenshot oder Demo-Ansicht einbinden. +- CTA zu Registrierung und Login. +- FAQ-Auszug strukturieren. +- Keine App-Sidebar im Public-Bereich. + +Ergebnis: + +- Interessenten verstehen das Produkt und koennen sich registrieren. +- Bestehende App bleibt optisch eigenstaendig und arbeitsorientiert. + +Abhaengigkeiten: + +- M3 fuer Registrierung. +- M5 fuer echte App-Screens oder Demo. + +### M8: Haertung, Datenschutz und Betrieb + +Ziel: +Die SaaS-App fuer mehrere Kunden sicher betreiben. + +Schritte: + +- Backups und Restore-Prozess definieren. +- Monitoring und Fehlerlogging einrichten. +- Audit-Log fuer Admin-Aktionen pruefen. +- Datenexport pro Tenant. +- Loesch-/Anonymisierungsprozess fuer Teilnehmer und Kunden. +- Rate-Limits und Security Headers. +- Mandanten-Isolation testen. +- Rollenmatrix testen. + +Ergebnis: + +- SaaS ist betrieblich und datenschutzseitig belastbarer. + +Abhaengigkeiten: + +- M3 bis M6. + +### M9: Cutover und Legacy-Archiv + +Ziel: +Produktive Umstellung ohne Datenverlust. + +Schritte: + +- Legacy fuer Schreibzugriffe sperren. +- Finalen Delta-Export ziehen. +- Migration ausfuehren. +- Rowcounts, Salden, PDF-Stichproben und Importhistorie pruefen. +- DNS oder Reverse Proxy umschalten. +- Legacy 30 bis 90 Tage read-only als Archiv behalten. +- Rollback-Fenster und Vorgehen dokumentieren. + +Ergebnis: + +- Neuer SaaS-Betrieb ist live. +- Alter Bestand bleibt fuer Rueckfragen lesbar. + +Abhaengigkeiten: + +- M8 abgeschlossen. + +## Empfohlene MVP-Reihenfolge + +Fuer den ersten produktnahen MVP sollten nicht alle Randmodule gleichzeitig +umgebaut werden. + +MVP-Paket: + +1. Tenant, User, Login, Registrierung. +2. Teilnehmer, Settings, Ledger. +3. Dashboard, Striche, Einzahlungen, Gesamtuebersicht. +4. Mitgliederverwaltung. +5. Hinweise. +6. CSV-Import, Export. +7. Landingpage. + +Spaeter: + +- Umfrage-Modul. +- SSO/LDAP pro Kunde. +- Billing/Tarife. +- MFA. +- Custom Domains. +- Erweiterte Mandanten-Branding-Optionen. + +## Validierung + +Fachliche Pruefungen: + +- Saldo je Teilnehmer alt gegen neu. +- Jahreswerte alt gegen neu. +- Gesamtstriche alt gegen neu. +- Einzahlungen alt gegen neu. +- Export-Summen alt gegen neu. +- CSV-Import: identische Treffer- und Dublettenlogik. + +Sicherheitspruefungen: + +- Fremde Tenant-IDs liefern keine Daten. +- Fremde Teilnehmer-IDs liefern keine Daten. +- Admin-Funktionen sind ohne Rolle blockiert. +- Alle POST-Aktionen brauchen CSRF. +- Uploads sind nicht direkt ausfuehrbar. +- Ausgabe von Namen, Mails und Hinweisen ist escaped. + +UX-Pruefungen: + +- Kernseiten bleiben optisch wiedererkennbar. +- Sidebar bleibt fuer App-Nutzer vertraut. +- Landingpage zeigt keine App-Adminnavigation. +- Mobile Darstellung bleibt bedienbar. +- Tabellen bleiben lesbar. + +## Risiken und Gegenmassnahmen + +| Risiko | Gegenmassnahme | +| --- | --- | +| Tenant-Leak durch vergessene Query-Filter | Zentrale Repository-/Query-Schicht, Tests mit zwei Tenants | +| Falsche Salden nach Migration | Golden-Master-Vergleich vor Cutover | +| Harte Deletes verlieren Audit-Historie | Storno-/Reversal-Modell fuer Buchungen | +| Login und Teilnehmer werden vermischt | `users` und `participants` strikt trennen | +| Bestehendes Design driftet weg | Designreferenz und App-Komponenten definieren | +| CSV-Upload unsicher | Upload ausserhalb Webroot, Dateityppruefung, Importvorschau | +| Mailversand nicht nachvollziehbar | Versandlog, Dry-Run, Job-Status | +| AD/LDAP blockiert SaaS-Onboarding | E-Mail/Passwort als Basis, SSO spaeter optional | +| Kein DB-Schema im Repo | Schema exportieren und Migrationen einfuehren | + +## Offene Entscheidungen + +- Soll die neue App weiterhin nativ in PHP entstehen oder mit einem Framework? +- Soll SQL Server bleiben oder mittelfristig eine andere Datenbank genutzt + werden? +- Wie sollen Kunden-Tenants adressiert werden: Subdomain, Pfad oder Auswahl nach + Login? +- Welche Rolle soll `treasurer` haben: eigene Rolle oder Teil von `admin`? +- Wird das Umfrage-Modul Teil des SaaS-Produkts oder nur archiviert? +- Braucht der MVP schon Tarife/Billing oder erstmal nur Registrierung? +- Sollen bestehende Kunden per Einladung oder per Self-Service onboarden? + +## Naechster konkreter Arbeitsschritt + +Als naechstes sollte M0 gestartet werden: + +1. Produktiv-/Testdatenbankschema exportieren. +2. Screenshot-Referenz der wichtigsten Seiten erstellen. +3. Golden-Master-Auswertungen definieren. +4. Entscheidung treffen, ob der neue SaaS-Kern im bestehenden PHP-Stil oder mit + einem Framework aufgebaut wird.