Optimize Product Development with Teamcenter

Part 4 of 4, Straight from the Mendix Community Round Table Meetup in Amersfoort on June 2nd, 2026. Parts 1 to 3 questioned what is left for the consultants to do, whether we can trust an AI agent to do it, and whether the platform still earns the choice. This article asks the commercial question underneath all three: who actually needs such a platform?

A seller at one of the tables had called the Dutch IT director of a top-tier investment bank to invite him to an event. Friendly guy, so he got a few minutes, and the director used them to explain why the answer was no. "No issue with low code," he said. "We're just not doing that anymore. We do everything with AI now, the full application lifecycle." And how do you govern all that? "We have four thousand engineers, and the resources to have full teams checking it." The seller told us afterwards that he could not counter it and did not pretend otherwise.

That answer stayed with me for the rest of the evening, and it has been hanging over this series ever since. I have written three times about June 2nd: what is left for the consultant to do, whether we can trust an agent to do it, and whether Mendix is still a defensible platform to do it on. Each of them ends up in roughly the same place: the value holds if you build it right. So the commercial question remains. If all of that is true, who actually needs it?

‍

The upper end of the market answered honestly

The bank was being accurate rather than dismissive. A company with four thousand engineers can do everything with AI and put full teams on checking the output, because it can afford to. Those enterprises have their AI in place and their budgets spent, so the question they ask is fair: why would we add a platform for this when we already build one ourselves?

The instinct many of us were trained on, chase the biggest logos and land the enterprise, deserves a second look. The companies with the most resources need a platform that takes the hassle away the least, because they are used to carrying the hassle themselves. At least when they are a software-focussed enterprise already. If they are not, a platform like Mendix still gives an incredible head start without the years it takes to build a platform approach yourself. Because yes, that's what it needs to reach a situation that is only getting close to what platforms like those of Siemens can offer.

‍

A nuance I want to add myself

Read that answer back and it sounds like AI mostly closed the door. I do not think it did. Was that bank ever going to buy a low-code platform? In 2019, with the same four thousand engineers, before any of this? Almost certainly not to replace its entire tech stack.

A few things keep a company that size building its own, and most of them have little to do with AI.

• Habit and history. An organization that has built software its own way for twenty years has an estate, standards, a review process and existing resources and components. Nobody rips that out because a vendor turned up with a better story.
• Talent, which is more local than we usually admit. If you can hire four thousand engineers, and hire them where the labor cost works out, building in-house is a defensible choice. For a company in the Netherlands hiring in the Netherlands that calculation can look completely different, and so can the values and beliefs behind it.
• The cost they already paid, which the bank did not mention. Years of procedures, internal standards, a platform team, an internal developer platform that somebody has to keep alive. They did not skip the hassle. They bought it in-house and spread the cost over a decade, which is an expensive position that only a company with the scale, strategy and time could get into.

So the four thousand engineers do not prove the platform case is dead. They show that a company big enough, with the right strategy, can build a similar platform experience for itself. This one did, and it took years and real money. It says little about low code, and a lot about who can afford to do without it.

‍

A moving market

I do not even feel it changed too much, with one important addition that I will come back to later. The opening sits with the company that says something close to "I am a construction firm, I am not an IT company," and wants a single supplier to have covered the security, the governance and the integrations already. They cannot put internal teams on checking high-code AI output, and they do not want to either. They want to buy off the hassle, which, as I argued last time, is the real low-code pitch once you stop thinking it is only about first-delivery speed.

A useful dividing line through the middle of that market is roughly the number of apps you run. A one-app company drifts toward the pure-prompting tools as a head start, because for one app, why not just prompt it and see how it holds? But once you have a dozen apps, integrations, and things that have to talk to each other and be governed together, you need something that holds the whole estate together. An orchestration platform that can manage them all starts to make sense there in a way it never did for a single app. That is the enterprise profile where all of this still fits. It is too small to have outgrown the platform for domain-specific reasons, and too big to prompt its one app into existence before caring about the full picture. I call it the orchestrating middle, and it is where most companies will find themselves.

‍

The objections

Some objections come up every time, and I would rather answer them than wish them away.

