~/jonasfink.dev
← cd ..

Klientenmanagement-System für die Soziale Arbeit

2026 · Full-Stack Developer
ReactTypeScriptTailwind v4Node.jsExpress.jsAWS S3MongoDB
Klientenmanagement-System für die Soziale Arbeit — screenshotKlientenmanagement-System für die Soziale Arbeit — screenshotKlientenmanagement-System für die Soziale Arbeit — screenshotKlientenmanagement-System für die Soziale Arbeit — screenshot

Situation

In der Sozialpädagogischen Familienhilfe (SPFH) arbeiten Fachkräfte direkt mit Familien in oft komplexen Lebenslagen. Vor diesem CMS war die Dokumentation von Terminen, Berichten und Hilfeplänen stark fragmentiert. Arbeitszeiten, Termine und Fahrtzeiten wurden manuell erfasst, und der Abgleich geleisteter Stunden gegen das bewilligte Wochenkontingent jeder Familie beruhte auf fehleranfälligen Excel-Listen. Admins fehlte eine Echtzeit-Übersicht über die tatsächliche Team-Auslastung, Urlaubsüberschneidungen oder wer gerade im Dienst ist. Sensible, fallbezogene Dokumente wurden teils lokal oder über unsichere Kanäle geteilt, und es gab keine strikte, systemseitige Trennung von administrativen Rechten und den Schreibrechten der Fachkräfte auf Fallakten.

Aufgabe

Ziel war eine DSGVO-konforme, performante und intuitive Full-Stack-Plattform, die administrative Lasten minimiert und Datensicherheit garantiert. Funktional brauchte es vollwertiges Klientenmanagement inklusive Tandem-Betreuung (zwei Fachkräfte teilen sich einen Fall), lückenlose, manipulationssichere Zeiterfassung mit Überstundenberechnung sowie die automatisierte Kontingentauslastung pro Familie inklusive gerechter Verteilung von Ausfallzeiten. Technisch waren die harten Nüsse eine sichere Authentifizierung für sensible Fallakten, ein skalierbares File-Handling ohne Server-Overhead bei großen Dokumenten und durchgängige Typsicherheit, sodass API-Anfragen zur Laufzeit exakt den Backend-Typen entsprechen und diese Typen 1:1 im React-Frontend gespiegelt werden.

Umsetzung

Die Authentifizierung nutzt stateful JWTs: kurzlebige Access Tokens (15 Min, im Memory des Frontends) und 7 Tage gültige Refresh Tokens als httpOnly-Cookie, wobei in der MongoDB nur der SHA-256-Hash gespeichert wird. Eine Refresh-Token-Rotation mit Reuse Detection wertet jede Wiederverwendung eines alten Tokens als Diebstahl und widerruft sofort die gesamte Token-Familie. Express-Middlewares (protect, adminOnly) steuern nicht nur den Routenzugriff, sondern auch Field-Level Write Guards: eine Fachkraft darf die Kontaktdaten ihrer Familie ändern, nicht aber Status, Stundenkontingent oder Zuweisung. Die MongoDB-Struktur ist referenziert (User, Client, Appointment) mit Sub-Dokumenten für eng gekoppelte Daten wie die RSVP-Zusagen bei CalendarEvents. Die Business-Logik läuft über Aggregationen: die Auslastung ist progressPercent = round((totalMinutes / (weeklyHoursQuota × 60)) × 100); ausgefallene Termine werden mit pauschal 90 Minuten gutgeschrieben (gedeckelt auf 2 pro Familie/Monat) und bei Tandem-Fällen fair zu je 45 Minuten mit einem Overhead-Faktor von 1,3 aufgeteilt; Überstunden werden bei jedem Clock-out aus der ISO-Wochensumme gegen das Wochenziel neu berechnet. Das React-19-/Tailwind-v4-Frontend gibt Fachkräften personalisierte KPI-Strips und Ringdiagramme, Admins ein Live-Dashboard, wer eingestempelt ist, plus Team-Auslastungstabellen. Dokumente werden via presigned PUT-URL direkt zu S3 hochgeladen, sodass die API die Datei nie proxyt; die Metadaten werden erst nach bestätigtem Upload persistiert. Eine einzige WeekView steuert Eigen- und Teamansicht über einen colorMode-Prop, und alle Frontend-Typen spiegeln die Zod-Shapes des Backends, um inkonsistente Payloads auszuschließen.

Ergebnis

Das automatisierte Zusammenrechnen von Terminen und die integrierte Zeiterfassung ersparen pro Fachkraft mehrere Stunden manuellen Übertragungs- und Kontrollaufwand pro Woche. Admins sehen Engpässe und Kontingentüberschreitungen sofort anhand visueller Indikatoren – sich füllende Stundenringe statt überlaufender Balken – und Urlaubsanträge werden mit einer Live-Vorschau der beanspruchten Arbeitstage validiert, was Fehlplanungen minimiert. Die Kombination aus Zod-Laufzeitvalidierung, gehashter Token-Ablage, restriktivem S3-Zugriff (Download-Links verfallen nach einer Stunde) und einem lückenlosen Audit Trail bei nachträglichen Zeiterfassungs-Edits garantiert hohe Datensicherheit und Revisionssicherheit für den Träger.

Fazit & Lessons Learned

Das native Node-Ökosystem hat überzeugt: native package.json#imports für Pfad-Aliase und Node-22-Features (--watch, --env-file) haben die Developer Experience verbessert und Abhängigkeiten reduziert. Ein schlanker eigener fetch-Wrapper, der bei einem 401 transparent das Token erneuert und den Request wiederholt, erwies sich als wartbarer als Axios und hielt die Bundle-Size klein. Für stark steigende Fallzahlen wäre der nächste Schritt, die aktuell zeitgesteuerten MongoDB-Aggregationen hin zu einer Event-Driven-Architektur (z. B. via Change Streams) zu bewegen, um Überstunden- und Auslastungsmetriken asynchron im Hintergrund zu berechnen.

© 2026 Jonas Fink