Als kleines Team aus drei Entwicklern, haben wir eine interne Zeiterfassungs-App entwickelt. Ziel war ein stabiles internes Tool, das sich sauber in unsere Systemlandschaft integriert und langfristig wartbar bleibt.

Da unser Unternehmen stark in Microsoft 365 integriert ist, haben wir uns für unsere – bis dato – aktuelle Zeiterfassung für Power Apps entschieden. Rückblickend war diese Entscheidung naheliegend – aber nicht effizient.

Warum Power Apps für uns zunächst sinnvoll war

Auf dem Papier bietet Power Apps viele Vorteile für Microsoft-365-nahe Organisationen. Azure Active Directory, Outlook, Teams und SharePoint sind direkt angebunden. Authentifizierung, Benutzerverwaltung und Rollenmodelle sind vorhanden und müssen nicht neu entworfen werden.

Genau diese Punkte haben uns überzeugt. Die Plattform versprach einen schnellen Einstieg, wenig Infrastrukturaufwand und eine niedrige Einstiegshürde – insbesondere für interne Anwendungen.

In der Praxis sah das jedoch anders aus.

Die Realität: Ein Jahr Einarbeitung in eine Low-Code-Welt

Die Entwicklung der Zeiterfassung in Power Apps war kein schneller Start.
Im Gegenteil: Es hat uns knapp ein Jahr gekostet, um die Plattform richtig zu entwickeln.

Der größte Zeitfaktor war nicht die fachliche Komplexität, sondern die Einarbeitung in:

die Denkweise von Power Apps,
die Limitierungen der Formeln und Komponenten,
die Eigenheiten von Power Automate,
und das Zusammenspiel der verschiedenen Microsoft-Werkzeuge.

Da man nicht direkt im Code arbeitet, sondern über die von Microsoft vorgegebenen Werkzeuge, Patterns und Abstraktionen, ist man stark eingeschränkt. Viele Dinge, die in klassischem Code trivial sind, lassen sich nur über Umwege oder gar nicht umsetzen.

Ein großer Teil der Entwicklungszeit floss nicht in fachliche Logik, sondern in das Verstehen und Umgehen der Plattformmechanismen.

Wenn Low-Code zum strukturellen Problem wird

Die Performance-Probleme von Power Apps waren kein schleichender Effekt, sondern von Beginn an vorhanden. Bereits beim Öffnen der Anwendung dauerte es spürbar lange, bis alle notwendigen Operationen, Abhängigkeiten und Initialisierungen geladen waren. Dieses Verhalten war unabhängig von Datenmenge oder Nutzung und zeigte klar die fehlende Effizienz des Frameworks.

Optimierung war kaum möglich, da wesentliche Abläufe außerhalb unseres Einflussbereichs lagen. Zusätzlich verschärften systemische Eigenheiten wie das automatische Deaktivieren inaktiver Power-Automate-Flows die Situation. Um produktive Prozesse stabil zu halten, mussten technische Workarounds implementiert werden, ohne fachlichen Mehrwert.

An diesem Punkt wurde deutlich: Unsere Entwicklungsarbeit richtete sich nicht mehr nach fachlichen Anforderungen, sondern nach Plattformgrenzen.

Der Vergleich: Drei Monate Django statt ein Jahr Power Apps

Der Wechsel war kein Experiment, sondern eine bewusste Entscheidung.
Wir haben die Zeiterfassung neu aufgebaut – dieses Mal mit Django in Python.

Die eigentliche Entwicklung der neuen Plattform dauerte rund drei Monate.

Trotz vollständiger Neuentwicklung waren wir deutlich schneller als mit Power Apps. Der Grund war einfach: Wir konnten wieder direkt im Code arbeiten. Architektur, Datenmodelle, Geschäftslogik und Performance lagen vollständig in unserer Hand.

Wir setzen dabei auf Prompt Driven Development als Produktivitätsverstärker. KI-gestützte Prompts unterstützen uns bei Standardlogik, Tests, Refactorings und Modellierung. Die technische Verantwortung bleibt jedoch klar beim Entwicklungsteam.

Die bestehende Power-App wurde nicht abrupt abgeschaltet. Die relevanten Daten wurden über Dataflows aus der Power-Apps-Welt entkoppelt und in eine eigenständige Datenbasis überführt. So konnten wir schrittweise migrieren, ohne den laufenden Betrieb zu gefährden.

Dieser Ansatz ermöglichte uns, die neue Plattform parallel aufzubauen und sukzessive zu übernehmen.

Microsoft-Integration ohne Low-Code

Mit dem Wechsel entfiel die implizite Microsoft-Integration von Power Apps. Authentifizierung, Benutzer-Synchronisation und Berechtigungen mussten explizit umgesetzt werden – etwa über Azure AD, OAuth und Microsoft Graph.

In der Praxis erwies sich dieser Aufwand als überschaubar und gut kontrollierbar. Statt impliziter Plattformlogik gibt es nun explizite Schnittstellen, klare Konfigurationen und nachvollziehbares Verhalten. Die Integration ist nicht schwieriger – sie ist transparenter und besser testbar.

Fazit: Low-Code kostet Zeit – klassischer Code spart sie

Power Apps hat uns keinen schnellen Start ermöglicht. Die Plattform erforderte eine lange Einarbeitung und zwang uns, in den Grenzen ihrer Werkzeuge zu denken.

Die Django-basierte Neuentwicklung war dagegen deutlich schneller, obwohl sie vollständig neu implementiert wurde. Direkter Code, klare Architektur und volle Kontrolle über das System haben sich als effizienter erwiesen als jede Low-Code-Abstraktion.

Heute entwickeln wir zielgerichteter, stabiler und nachhaltiger.
Unsere Zeiterfassung tut wieder das, was sie soll:
Zeit erfassen – nicht verbrauchen.