Mendix Meetup Insights: What are you actually paying for in 2034?

Part 3 of 4, from the Mendix Community Netherlands Round Table in Amersfoort, June 2nd, 2026. Parts 1 and 2 asked what is left for the consultant to do and whether we can trust an agent to do it; this one goes after the platform underneath both.

Someone at the table put the case for Mendix in just a few words: you buy off a lot of hassle. A governed cloud, a validated stack, security handled, Siemens standing behind it, all of it kept in order so you do not have to. Not speed. Not even, really, a model you can read. The whole platform.

I have written twice now about June 2nd. The first article envisioned what is left for the consultant to do. The second asked whether we can trust an agent to do it. This third one went after the thing underneath both: the platform we are building all of it on. Is choosing Mendix in 2026 still a defensible decision where concepts like TCO and developer productivity seem to change on a monthly basis?

‍

What the defenders actually defended

The claim on the table was deliberately blunt: the reason to choose Mendix over AI-augmented React in 2026 is not build speed; it is that the thing is still standing, readable, and governed in 2034.

The room that defended it did something I did not expect as the first argument. It defended Mendix without once leaning on speed. "Speed has never been the most important thing," one of them said, "because then everybody would already be using low code." So if not speed, what?

Security and governance, mostly. You are not buying a faster way to type. You are buying a governed cloud that is already set up, a stack that has been validated for years, a thing that is, in one consultant's words, "all in order," with Siemens behind it. "If I were a customer right now," someone said, "I would still go for Mendix with Siemens behind that." The pitch was never the build. It was everything wrapped around the build that you would otherwise have to assemble, secure, and answer for yourself.

That is a real argument, and a better one than "we ship faster". With Mendix we have been used to shipping software faster for a long time. So from first-hand experience, we do know that it's great to be able to spend the well-needed time on getting the requirements and adoption straight instead of battling a coding syntax.

A personal note I must add here is that I strongly believe communication is (and always will be) one of the most costly and time-consuming obstacles to creating new things, whether it's software or something else. For decades, Mendix has enabled very small teams to build enterprise-grade software, whereas high-code approaches require much larger teams to reach the same. AI can help reduce the size of those teams to some extent, but this doesn't mean the responsibility is shared with an organization like Siemens. Rather, it's shared with an LLM developed by someone else, including an expiry date on its possible availability. That's something to be aware of, to say the least.

‍

Readability is part of "in order"

One piece of that package matters more now than it did two years ago, and it is the part people reach for first: you can still read it.

When an agent writes the code, being able to open it up and understand it stops being a nicety. It becomes the difference between owning your app and renting a black box. "I don't like to see an app as a black box," one developer said, "where you prompt, it builds, and you don't know how it works inside." His worry was concrete and client-facing: when the customer asks how you built it, you do not want your only honest answer to be "this was my prompt." When a production issue lands on your desk at the wrong hour, you want a flow you can read, even if an agent wrote it. And the readable model is what lets a developer and someone from the business sit and look at the same thing and actually talk. Even if the AI generates the whole thing, the defenders argued, you can still fall back on something readable and go through it together.

So far this is a strong, grown-up case for Mendix. Governed, secure, readable by a broad audience, and someone else keeps it in order. Which is what makes the next part interesting.

‍

So why did half the room say "neither"?

Because the whole package rests on one assumption, and the skeptics went straight at it. The platform stays worth it only if Mendix itself stays stable and stays ahead. 54% of that vote landed on "neither", the durability claim assumes Mendix keeps its end up, and they were not sure it would.

The other room said it plainly. "In ten years, people will see Mendix as high code," one put it, "or as legacy." Another did not think we would be writing code anywhere in ten years, not in Mendix either. Someone pointed at the pure-prompting tools, where "I don't need to do anything anymore; it's just prompting," and "it changed everything." The governed, validated, readable platform is a great answer, right up until someone else offers the same governance "for free" and lets you prompt your way there. But is that even possible without being able to look inside? And if anyone can do this with years of experience in shared responsibilities on exactly this axis, that would be Mendix, right?

While I was not in that room myself, I still believe that the platform itself proves the highest value here. Many Mendix customers don't like to spend much time or budget on their IT landscape when it's not needed. Even if you can deliver "working" software really fast, if there is no place to put it in such a way that you can sleep at night without the need for a costly department or other mechanism looking after it, what did that first-time delivery speed really bring you? With the large customer base, Mendix simply benefits from economies of scale already. Letting customers enjoy that uniform approach to the cost of a license.

‍

The part that should worry Mendix most

This did not come from a skeptic in the room. It came from someone defending Mendix.

He laid out the whole case, the governed cloud, the validated stack, Siemens, all of it, and then said the quiet thing out loud: "if you look at 2034, why shouldn't an AI-code thing provide the same trust and governance? And that's the main challenge for Mendix."

That is the real competition, and it is not AI-augmented React's build speed. It is whether an AI-native stack can wrap itself in the same trust, governance and readability that Mendix sells today. None of those three is a law of physics. They are a head start. The hassle you buy off with Mendix is hassle that, the day a competitor buys it off too, you can get there too. While typing this based on the outcomes of the round table, I am very much trusting that Mendix will stay on top of it's game. Staying completely up to date with the monthly release notes has never been too easy (in a positive way), but now both the breadth and depth of the releases have increased even more.

‍

So, defensible or not?

Yes, and for the right reasons: the governed platform and the readable model, not the demo-day speed. But that case is not self-renewing. Mendix is not really competing on whether it can build the app. It is competing on whether it stays the most governed, most readable, most in-order way to build, while the AI tools climb steadily toward the same promise. That is a race, not a moat. Referring back to my personal note, building better software with fewer people has been one of the major powers of the Mendix ecosystem. And for exactly this, I have not seen many solid challengers yet when it comes to enterprise-grade software without being tied to a specific domain or software ecosystem.

The defenders in that room were not wrong. They were just honest about the clock. The reason to choose Mendix is still a good one. The question is for how long, and that answer depends less on what AI does next than on what Mendix does next. With the recently announced Intelligence Center X, we can surely say that Siemens is ahead of its game.

Which leaves one more question from June 2nd, and it is the awkward commercial one. If all of this is true, who actually needs it? More on that next time.

‍

Originally published here.