The real cost of Low-Code

The real cost of low-code isn’t just licensing. It’s the time, engineering effort and accumulated complexity invested in making a platform solve a problem it was never designed to solve.

The first version is rarely the problem. Modern low-code platforms such as Microsoft Power Platform make it possible to transform business requirements into working applications in days rather than months. For the majority of internal business processes, that’s exactly what organizations need.

The real challenge begins when the application starts to outgrow the platform.

As requirements evolve, business logic becomes more sophisticated, integrations multiply, and users expect richer experiences. To keep pace, teams introduce workarounds to overcome platform limitations. One workaround becomes two, then five.

Eventually, the application still works. However, you’ve invested so much effort adapting the platform that you begin to wonder whether it’s still the right tool for the job.

The next step is often to move the complex business logic into a custom backend and expose it through APIs.

That naturally leads to another question.

If the frontend also requires rich interactions, custom UI, or advanced behaviour, why continue stretching a low-code frontend instead of building a purpose-built application?

This doesn’t mean low-code has failed. Quite the opposite. In my experience, the vast majority of internal business applications are an excellent fit for low-code. They reduce development time, enable business teams to iterate faster, and lower the operational burden on IT. When the problem aligns with the platform, few approaches deliver value as quickly or as cost-effectively.

The challenge lies in the smaller number of applications with complex workflows, advanced business rules, demanding user experiences, or high-performance requirements. These projects often consume a disproportionate amount of engineering effort, introduce architectural compromises, and become increasingly difficult to maintain over time.

The lesson isn’t about low-code versus pro-code. It’s about making better technology decisions.

Whether you’re building with low-code or writing thousands of lines of code, the engineering process should remain the same. Start by understanding the business problem, gathering and prioritising requirements, evaluating long-term risks, and designing an architecture that can evolve. Only then should you choose the technology that best fits those needs.

Before choosing a technology, don’t base the decision solely on budget, familiarity, or how quickly a prototype can be built. Invest time in understanding the problem, evaluating the long-term implications, and defining a high-level solution first. The platform should be the outcome of that process, not its starting point.

Every technology has a sweet spot. Great technology decisions come from knowing where that sweet spot begins and where it ends.

Imagine an internal application used by employees to create and manage customer orders.

The first version is straightforward. Employees select a customer, add products and quantities, submit the order, and track its status. Users are internal employees authenticated through Microsoft Entra ID, the user interface consists primarily of standard forms, and the application relies on standard platform capabilities.

Applying the decision matrix to the initial requirements could look like this:

At this stage, the application sits comfortably within the low-code sweet spot. The requirements align closely with standard platform capabilities, allowing the team to deliver quickly without introducing unnecessary architectural complexity.

The application has been successful, but the business requirements have evolved.

The organization now wants external customers to place and manage orders directly.

Customers need their own identities and should only be able to access their own products, prices, orders, and documents. Pricing has become more sophisticated, with customer-specific conditions and business rules.

Product availability and order information must be exchanged with multiple systems through APIs. Some processing now happens in the background, and the customer-facing interface requires custom components and a more tailored user experience.

Applying the same matrix again gives a different picture:

The application has moved from 8 to 26 points.

That does not mean choosing low-code for the original application was a mistake. The original requirements were a strong fit for the platform.

The requirements changed.

The higher score also does not automatically mean that the application should be rewritten. Instead, it signals that the architecture should be reassessed.

A hybrid approach might still make sense, with the low-code platform handling parts of the user experience while custom services and APIs handle more complex business logic and integrations. Alternatively, the requirements may have evolved far enough that a purpose-built application deserves consideration.

The matrix does not make the technology decision. It provides a structured way to identify when the characteristics of an application have changed enough to revisit that decision.

A good technology decision is not necessarily a permanent technology decision.