Low-code vs custom: when Mendix, OutSystems or Power Apps are no longer enough
Low-code platforms deliver speed where it matters: a first working version of an internal application within weeks, a citizen developer setting up a form flow themselves, a proof of concept for a process that isn't yet fully defined. Until the point where it starts to chafe: performance drops under user load, your domain model no longer fits the platform's rigid framework, or your licence renewal quote reveals that runtime costs have doubled. This article describes honestly where low-code works, where it breaks down, and which route you have towards custom development without throwing everything away.
Discuss your low-code project Explore the limitsWhen low-code stops scaling: the limits of Mendix, OutSystems and Power Apps
Low-code is not a bad thing. For an internal approval flow, a form-driven back-office tool or a proof of concept to validate a process, it is often the quickest route. But every platform has a built-in ceiling, and the further your organisation grows, the sooner you hit it.
The pattern we see among IT leads and CTOs who contact us is a familiar one: a team started with Microsoft Power Apps for a simple request workflow, or with Mendix Studio Pro for a customer portal, or with OutSystems Service Studio for a mobile app. For the first two years, everything runs smoothly. The business is enthusiastic and the platform delivers. Then comes the third year: user numbers double, an external API needs to be integrated, the domain model becomes more complex than the platform comfortably supports, and renewing the runtime licence turns out to be considerably more expensive than budgeted.
That is not a failure of low-code. It is the design of low-code: speed and accessibility in exchange for abstraction and platform dependency. The question is not whether low-code is "good or bad", but whether it is still the right choice for your specific use case, and what you do if the answer becomes no.
What low-code does well
Before describing the limits, low-code platforms deserve credit for what they genuinely solve. Here are three scenarios in which Mendix, OutSystems or Power Apps are simply the right choice.
Rapid MVP for internal tooling
A department has a recurring process currently run in Excel or email, such as expense claims, holiday requests or asset tracking. A Power App or Mendix application can deliver a working version within weeks. The business can validate whether the process works at all before you invest in custom development.
Citizen developer empowerment
Power Platform is designed to let people without a development background build a working solution. For forms, simple workflows and dashboards on existing SharePoint or Dataverse data, it is powerful. IT is relieved of small requests, and citizen developers deliver their own solutions.
Simple workflows and forms
A form is submitted, validated, forwarded to an approver, a notification is sent to the requester, and the data is stored in a database. This kind of process is precisely what a low-code platform was built for. The abstraction that becomes a blocker elsewhere speeds up the work here: no authentication layer to build, no form rendering to design.
The common thread across these three scenarios: the problem fits within the platform's standard building blocks, the number of users remains manageable, and the complexity of the business logic is low to moderate. Once any of those assumptions breaks down, you are on your way to one of the limits below.
Six limits low-code runs into
Not one but several boundaries. In practice, organisations rarely hit a single ceiling; they usually accumulate them. A problem described below can still be mitigated; two at once becomes painful; three becomes unsustainable.
1. Vendor lock-in
A Mendix application runs on the Mendix Runtime, a Power App lives within the Power Platform environment, and OutSystems applications are tied to the OutSystems Platform Server. The code you build is not an open standard you can migrate to another environment; it is a platform-specific representation. In practice, moving away means redesigning, not exporting. That is not malicious design; it is how these platforms make their money: by owning the context in which you work.
2. Performance at Scale
Under normal load, a Mendix or OutSystems application works perfectly well. Under peak load — thousands of concurrent sessions, bulk imports, complex queries on large datasets — the abstraction layer becomes a constraint. At that point, you cannot easily hand-optimise your SQL query, you have no direct control over caching strategies, and horizontal scaling is bound by what the platform supports. For an operational back office with a hundred users, none of that matters. For a customer-facing application with thousands of concurrent visitors, it becomes a serious obstacle.
3. Limited Domain Modelling
Low-code platforms work with a fixed way of modelling entities. Mendix has its domain model, OutSystems has entities, and Power Apps uses Dataverse. For CRUD applications, that is fine. But once your business logic becomes complex — think event sourcing, polymorphic entities, multi-tenant sharding, or a model with deep inheritance — you have to force your domain into the platform's straitjacket. It can be done, but it turns into an endless dance of workarounds.
4. Integration Complexity
Calling an API through a low-code connector works for REST endpoints with standard JSON. But as soon as you deal with SOAP, XML with namespaces, OAuth flows with custom claims, WebSockets, gRPC, or streaming data, you have to write connector code that the platform does not handle for you. At that point, you pay the price of low-code (the abstraction layer) without the benefit (speed). With custom development, you have direct access to mature client libraries; with low-code, you end up building a wrapper around a wrapper.
5. Licence Cost Escalation
Runtime licences, per-app licences, premium connector licences, AI Builder credits: the licensing structure of low-code platforms is complex and tied linearly to usage. For a first team of ten users, it is manageable. When rolling out across the whole organisation, you run into a cost curve that rises steeply. With custom development, the main cost sits at the front (development); with low-code, it sits at the back (annual licences that scale with your success). Work out in advance what it costs if the solution succeeds, not just what it costs if it stays within one department.
6. Accumulating Technical Debt
Every workaround you build to get around a platform limitation — a custom Java action in Mendix, a custom connector in Power Apps, an extension in OutSystems — builds up technical debt. It is not visible on a dashboard, but it is felt with every platform upgrade and every developer handover. Eventually, a large part of your codebase is exactly that: workarounds. At that point, you have the worst of both worlds — the licence costs of low-code and the maintenance costs of custom development.
The hybrid route: low-code for admin tooling, custom development for the core
The choice is rarely binary. In many organisations, a hybrid architecture is the right middle ground — low-code where it is useful, custom development where it is necessary.
In practical terms, this means your customer-facing application, the platform that delivers the core of your value proposition, runs on a custom stack. You keep full control over performance, domain model, integrations and extensibility. The internal admin tooling, the back office where your team checks status, approves an exception or generates a report, can perfectly well be built in Power Apps or Mendix. Speed where requirements allow, robustness where it matters.
Custom development for the core
Your customer portal, mobile app, transaction engine, integration layer or platform: anything customer-facing, anything with demanding performance requirements, or anything that forms your differentiator. Here, custom development outperforms low-code on every axis that matters: scalability, integration flexibility and total cost of ownership over the medium term.
Low-code for the periphery
The approval workflow for purchasing, the onboarding form for new employees, the dashboard where business team leads review KPIs themselves. Low-code delivers real value here precisely because the business can manage these tools itself: no IT tickets for an extra field, no developer needed for a new view.
The key architectural principle is the boundary between the two: custom development and low-code communicate through a well-defined API layer. Your custom backend holds the source of truth, and low-code tooling consumes it via REST or GraphQL. No direct database access, no shared state. This keeps the two worlds modular: the low-code tools can be replaced or extended without the core application being affected.
When custom development is the right choice from day one
Not every project lends itself to a low-code starting point. We typically advise custom development in three patterns, not out of ideology, but because the alternatives turn out more expensive.
Complex business domain
When your core business revolves around an intricate domain model, such as pricing engines with hundreds of rules, multi-leg trade settlement, or regulation-driven workflows with field-level audit trails, that rarely fits the standard entity modelling of a low-code platform. Domain-driven design with explicit aggregates, value objects and domain events requires the expressive power of a genuine programming language.
Edge cases that matter
Low-code platforms are optimised for the 80% path. They work well as long as your business behaves "normally". But if the 20% of edge cases, such as refunds, escalations, error recovery and retry strategies, are critical to your value proposition, low-code struggles badly. With custom development, you explicitly write out what happens in every boundary condition, backed by test coverage to prove it.
Performance-critical scenarios
Sub-100ms latency requirements, bulk processing of millions of records, real-time data streaming, high concurrency on a single endpoint. The abstraction layer of low-code costs performance you cannot regain without diving under the hood, and under the hood your access is limited. In those places, custom development is not a luxury, it is a prerequisite.
A candid rule of thumb: if your application is where your competitive advantage lies, where you differentiate from the market, then that is rarely a good place to let a platform vendor dictate your architecture. Custom development gives you the freedom to build and sustain that differentiation.
Migration path: how do you exit low-code without throwing everything away?
Moving away from a low-code platform is not a big bang. It is a phased journey in which you run functionality in parallel, shift gradually and eventually phase out the old environment. These are the four steps we follow in practice.
Domain extraction
First step: spell out in domain documentation the business logic that sits in workflows, microflows or canvas app formulas. This is usually the most painful step, as a lot of logic turns out to be implicit, hidden away in platform-specific configuration. But without this foundation, migrating is guesswork.
API layer between old and new
You build a custom API layer that gradually takes over functions from your low-code application. Both run in parallel: the low-code front end initially calls its own logic, and over time calls the new API instead. Strangler fig pattern: the old environment shrinks as the new one grows.
Modular replacement
Per business module, for example first the request flow, then the approval flow, then reporting, you build a custom equivalent. You validate in production with a subset of users before scaling up. No irreversible decisions for the whole platform at once.
Phasing out
Once all business-critical functions have been replaced, you switch off the low-code environment and cancel the licences. You may keep one or two non-essential admin tools running if they still add value, but the centre of gravity and the complexity now lie in the custom stack you own.
What we use for custom development after low-code
The choice of technology depends on the type of application and the existing infrastructure, but our preference is for mature, widely supported stacks with a large pool of developers available. No exotic frameworks, no platform lock-in 2.0. What we choose must still be maintainable in five years by a developer you did not have to find through a specialist recruitment partner.
For the back end we default to TypeScript on Node.js or C# on .NET, depending on your existing Microsoft investment. For data-intensive services we use Python. Front end: React with Next.js for customer portals, Astro for public sites that need SEO-friendly rendering. Authentication via a mature provider (Auth0, Azure AD B2C). Hosting on Azure or AWS, almost always containerised.
Why choose Appfront when weighing low-code against custom development
No platform dogma
We don't sell Mendix hours or Power Platform licences. We only provide advice and build work that makes sense for your situation. That means we sometimes recommend staying with low-code, and sometimes recommend migrating to custom development, depending on what the figures show.
Understanding low-code codebases
We have analysed, documented and migrated Mendix, OutSystems and Power Apps applications. We know where the business logic is hidden, how to read a microflow, and how to extract a Dataverse model to bring it into a bespoke schema.
Full custom delivery
We don't just provide the advice; we also deliver the migration and the new custom stack. One partner across the whole journey, from inventory to production, avoids the handover pain that otherwise makes these migrations so risky.
Frequently asked questions about low-code versus custom development
Low-code platform at its ceiling? Time for an honest analysis.
We work out what phasing out Mendix, OutSystems or Power Apps would actually cost, and what it would deliver. No obligation and no sales pressure.
Book a sounding-board session