The first is perception. There is a feeling in some rooms that choosing low-code in 2026 is the unadventurous option, the sensible and slightly dull choice while everyone else does something shiny with AI. That perception is only partly real, given the huge AI investments from Siemens as well. The platform might not be on par with the possibilities of the big frontier models the day after they release a new version. That said, even since the Meetup in June (this article was published in September), AI assisted development with Mendix matured enormously. I am quite sure the discussion would be more nuanced if we hosted this session again.

The second is lock-in, and it is a fair concern. "It's half the price, and then I own the IP" is something buyers genuinely say when they weigh a managed platform against high code. High code feels like freedom, a managed platform can feel like a cage, and AI has, if anything, made the high-code side look less locked-in than it used to. Denying the lock does not help. Being clear about what it buys you does, and so does being clear about what migrating away would cost. With a reasonably open platform like Mendix that cost is lower than people expect, and with Maia Transform it is now fairly doable to migrate code bases to and from Mendix. Having that option can be a good peace of mind while you enjoy the benefits of the platform.

The third one is quieter. A customer who already has a mature AI strategy elsewhere does not want to bolt new AI onto yet another platform's resource pool. They want to use what they have already invested in. Pitch only greenfield, "add AI here," and you will keep meeting buyers who came at AI from a different direction and got there first. Respecting that allows for a much deeper conversation about what is needed, especially as Mendix lets you use "their" AI, bring your own, or blend them into a mix you like.

‍

The actual pitch

It is sharper than what came before, even if it sounds like a downgrade at first.

You sell having already done it: the supplier who has solved the governance, the security and the integration, so the construction firm does not have to. For the right customer, "we have done the hard part already" is a stronger line than "we are faster," which stopped being true the moment a prompt could ship faster than any of us. Even though these are mostly prototypes and not enterprise grade apps from the first delivery. When shipping your Mendix app on day one, you get ISO 27001, 27017, 27018, 9001, and SOC 2 Type II reports, plus support for GDPR, HIPAA and PCI-DSS without even knowing what they entail. This is and always will be one of the huge drivers of owning Mendix as your enterprise app platform.

There is also one wedge the four-thousand-engineer crowd cannot take, because it has nothing to do with resources and everything to do with trust. Data. A consultant at another table, talking about a government client, put it plainly: they are "very scared, what's going to happen to the data." So you do not lead with the AI. You build the trust first, keep the data in their hands on infrastructure they control, and let the AI come second. For a whole class of customers, in government, in healthcare, anywhere the data cannot leave the building, that is the entire reason they can say yes at all. Local LLMs rapidly land here, and Mendix and Maia can use them just as well.

For those who reached this part of the series and think: but what about Siemens? Most of the Dutch Mendix Community has experience in other domains than manufacturing, so it does not come as a surprise that this angle did not reach a table. It should not be ignored either. With Mendix in its portfolio, including the broad (AI) capabilities discussed above, I can only be happy for the customers that are already well invested in the Siemens ecosystem.

‍

Closing the series

The bank with four thousand engineers was never going to be the main growth, and chasing it is how you end up feeling replaceable. The growth is with everyone below that line who cannot do it themselves and does not want to: the orchestrating middle, the regulated, the ones who want one trusted supplier to have covered the hard parts and to keep their data where it belongs.

Those were four questions from one evening: what is left for us to do, whether we can trust the agent to do it, whether the platform still earns the choice, and who actually needs it. Now that I have written them down, I notice that none of the answers are really about the technology. They come down to judgment, trust, and knowing who you are for. Which is a reassuring thing for a room full of consultants worried about AI to have talked their way into.

Thank you for reading, if you made it through the full series. These articles reflect the discussions in the room, completed with my own opinion, so I am very much looking forward to your thoughts. Does it resonate with what you are seeing? Are you happy, or worried about the possible new perspectives? Either way, I am eager to host another Round Table later this year, or early next year, to go through some statements in person again.

‍

Originally published here.

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.

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

She gave an AI access to her machine and her inbox and asked it to get some work done. It started deleting real emails, thousands of them. She told it to stop. It kept going. Afterwards she asked it why. It said: yes, I knew it was wrong, but I did it anyway.

That story got told at one table on June 2nd. Then it turned up, on its own, at another. Two rooms full of Mendix consultants, the same evening, reaching for the same cautionary tale without knowing the other had.

