Bericht · Auszug
1. Management Summary
Für den aktuellen Status «Prototyp» ist die App sauber und durchdacht umgesetzt – Datenmodell, Backup-Konzept und Grundsicherung sind gut. Für eine Handvoll Pilotkunden ist die Basis in Reichweite. Für hunderte Firmenkunden fehlt aber nicht in erster Linie Server-Leistung, sondern ein Fundament, das bereit ist für Weiterentwicklung, Skalierung und Überwachung.
| Bereich | Status | Kurzeinschätzung |
|---|---|---|
| Sicherheit (Login/Session) | dringend | Solides Grundgerüst, einige Lücken für den Mehrbenutzer-Betrieb |
| Architektur / Skalierbarkeit | dringend | Monolith (ein Prozess, ein Server); Ziel-Architektur empfohlen |
| Code-Qualität | wichtig | Gut kommentiert, aber stark gebündelt und ohne Tests |
| Betrieb / Deployment | OK | Überdurchschnittlich gut für diesen Reifegrad |
| Kommerzialisierung | wichtig | Kein Firmen-Account- und Abrechnungsmodell |
| Datenschutz (DSG/DSGVO) | wichtig | Keine dokumentierten Prozesse gefunden |
2. Befunde (Auszug Sicherheit)
Positiv
- Passwörter mit modernem, langsamem Hash-Verfahren; alte Hashes werden beim nächsten Login automatisch migriert.
- Session-Cookies korrekt gesetzt (HttpOnly, SameSite, Secure).
- Brute-Force-Schutz: Sperre nach mehreren Fehlversuchen.
- Sicherheits-Header (HSTS, CSP u. a.) sauber konfiguriert – über dem, was man bei Solo-Projekten sonst sieht.
- Durchgängig parametrisierte Datenbankabfragen; keine SQL-Injection gefunden.
Befunde
- Mittel
Sessions und Rate-Limits nur im Arbeitsspeicher
Jeder Neustart meldet alle Nutzer ab, die Strukturen wachsen bei Angriffen unbegrenzt, und ein zweiter Server-Prozess hätte eigene, inkonsistente Sessions.
- Mittel
Kein CSRF-Token
Zustandsändernde Aktionen verlassen sich allein auf SameSite-Cookies. Für Admin-Aktionen ist ein expliziter Token robuster.
- Niedrig
Standard-Zugangsdaten im Code
Ein Fallback-Benutzer mit Passwort steht im Quellcode. In Produktion zwar übersteuert, aber vermeidbar.
- Niedrig
Kein Self-Service-Passwort-Reset
Zugänge laufen nur über Einladungen des Admins – mit mehr Kunden wird das zur Support-Last.
3. Skalierbarkeit: nicht mehr Server, sondern das richtige Modell
Technisch reicht die heutige Architektur für die ersten Dutzend Kunden. SQLite ist dabei kurzfristig nicht der Engpass – bei einer überwiegend lesenden Anwendung ist es pragmatisch. Die echte Grenze sollte per Lasttest ermittelt werden, nicht aus der Anzahl Accounts abgeleitet.
Der eigentliche Blocker ist das Datenmodell: Das System kennt einzelne Logins, aber keine Firma, der mehrere Benutzer, Rollen, Lizenzen und ein Abo-Status gehören. Die nächste Stufe braucht also zuerst ein belastbares B2B-Account-Modell – nicht mehr Server.
4. Ziel-Architektur: kontrolliert modularisieren statt neu bauen
| Baustein | Heute | Ziel |
|---|---|---|
| Backend | Ein Prozess ohne Framework; Routing, Login, Geschäftslogik und Datenzugriff in einer Datei | Modulares API-Backend (z. B. FastAPI) mit getrennten, testbaren Modulen |
| Datenbank | SQLite-Datei auf dem Server; Schemaänderungen direkt aus dem Code | PostgreSQL mit versionierten Migrationen |
| Frontend | Eine sehr grosse HTML-Datei mit eingebettetem JavaScript | Komponentenbasiertes Frontend, das Daten nur über die API bezieht |
| Betrieb | Ein Server, Backup auf derselben Maschine, kein Monitoring | Externes Backup, getesteter Restore, Monitoring und Alarmierung |
Die fachlich wertvolle Logik wird zuerst mit Tests abgesichert und dann schrittweise übernommen – Refactoring der Struktur, kein Rewrite der Fachlogik.
5. Priorisierte Roadmap
Vor dem ersten zahlenden Firmenkunden (Muss)
- Rechte an Drittdaten und Lizenzen für den kommerziellen Einsatz klären
- Einfaches Firmen-Account-Modell einführen (Organisation mit mehreren Benutzern)
- Basis-Monitoring und Alarmierung für Erreichbarkeit, Importe, Backups und Fehler
- Backup ausserhalb des Produktionsservers und Restore praktisch testen
- Datenschutz und Datenlebenszyklus dokumentieren (inkl. Daten an externe KI-Dienste)
- Kritische Fachlogik mit Regressionstests absichern
Vor der Skalierung (Sollte)
- Account- und Abo-Modell vervollständigen (Rollen, Sitzplätze, Kündigung, Sperre)
- Zahlung und Abrechnung automatisieren
- Backend modularisieren und API etablieren
- Sessions und Rate-Limits in Datenbank oder zentralen Store verlegen
- Auf PostgreSQL migrieren, Frontend schrittweise modularisieren, CI und Lasttests einführen
6. Fazit
Eine gute technische Ausgangsbasis für die nächste Produktphase, aber noch keine vollständig skalierbare B2B-Plattform. Der Weg dorthin erfordert mehrere gezielte Erweiterungen – jedoch keinen Neustart.