Low-code platforms promise to build software faster and cheaper. Mendix, OutSystems, Microsoft Power Apps — the pitch is always the same: assemble a working application through drag-and-drop instead of hiring an army of developers. For some projects that promise holds up. For others, it's a trap that ends up costing more than custom development ever would.
I've built production software on Mendix — including a BuildingX IoT connector for Siemens used by enterprise customers. So this isn't a low-code-is-bad rant. It's an honest look at when the platform earns its keep and when it quietly works against you.
What low-code actually is
A low-code platform gives you a visual development environment. You assemble screens, data models and business logic through a graphical interface instead of writing every line by hand. You still build real applications with real databases and real integrations — you just do a large part of the work by configuration rather than code.
The important word is low-code, not no-code. Serious Mendix projects still involve custom Java actions, REST integrations and real architecture decisions. Anyone who tells you a complex business system can be built with zero programming is selling you something.
Where low-code wins
Low-code is genuinely the right call in a few clear situations:
- Internal tools and forms-over-data apps — Approval workflows, registration systems, case management. Standard screens on top of a database, where speed of delivery matters more than a polished interface.
- Enterprise environments that need governance — Large organisations value the built-in user management, audit trails and deployment controls. The platform enforces consistency across dozens of apps.
- Fast delivery of a first version — A working app in weeks instead of months. For validating a process before committing a larger budget, that speed is real.
- Teams without a deep engineering bench — When you don't have senior developers in-house, a low-code platform lets a smaller team ship and maintain useful software.
For these cases, low-code can cut initial build time by 30 to 50 percent compared to writing everything from scratch.
Where low-code costs you
The trouble starts when a project drifts outside the platform's comfort zone:
- Vendor lock-in — Your application lives inside the platform. Migrating away later means rebuilding, not exporting. You're tied to one vendor's roadmap, pricing and limitations.
- Recurring licensing cost — Custom software has a build cost and then cheap hosting. Low-code adds a licence fee that never stops, scaling with apps and users. Over five years this often overtakes the cost of building custom.
- The last 20 percent — The first 80 percent of a low-code app is fast. The remaining 20 percent — a specific UI interaction, an unusual integration, a performance edge case — can take longer than it would in code, because you're fighting the platform instead of using it.
- Custom, consumer-grade interfaces — If design and user experience are a competitive advantage, low-code's standard components will hold you back. These platforms are built for function, not for pixel-perfect product design.
- Specialist scarcity — Good Mendix and OutSystems developers are rarer and often more expensive per hour than general web developers. The talent pool is smaller than it looks.
The licensing math nobody mentions
This is where many low-code decisions go wrong. The build quote looks attractive, but the licence is a subscription you pay every year for as long as the app lives. Depending on the platform, number of apps and user count, that runs from a few thousand to tens of thousands of euros per year.
Compare that to a custom application: a one-time build, then hosting that often costs €50 to €500 per month. On a system you expect to run for five or ten years, the recurring licence can quietly become the largest line item — larger than the original build. Always model the total cost over the full lifespan, not just the first invoice.
A simple decision framework
Ask four questions before choosing low-code:
- How long will this system live? A tool you'll run for ten years favours custom — the licensing adds up. A short-lived internal app favours low-code.
- How unusual is the logic and the UI? Standard screens over a database: low-code. A distinctive product with complex interactions: custom.
- Who maintains it? No engineering team in-house? Low-code lowers the barrier. A capable team? Custom keeps you flexible.
- What does five years of licensing cost versus building it once? Do this math explicitly. It frequently flips the decision.
How I approach it on a project
I don't start from the platform. I start from the problem, the lifespan and the budget over time — exactly the questions a proper discovery phase answers. For a short-lived internal workflow with standard screens, I'll happily recommend low-code and build it fast. For a long-lived, distinctive product where the recurring licence would eventually dwarf the build, custom is the honest answer — even though it's more work for me upfront.
The choice between low-code and custom is really the same decision as building in-house versus outsourcing: there's no universal winner, only the right fit for your situation, timeline and budget.
Not sure which fits your project?
Describe what you want to build, how long it needs to last and roughly how many people will use it. I'll tell you honestly whether low-code, custom development or a standard tool is the smartest route — including a realistic five-year cost picture. No commitment, no sales pitch. Let's talk.