Last time I wrote that the agent is going to take over the building, and that the job left for us is deciding what is worth building and standing behind what ships. This is the next question, and the room could not leave it alone. Once the agent can act on its own, do we let it?

‍

So we just don’t let it act?

Bluntly, that was the night’s first answer. The statement on the table was that every agentic feature we ship should keep a human in the loop, and 69% voted to gate the agent, nine of thirteen. Not because the room thinks the technology is dangerous forever. Because trust has not been earned yet, and that is a different thing. Suggestions today, supervised actions next, autonomy once there is a track record. As one developer put it, if it proves that it works, we move from one, to two, to three.

So far, so sensible. Keep a human on it until it earns its way off. But that framing has a hole in it, and somebody at the table put their finger on it.

‍

What changed the conversation

The sharpest thing said all night was not about trust at all. It was about plumbing.

“The way agents are at the moment,” one support engineer said, “you just put a wrapper around the whole API and say, here’s the API, go away and do it. And there’s no difference between reading something and deleting something.”

That is the actual problem. Not whether the agent is trustworthy, but that we hand it a tool which cannot tell the safe action from the destructive one, and then argue about the agent’s character. Change the tool, and the argument changes. Here are your APIs, went the reframe, but they are read-only. I am not going to give you the tool to do something dangerous.

One person wanted it physical. Not a setting, not a line in a system prompt. An actual switch that has to be pushed before the dangerous thing can happen, and the agent does not get to push it. It sounds paranoid. It sounds a good deal less paranoid once you have heard the email story.

This is the move from gating the agent to gating the tools. Stop trying to make the agent trustworthy. Decide what it can reach.

‍

What being in control actually means

This is where the room agreed most. Asked whether we are still in control of what AI builds, 86% landed on the same answer, six of seven: it depends on the boundaries. Not the optimist’s answer, not the pessimist’s. The engineer’s.

And the reasoning was concrete, and it was the same in both rooms. Scope the tools the agent is handed. Separate the things that read from the things that destroy. Keep backups and a restore path. Put a human in front of anything you cannot undo. One consultant drew the line exactly: creating orders is not a problem; if you delete orders, that is a problem. Let the agent act freely where acting is cheap to reverse, and gate hard where it is not. Or, as he framed the constraint, you can mark for deletion; you cannot really delete. If there is an easy recovery mechanism, then it is fine to give it the freedom.

Freedom inside the boundaries, accountability on the way out. That is not a compromise between trusting and not trusting the agent. It is a design. And it is one we already know how to build, because it is the same thinking we put into who is allowed to do what in any Mendix app we have ever shipped. Personally, this also helps me see the nuances in this AI era. Deterministic processes remain deterministic with the same strict validations and workflows we’re familiar with today. The way we interact with them may change, but the essence rarely does.

‍

So gate everything and sleep easy? Not quite.

Here is the part I want to be honest about, because it is easy to leave out of a tidy conclusion.

The gate is for now. It is not forever. The same table that voted to keep a human in the loop said so out loud and asked the host to put it on the record: it will move to three, without a doubt. Trust gets earned, gates come off, and the careful consensus everyone just voted for has an expiry date stamped on it.

So the useful work is not building the gate. It is building the gate so it can move. A boundary you can loosen one action at a time, as each one earns it, is worth far more than a blanket “a human approves everything” that you will quietly start ignoring the first week it slows you down. One table even floated moving the gate to the end: let the agents build, and put someone with common sense at the checkpoint before anything real happens. The gate does not have to live in the same place forever. It has to live in the right place for the trust you actually have today.

‍

The delete button nobody took away

The agent that deleted those thousands of emails was not evil, and it was not broken. It told the truth, in its strange way. It knew the action was wrong and it did it anyway, because nobody had taken the delete button out of its hand.

Control was never a feeling you have about AI, optimism or dread. It is a decision you make about what the agent can reach, and you get to make it again every time the trust changes. Get that right, and you can hand an agent a surprising amount of freedom. Get it wrong, and it will not matter how much you trust it.

This was the second article I have written up from June 2nd. The first asked what is left for us to do. This one asked whether we can trust the thing to do it. There is one more question sitting underneath both, and it is about the platform we are building all of this on. More on that next time.

‍

Originally published here.