As a small team of three developers, we developed an internal time tracking app. The goal was to create a stable internal tool that would integrate seamlessly into our system landscape and remain maintainable in the long term.

Since our company is heavily integrated with Microsoft 365, we opted for our current time tracking solution for Power Apps. In retrospect, this decision was obvious – but not efficient.

Why Power Apps made sense for us initially

On paper, Power Apps offers many advantages for organisations that use Microsoft 365. Azure Active Directory, Outlook, Teams and SharePoint are directly connected. Authentication, user management and role models are already in place and do not need to be redesigned.

These are precisely the points that convinced us. The platform promised a quick start, low infrastructure costs and a low barrier to entry – especially for internal applications.

In practice, however, things turned out differently.

The reality: a year of familiarisation with a low-code world

The development of time tracking in Power Apps was not a quick start.
On the contrary, it took us almost a year to develop the platform properly.

The biggest time factor was not the technical complexity, but familiarising ourselves with:

the mindset of Power Apps,
the limitations of formulas and components,
the peculiarities of Power Automate,
and the interaction of the various Microsoft tools.

Since you don’t work directly in the code, but rather with the tools, patterns, and abstractions provided by Microsoft, you are severely limited. Many things that are trivial in classic code can only be implemented indirectly or not at all.

A large part of the development time was spent not on technical logic, but on understanding and working around the platform mechanisms.

When low-code becomes a structural problem

The performance issues with Power Apps were not a gradual effect, but were present from the outset. Even when opening the application, it took a noticeably long time for all the necessary operations, dependencies and initialisations to load. This behaviour was independent of data volume or usage and clearly demonstrated the framework’s lack of efficiency.

Optimisation was hardly possible, as essential processes were beyond our control. In addition, systemic peculiarities such as the automatic deactivation of inactive Power Automate flows exacerbated the situation. In order to keep productive processes stable, technical workarounds had to be implemented without any added value.

At this point, it became clear that our development work was no longer based on technical requirements, but on platform limitations.

The comparison: three months of Django instead of a year of Power Apps

The switch was not an experiment, but a conscious decision.
We rebuilt the time tracking system – this time with Django in Python.

The actual development of the new platform took around three months.

Despite being a completely new development, we were significantly faster than with Power Apps. The reason was simple: we were able to work directly in the code again. Architecture, data models, business logic and performance were entirely in our hands.

We rely on prompt-driven development to boost productivity. AI-supported prompts assist us with standard logic, testing, refactoring and modelling. However, technical responsibility remains clearly with the development team.

The existing Power App was not abruptly shut down. The relevant data was decoupled from the Power Apps world via data flows and transferred to a separate database. This allowed us to migrate step by step without jeopardising ongoing operations.

This approach enabled us to build the new platform in parallel and gradually take it over.

Microsoft integration without low code

The change meant that Power Apps’ implicit Microsoft integration was no longer available. Authentication, user synchronisation and permissions had to be implemented explicitly – for example, via Azure AD, OAuth and Microsoft Graph.

In practice, this effort proved to be manageable and easily controllable. Instead of implicit platform logic, there are now explicit interfaces, clear configurations and traceable behaviour. Integration is no more difficult – it is more transparent and easier to test.

Conclusion: Low-code costs time – classic code saves it

Power Apps did not enable us to get started quickly. The platform required a long training period and forced us to think within the limits of its tools.

The Django-based redevelopment, on the other hand, was significantly faster, even though it was completely reimplemented. Direct code, clear architecture and full control over the system proved to be more efficient than any low-code abstraction.

Today, our development is more targeted, stable and sustainable.
Our time tracking system is back to doing what it’s supposed to do:
tracking time – not consuming it.