When low-code stops scaling: custom portals, lower costs, better UX

As a Mendix application grows, the economics and requirements of its portal can change. External-user licensing becomes a larger expense. Customers expect a more polished experience. The team needs greater control over performance, navigation, and the pace of frontend development.

Meanwhile, the backend may still be doing exactly what the business needs. Its domain model, integrations, and business rules represent years of accumulated investment.

At Condactis, we address this situation by moving the user-facing portal to a custom web application while retaining the valuable Mendix backend. The objective is to optimize operating costs and improve UX while preserving the business capabilities already built. AI-assisted development helps reduce the effort required to make that transition.

Keep the backend investment, rebuild the portal

The approach separates the application at a practical boundary. Mendix continues to manage operational data and server-side business logic. A custom portal takes responsibility for the experience through which customers, partners, or employees use those capabilities.

The new portal can be built with React, Next.js, and TypeScript. It connects to Mendix through published REST or OData services, with a backend-for-frontend (BFF) handling the portal’s integration needs and session management.

Browser → Custom portal → BFF → Mendix APIs and business logic

This preserves the parts of the system that already work: calculations, integrations, workflows, and data structures. The migration focuses on the pages, forms, navigation, and interactions that users encounter every day.

Some behavior moves with the interface. Mendix nanoflows execute on the client, so their logic must be assessed and recreated in the appropriate layer. Server-side rules remain authoritative, and the new API paths must preserve validation and access controls. Mendix’s published REST services provide a supported way to expose entities and microflows to the custom portal.

Target costs and UX together

There are two connected sources of value in this migration.

The first is cost optimization. For a portal with a growing external audience, user-related charges can materially influence the cost of serving customers or partners. A custom portal creates an opportunity to redesign that access model. Any reduction in Mendix license costs depends on the commercial terms agreed for the resulting architecture; changing the frontend alone does not remove licensing obligations.

The second is control over the user experience. A custom frontend gives the team direct ownership of page structure, interaction design, responsive behavior, and rendering. It becomes possible to tailor the portal around the way users actually work and to evolve the interface through a dedicated frontend release cycle.

• Simpler journeys: organize navigation and forms around the user’s task, reducing unnecessary steps.
• Better performance: optimize loading, rendering, and data requests for the journeys that matter most.
• Consistent design: apply the organization’s own components, accessibility standards, and visual identity.
• Faster interface development: introduce frontend improvements while maintaining stable contracts with the Mendix backend.

These gains reinforce the investment case. The portal can become more economical to operate and easier to use, while the business retains the capabilities that make its backend valuable.

Use AI to reduce the cost of migration

Rebuilding an established portal involves substantial repetitive work: reproducing layouts, translating form behavior, implementing reusable components, and connecting pages to data. That effort has traditionally made a custom frontend difficult to justify for some applications.

Our delivery approach uses AI to accelerate this work. We derive structured specifications from the existing application, carry its design tokens into a component library, and generate initial implementations of pages and interactions. Engineers review, refine, and integrate those implementations.

This makes the existing application a concrete starting point for the rebuild. The team can reproduce familiar behavior, identify opportunities to improve it, and concentrate engineering effort on the parts that require judgment: architecture, integration, permissions, and exceptions.

The commercial benefit comes from reducing the effort needed to reach an accepted result. We establish that benefit on representative pages and workflows, including review and testing, and use the observed effort to plan the wider migration.

Migrate in three controlled stages

We structure delivery so that the portal can be evaluated before users depend on it.

1. Rebuild the experience. Recreate the agreed portal pages and journeys using mock data. Establish the component library, form behavior, and responsive layouts. This gives business stakeholders a working interface to review and a baseline against which to assess UX improvements.
2. Connect the business capabilities. Replace mock data with Mendix API calls through the BFF. Integrate authentication and verify permissions, validation, data updates, and workflow actions. Test complete journeys, including failures and retries, against the retained backend.
3. Move users to the new portal. Introduce production traffic with a defined rollout and rollback plan. Verify performance under expected load, monitor real usage, and confirm support ownership across the portal and Mendix layers.

API feasibility and identity handling are assessed early enough to inform the rebuild. The stages then provide a clear progression from a visible user experience to an integrated application and finally to production use.

Make the investment case specific

The calculation should connect the migration to the costs and outcomes it is intended to change. Start with current portal expenditure, expected audience growth, and the user journeys that most need improvement.

Compare those with the cost of the frontend rebuild, integration work, hosting, and ongoing maintenance, together with the confirmed Mendix charges for the new architecture. This establishes the net operating benefit and, where recurring savings support it, the expected payback period.

UX improvements deserve their own measures: task completion, time spent on key journeys, support demand, or conversion where relevant. Tracking these alongside costs makes it possible to assess the full result of the migration.

A focused path beyond the current portal

This approach is a strong fit when the Mendix backend remains useful and the main pressure comes from portal costs, user experience, or frontend development constraints. It also requires clear ownership of the custom code and the retained platform.

The opportunity is to invest at the layer where change produces value: give users a better portal, improve the cost of serving them, and preserve the operational logic the organization already relies on. AI-assisted delivery makes the work of getting there more efficient.