In late 2025 a developer published My First Experience with Mendix: A Low-Code Platform That Didn’t Feel Low-Code. He needed to debug an issue for a customer using Mendix in an integration project, and got stuck before reaching the problem: Mendix does not run in the browser, you must install Studio Pro, and Studio Pro does not run on Linux — the operating system he uses every day.
That led him to ask: if you still install a heavyweight IDE and still need to understand integration, deployment and a lot of engineering, where is the "low-code"? And if you already have a good codebase and a solid CI/CD pipeline, why add a platform on top?
It is a question worth answering seriously. After years of delivering Mendix for enterprise systems, we agree with part of the criticism and see the rest differently.
Where the criticism is right
On tooling, the author is not wrong. According to the Studio Pro 11 system requirements, the fully supported environment is Windows 11. The native macOS version is still a public beta, and from Studio Pro 11.12 it supports Apple Silicon only. Linux is not supported for Studio Pro, even though deployed Mendix applications run well on Linux servers.
For a Linux engineer called in to debug something urgently, that is a real barrier. We do not think it is a small thing, and we hope Mendix broadens support soon.
But from inconvenient tooling, the article concludes that Mendix is not very different from a codebase with some abstractions. Here our project experience points the other way.
Perhaps we misread the "low"
Low-code does not mean dropping software engineering. Nor does it mean anyone can open a browser, drag in a few components and have an enterprise application.
What Mendix does well is raise the level of abstraction of software development. Instead of spending most of the time on boilerplate and framework configuration, much of the work becomes a model:
- The Domain Model replaces most of the data-layer design work.
- Microflows and nanoflows model application logic.
- Pages model the UI; workflows model business processes.
- Security is declared by role and by module.
- Integration over REST, OData and databases is standardised.
- Deployment and lifecycle management live in the same platform.
The hard problems do not go away
As an application grows, the hard problems of software engineering remain. You still think about architecture. You still need to understand transactions, concurrency, performance, security and data consistency. You still design APIs, still debug, still need CI/CD, monitoring, logging and governance.
When integrating with ERP, MES, warehouse systems or IoT devices, a Mendix developer still has to understand how the systems behind them work. In the centralised approval system for TH Group, drag-and-drop was only the surface; the real work was approval flows configurable per department, multiple digital-signing methods and running reliably on both web and mobile.
That is why we do not see Mendix as a "drag and drop to build an app" tool. It is closer to an engineering platform than a visual app builder.
So what does low-code actually reduce?
In our experience, Mendix sharply shortens the distance from business requirement to working software. In a traditional approach there are many separate layers between the two: UX/UI, front-end, back-end, database, APIs, security, deployment, operations — usually many tools and many people.
Mendix does not remove those concepts. It brings them together and standardises them in one development model. This is where we see the biggest value of low-code in the enterprise:
- Business analysts can read a microflow.
- A developer new to the project understands the domain model quickly.
- An architect can see the application structure without reading thousands of lines of code.
- Business users see a running prototype from the first sprints.
The gap between business and technology gets noticeably smaller.
The learning curve is real
Here we agree with many first-time Mendix users. Studio Pro is not a tool you install today and become a Mendix developer by tomorrow. A developer used to writing code usually goes through three stages:
- At first: "Why not just write the code, it would be faster?"
- After a while: "Ah, the platform already handles this."
- Later: "If I design it the platform way, I do not need that code at all."
That is when thinking shifts from coding to modelling. But modelling well is not easier than software engineering: it still requires architectural understanding, and above all an understanding of the platform's limits.
Enterprise low-code is not citizen development
A common mistake is to treat the two as the same. Citizen development helps business users build relatively simple applications themselves. Enterprise low-code solves a different problem: how an organisation can build and change complex business systems faster while keeping architecture, security, integration and governance intact.
In that second problem, SSO, digital signing, event-driven integration, high availability and performance tuning all still show up. Low-code does not remove them; it lets the team spend less time on plumbing and more on what actually matters.
AI is raising abstraction another level
The most interesting shift right now is AI pushing abstraction up one more step: from code to model, and now from requirement to model. With Maia Make in Studio Pro 11.8 and later, a developer describes requirements in natural language and Maia creates and edits domain models, pages and microflows, with workflows added in 11.9. Maia accepts PDFs, images and markdown as context — so a user story or a mockup can be the starting point.
From Studio Pro 11.10, the Studio Pro MCP Server also lets external agents such as Claude Code use those capabilities inside the project. There are limits: Maia cannot generate Java actions, and in 11.10 the MCP Server cannot generate pages yet.
At that point the question is probably no longer "is Mendix low-code enough?" but: on the way from a business idea to a running system, which parts do people genuinely still have to do themselves? In our view that is where the next competition between application platforms lies.
Low-code is engineering at a higher level of abstraction
After years with Mendix, we do not think the biggest value of low-code is writing less code. The bigger value is shrinking the distance between an idea, the business and software that actually runs.
If a platform does that while still handling complex enterprise problems, then needing developers, architects or a dedicated IDE does not make it any less "low-code". It simply shows that low-code is not less engineering; it is engineering at a higher level of abstraction.
If you are considering Mendix for a business system, see how we deliver it on our Mendix & Low-code services page.
Sources: Pasan Uluwatta — My First Experience with Mendix (Medium) · Mendix — System Requirements · Mendix — Maia Make · Mendix — Studio Pro MCP Server