REST-API und HR-Frontend für ein internes Tools-Portal

Wie das Projekt gelaufen ist

Ein Münchner Startup baute ein internes Tools-Portal für eine HR-nahe Anwendung. Der Auftrag lag in zwei Schichten: eine sauber geschnittene REST-API für Auth und HR-Domain-Endpoints, und ein dispositions-orientiertes Frontend mit Kalender, Filter und Check-In-Workflows. Die Aufgabe sollte fertig geliefert werden, nicht permanent gepflegt.

API-First, dann das Frontend obendrauf

Die Reihenfolge war entscheidend: Erst standen die REST-Endpoints, dann setzten die Frontends darauf auf. Auth-Endpoints (Login, Token-Refresh, Rollen-Checks) sauber getrennt von der HR-Domäne (Mitarbeiter, Schichten, Verfügbarkeiten, Buchungen). Versioniert über URL-Präfix, dokumentiert mit OpenAPI, getestet auf Endpoint-Ebene. Das interne Team konnte später eigene Clients ansprechen, ohne sich mit Implementierungs-Details herumzuschlagen.

Diese Reihenfolge schützt vor einer typischen Falle in HR-Anwendungen: Wenn das Frontend zuerst entsteht und die API dahinter Stück für Stück nachgezogen wird, wachsen die Endpoints schief, weil sie der UI-Logik folgen statt der Domäne. Wir haben die Domain-Begriffe sauber durchdacht, in API-Verträgen festgehalten, und erst dann die Bildschirme dazu gebaut.

HR-Frontend mit Kalender, Filter und Check-In-Logik

Das Backoffice-Frontend zeigte einen Wochen-/Monatskalender mit filterbaren Mitarbeitern, Anwesenheits- und Verfügbarkeits-Markierungen. Buchungen, Stornierungen und Check-In-/Check-Out-Logik liefen ohne Page-Reload, mit klaren Status-Übergängen. Das Portal-Frontend für externe Mitarbeiter war schlanker, hatte aber dieselben Auth-Endpoints im Hintergrund.

Die Dispositions-Logik wuchs schrittweise: zuerst der reine Kalender mit Mitarbeiter-Spalten, dann Filter und Sortierungen, später die Buchungs-Flows und am Ende die Check-In-/Check-Out-Sequenzen. Diese inkrementelle Reihenfolge war kein Zufall - sie ist die natürliche Lese-Reihenfolge der Domain. Wenn Sie Tabellen-Ansichten und Buchungen vor dem Kalender bauen, kommen Sie am Domänen-Modell vorbei und ringen später mit halben Begriffen.

Zwei Frontends, eine Auth-Schicht

Das Backoffice-Frontend für die internen Disponenten und das Portal-Frontend für die externen Mitarbeiter sahen unterschiedlich aus und hatten unterschiedliche Funktions-Tiefe. Beide gingen aber durch dieselbe Auth-Schicht, dieselben Token-Refresh-Mechaniken, dieselben Rollen-Checks. Ein Bug an der Anmeldung war an einer Stelle zu fixen, nicht an zweien.

Diese Auth-Konsolidierung hat sich am Ende doppelt ausgezahlt: einmal bei der Übergabe, weil das interne Team nur ein Modell verstehen musste; einmal bei späteren Erweiterungen, weil eine neue Rolle oder ein zusätzlicher Endpunkt-Schutz an genau einer Stelle eingehängt werden konnte.

Liefer-Cut nach rund zehn Monaten

Nach rund zehn Monaten war die Funktions-Tiefe erreicht, die das Startup für seinen Live-Betrieb brauchte. Die Übergabe an das interne Team war kompakt: API-Doku, Test-Suite, Architecture Decision Records für die größeren Entscheidungen. Wir blieben Ansprechpartner für punktuelle Erweiterungen, ohne weitere Vollzeit-Bindung.

Diese Art Werkvertrags-Phase passt zu Greenfield-Projekten in Startups: Ein klar umrissenes Modul wird in einer definierten Zeit gebaut und dann in die interne Pflege übergeben. Das vermeidet die Dauer-Abhängigkeit, die einer skalierenden Engineering-Mannschaft im Weg steht, und gibt dem externen Lieferanten gleichzeitig die Liefer-Tiefe, um Architektur-Entscheidungen vernünftig zu treffen.