Low code vs custom software is a choice per app, and the answer can change later. Low code suits internal apps with standard forms and fixed workflows, a fast first version, and organisations without their own developers. Custom software fits once your business logic needs workarounds, the app slows down as it grows, or integrations fall outside the platform.
Mendix, OutSystems, and Microsoft Power Apps are widely used low-code platforms, and for many apps they remain a good choice. Below you'll find a decision table, six signs that show when low code stops scaling for an app, what moves and what stays, and how a move to custom software works.
Low code vs custom software in one table
Low code or custom software is a question you answer per app. Go through the eight situations below with one app in mind.
| Situation | Low code fits when | Custom software fits when |
|---|---|---|
| Type of app | It's an internal app with forms and approvals | The app carries your core process, or customers and suppliers work in it |
| Pace | You want a first version quickly to test an idea | The software must last for years and keep changing |
| Team | Colleagues who know the process build it, without developers | You have your own development team or a regular partner |
| Business logic | The rules fit the platform's building blocks | Every new rule calls for a workaround |
| Users and data | One department uses it and the data stays manageable | The number of users or records is growing fast |
| Integrations | The platform's connectors cover all your systems | You connect systems for which no connector exists |
| Testing and version control | One or two makers test by hand | Several developers work at once, with automated tests and code reviews |
| Dependence | You're comfortable with the app running on one vendor's runtime | You want to own the code and choose where the software runs |
If your app sits on the left in most rows, the platform is doing its job. If it moves right on three rows or more, read the signs below.
What low code does well
A low-code platform lets you build apps with visual models instead of code. You assemble screens, draw the steps of a process, and connect the app to popular packages through standard connectors. The platform handles login, roles, and rolling out new versions.
That works well for:
- Internal apps with standard forms and workflows, such as submitting and approving a request.
- A fast first version to test an idea with real users. Our article on what an MVP is explains how to keep it small.
- A team without developers, where colleagues who know the process build the app.
- An app that replaces a shared spreadsheet. If it needs to do much more, read when to replace Excel with a web application.
For apps like these, custom software is often more than you need.
Six signs your app is outgrowing the platform
The limitations of low code show up as an app becomes more important, gains users, and has to talk to more systems. Watch for these six signs.
1. Business logic keeps needing workarounds
Every platform has building blocks for common logic, such as a required field or a status change. Rules with many exceptions fit less well, for example a schedule that has to account for shifts, permissions, and stock. You end up building workarounds with helper fields, extra steps, and bits of your own code. Together they make the app hard to understand and risky to change.
2. The app slows down with more users or more data
An app that responds quickly with 20 users and thousands of records can stall with 200 users and a million records. The platform decides how the app queries the database, and you have less control over that than in your own code.
Microsoft describes one such limit for canvas apps in Power Apps. When the data source can't run a query itself, Power Apps retrieves the first 500 records by default and works from there. You can raise that limit to 2,000. If the source holds more records, Microsoft notes that the result may be incorrect. Functions that the data source can run itself avoid the problem.
3. Integrations fall outside the connectors
Connectors cover popular packages well. Your own ERP, an older system, or a messaging standard from your sector often isn't among them. You then build your own connector or an intermediate layer, and part of the app lives outside the platform. With many messages a day, you'll also want to control how an integration handles errors and retries.
4. Testing and version control don't fit your team
With one or two makers, testing by hand is fine. Once five developers work on the same app, you want separate branches in version control, code reviews, and automated tests on every change. On a low-code platform, the app lives in a model in the vendor's format, and comparing, merging, and testing often happen with that platform's own tools. If that doesn't match how your team works, every release takes longer than it should.
5. You depend on one vendor's runtime and licence model
A low-code app runs on the platform's runtime. Mendix describes the Mendix Runtime as an interpreter that runs your app's model. Each patch version of Mendix comes with its own runtime, which can only run apps built for that version. Upgrades therefore follow the vendor's rhythm.
According to Mendix's licensing documentation, you need a licence for each environment to lift the restrictions on an unlicensed app. Outside Mendix Cloud, an unlicensed app stops after two to four hours and allows at most six concurrent users. With licensing per user, the licence model grows with the number of users.
6. Taking your app and data elsewhere is hard
One of the drawbacks of a low-code platform only becomes clear when you want to leave. You can usually export your data. The way the app works sits in a model in the platform's format, and another platform can't read that model. So ask up front what you take with you: data, files, logic, and the history of changes.
If you recognise one sign, you can often solve it within the platform. If you see three or more in an app your business runs on, it's time to look into a move.
What stays in low code and what moves
A move doesn't have to include every app. Decide app by app.
This can stay in low code:
- Forms and approvals within one department
- Apps with few users and manageable data
- Temporary apps and prototypes
- Apps whose integrations the platform's connectors fully cover
This moves to custom software:
- The core process with the most rules and exceptions
- Apps with many users or large volumes of data
- Portals where customers or suppliers work
- The place where your systems exchange data
The two can sit side by side. The custom core offers an API, a fixed entry point for other software. Small low-code apps around it use that API and keep working as they did.
Moving off a low-code platform in four steps
A move is safest when the old app keeps running until each new part has proved itself.
1. Map what the app actually does
Go through every screen, workflow, and scheduled task in the model together with the makers. Note which rules it contains, which roles exist, which integrations run, and which notifications the app sends. Talk to users as well. They know the workarounds they invented because the app couldn't do something.
2. Get the data out and test the export early
Start on the export while your licence still has plenty of time to run. Check what comes along: tables and relationships, attachments, the history of changes, and user accounts. Run the export and the import into the new data model a few times as a trial, and have users check samples of the results.
3. Rebuild the core while the old app keeps running
Martin Fowler calls this approach the strangler fig, after the vine that germinates in a tree and eventually grows its own roots. You build new parts alongside the existing system and let old and new coexist for a while. Our article on legacy systems explains how that works.
Start with the part where the sign is strongest, such as a schedule that has become too slow. Agree per part which system is the source of the data. Our guide to software development outsourcing describes how the rest of such a project runs.
4. Switch off the old app step by step
Move users over by group or department. Keep the old app available read-only for a short period, so no one misses any data. Then cancel the licences you no longer need and clean up connectors and accounts.
Five pitfalls when you switch
- Rebuilding the old app like for like. Some screens only exist because the platform couldn't do something. Take the process as your starting point.
- Forgetting what the platform handled for you. In custom software, you set up login, roles, logs, and releases yourself. Plan for them from the start.
- Moving everything at once. A switch on a single date piles every risk onto one day. Working in steps gives you a way back at every stage.
- Leaving the makers out. They know the rules and exceptions best. Give them a fixed role in the inventory and in testing.
- Losing track of the licence term. If the contract ends before the new software is ready, you renew under time pressure. Plan backwards from the end date.
Custom software from Isatis
Isatis builds custom business software, with teams in Nijmegen, in the Netherlands, and Sarajevo. We've been doing this for more than 30 years, with 30+ engineers and more than 100 projects, and we're certified for ISO 9001 and ISO 27001. Our page on custom software development shows how we work.
If you're unsure whether an app can stay on low code, book a conversation. We'll also tell you when the platform still suits your app.
Frequently asked questions
What is the difference between low code and custom software?
With low code, you build an app with visual models and the vendor's platform runs it. With custom software, developers write the code and you decide where the software runs. Low code is faster for standard apps. Custom software gives more freedom for complex logic, many users, and demanding integrations.
When is low code the right choice?
For internal apps with forms and fixed workflows, for a first version to test an idea, and when you have no developers of your own. If the logic, users, and integrations stay manageable, such an app can work well for years.
Can you combine low code and custom software?
Yes. Build the core as custom software with an API, and let small low-code apps read and write data through that API. The most important rules then live in one place.
Mendix vs custom development: which fits when an app stops scaling?
You can move to another low-code platform or to custom development. Either way, you rebuild the app, because each platform works with its own model. If the app is growing mainly in logic, users, and integrations, custom development is the more natural choice.
How long does a move from low code to custom software take?
It depends on the size of the app, its integrations, and the volume of data. Because you work in steps, the first part often goes live while the rest still runs in the old app.
