When low-code stops scaling: Mendix frontends, custom code, and AI-augmented delivery

The inflection point

Low-code platforms like Mendix solve a real problem. They let organizations ship business applications fast, with smaller teams, and with governance built in. For internal tools and moderate-scale portals, the value proposition holds.

But there is an inflection point. It tends to arrive when one or more of these conditions appear: external user license costs become a significant line item, frontend UX requirements exceed what the platform's widget system can deliver, or the organization needs full control over the user experience - performance, accessibility, SEO, progressive enhancement - without being constrained by the platform's rendering engine.

At that point, the conventional wisdom says you have two options: stay and accept the limitations, or rewrite everything from scratch. Both are expensive. Both carry risk.

There is a third option.

Keep the engine, replace the cockpit

The approach we've developed treats Mendix as what it actually is underneath the visual layer: a capable application server with a domain model, business logic, and API surface. The platform's runtime exposes OData and REST services. Microflows and nanoflows encode years of accumulated business rules. The database holds the operational data.

None of that needs to change.

What changes is the frontend. Instead of the Mendix client rendering pages from the platform's widget tree, a standalone web application - built with React, Next.js, and TypeScript - handles the user interface. It communicates with Mendix through a thin Backend-for-Frontend (BFF) layer that proxies API calls and manages session state.

The architecture is straightforward:

Browser → Next.js application → BFF proxy layer → Mendix Runtime (OData + REST + Auth)

Business logic stays in Mendix. Validation stays in Mendix. Workflows, calculations, access control - all Mendix. The frontend is responsible for rendering, navigation, and user interaction. The BFF is responsible for authentication and request forwarding. Nothing else.

This separation preserves your entire investment in the platform's backend while giving you full control over the user experience.

Why this works now: AI-augmented development

The economics of this migration pattern have always been difficult. A Mendix application with 40-50 pages, complex form wizards, conditional visibility, data grids, and multi-step workflows represents months of frontend development work if rebuilt manually. For many organizations, the cost of the rebuild exceeded the savings from eliminating licenses - at least in the short term.

AI-augmented development changes the math.

We use AI as an engineering accelerator at multiple stages of the migration. Structured specifications extracted from the source application are used to generate initial React component scaffolding. Design tokens are derived programmatically from the platform's theme system and applied to a component library. Page-by-page, the AI generates a first draft that matches the existing UI, which engineers then review, refine, and integrate.

This is not "AI writes the whole app." It is a disciplined workflow where AI handles the high-volume, pattern-based work - layout replication, component wiring, mock data setup - while engineers focus on architecture decisions, edge cases, integration logic, and quality. The result is a 3-5x acceleration in frontend delivery compared to a purely manual rebuild.

The phased approach

We deliver this migration in three phases that reduce risk at every stage.

Phase one produces a complete visual replica of the existing portal using mock data. Every page, every layout, every form - rebuilt in React with the same structure and appearance as the Mendix original. This phase validates the UI layer in isolation, without touching production systems.

Phase two connects the frontend to Mendix through the BFF layer. Mock data is replaced with real API calls. Authentication is wired to the platform's auth endpoint. This is where integration testing happens - confirming that every data flow, every action, every conditional behavior works end-to-end.

Phase three is cutover. User migration, DNS routing, production monitoring. By this point, the application has been validated visually, functionally, and under load.

The economics

The numbers on a typical engagement look like this. An organization with 1,500-2,000 external users on Mendix is paying a substantial annual license fee for those user seats. The migration project - frontend rebuild plus BFF plus integration testing - pays for itself within 12-18 months through eliminated license costs alone. After that, the savings compound.

But cost elimination is only half the story. The custom frontend unlocks capabilities that the platform couldn't deliver: sub-second page loads, full accessibility compliance, progressive web app support, and a development velocity on the frontend that isn't gated by the platform's release cycle.

When this is - and isn't - the right move

This pattern works when Mendix is doing valuable work on the backend and you want to preserve that investment. It works when external user volume makes per-seat licensing economically untenable. It works when your UX requirements have outgrown the platform's widget system.

It does not work when the business logic itself needs to be replaced. It does not work when the Mendix domain model is the problem. And it does not work when the organization isn't prepared to maintain a custom frontend codebase alongside a Mendix backend.

We're selective about when we recommend this approach. But when the conditions are right, it's the most capital-efficient path from low-code constraints to full frontend control - without throwing away the years of work embedded in your platform.