Before I became a Mendix developer, I built a financial forecasting application in Excel.
We called it a spreadsheet because that was the file format. In practice, it was software.
I was working in finance at Accenture. Our system of record was TM1, IBM's enterprise planning and forecasting software. Project managers needed to forecast the hours their teams would work, but they did not have access to it.
So I recreated the part they needed.
They entered their expected hours into my workbook. It calculated revenue, costs, profit, burdens, bill rates, cost rates, subcontractor accruals, infrastructure, and the applicable revenue-recognition method. It gave them the same view of their projects that the finance team could see in TM1.
Dozens of project managers used it. My boss eventually required them to use it because it was so useful. They needed those numbers to manage their projects and report to delivery leadership.
Those forecasts rolled up through the organization. No single workbook was going to move Accenture's stock price, but together these were the kinds of numbers that eventually mattered when a public company reported to the market. This was not a trivial side project.
It was still an Excel file.
Every month, the project managers sent their workbooks to finance. We checked that nobody had broken anything, entered their numbers into TM1, and updated the files with actual results. Access meant sharing a file through email or SharePoint.
If Mendix had been available to me, I probably would have built it there instead. We could have had one web application, controlled access directly, connected it to the underlying systems, and removed much of the copying back and forth.
The reason I became a Mendix developer is that I was exactly the person Mendix had in mind when it talked about citizen developers. I understood the work, saw what was missing, and built our team's tools with whatever I had.
People like that are not new. They have been building critical business applications in Excel for decades. We just called them spreadsheets.
What is new is how much further they can go.
The citizen developer might finally be real
I never found the citizen-developer pitch very convincing before AI. A business expert could build a page or two with basic logic. Beyond that, a serious Mendix application still required serious Mendix expertise.
AI changes the equation for the person who is already building the forecasting workbook, data transformation, dashboard, or intake tool. Instead of stopping at Excel, that person can describe the process to an agent and build a web application.
I do not think everybody in the office is about to become a software developer. I do think the existing problem-solver can get incredibly far. When the stakes justify it, a Mendix expert can review the security, inspect performance-sensitive logic, and sign off on the parts that require specialist knowledge.
The expert does not have to build every screen. That is the first version of citizen development that has ever made sense to me.
The path from an English-language request to a working application can be visible at every stage.
It is also why Mendix could become the Platonic ideal of vibe coding.
Microflows are how we check AI's work
Bad vibe coding is easy. Describe what you want, check that the happy path works, and put the application into production.
Good vibe coding begins the same way. Then you do the work nobody wants to do: regression testing, load testing, penetration testing, and security hardening. You make sure the application can survive where it will actually live, whether that means 30 people in a department or millions of records and thousands of users.
LLMs are magical. You still have to check the work.
If English is becoming the language we use to request software, we need a way to inspect what the machine built. Clicking through the finished application is not enough.
Mendix gives us a visual model. I can open a microflow and follow it from one end to the other. I can see where it turns left or right, what happens under each condition, which records change, and which associations get set.
AI still makes funny choices. It puts commits inside loops, which can create a performance problem. You ask it to clear two associations, and it clears one. It chooses a strange widget because the right one had not been downloaded into the project yet. It follows the app's styling here and then chooses not to over there.
Today's version of AI coding still very much requires a human in the loop. I suspect it will stay that way for the foreseeable future.
For every critical area of the application, I am opening the model and making sure I understand the approach. When it touches data, I am also checking what it is doing to the database.
It is picture books versus novels. Mendix can hold just as much complexity, but it is easier to follow.
The new coding language is English. Microflows are how we check AI's work.
The spreadsheet can become a real application
My forecasting workbook did its job. Its limitations came from everything around the calculations.
There were multiple copies. People could break formulas. Finance had to validate each submission and transfer the numbers into TM1. Actuals had to come back the next month. Access was governed by possession of a file.
A web application gives everyone one maintained version. It can validate data at entry, retrieve actuals from another system, and send an approved forecast onward. Project managers, finance, and delivery leadership can each have an experience designed for their part of the process.
Mendix brings the data model, application logic, integrations, security, and deployment path into one platform. I can create a deployment package from the commit I want, point it at an environment, and deploy it. Organizations that need more control can use Kubernetes or private-cloud options.
Reusable modules also let the work compound. At Kinetech, our Conductor module supports case management with workflows and intake forms that can change at runtime. We can begin a new application with a production-proven capability instead of rebuilding the basics. The Mendix Marketplace extends the same idea with reusable modules, connectors, and widgets.
This is the difference between an ingenious workaround and an application an organization can continue to operate.
Security is a clear glass of water
Security in a traditional application has never felt as legible to me as it does in Mendix.
Open the domain model and select an entity. Mendix's access rules show which roles can create or delete records, which attributes and associations they may view or edit, and the XPath constraints that limit which records they can retrieve.
Imagine an application used by several nonprofits delivering assistance for a state. Every user belongs to an organization, and the applications and households hang off that organization.
An administrator may see everything. A user at one nonprofit should retrieve only the records associated with that organization. You can see that rule in the model.
Then you can test it. Create multiple organizations and sample records. Use auditing tools to inspect what the current session can retrieve, not merely what appears on a page. Check what an anonymous visitor can access. Confirm that one tenant cannot retrieve another tenant's data.
This does not make security automatic. A bad rule remains a bad rule. It makes the intended access model unusually inspectable for both the person building the application and the specialist auditing it.
When AI can generate a large amount of software very quickly, that clarity becomes more valuable.
Mendix is not all the way there yet
I do not work for Mendix, and this is not a Mendix advertisement.
The Studio Pro MCP server lets external agents such as Claude Code work with the Mendix model. I use both Claude and ChatGPT. The capabilities are moving quickly, but my current workflow still has obvious gaps.
Large pages can cause simple edits to fail. Sometimes I have the agent stage the work elsewhere and copy it into place manually. Nanoflows and snippets require more hand-holding than they should. Generated microflows can be laid out like spaghetti, which defeats part of the purpose of a human-readable visual model.
The most annoying version is when the agent knows a page is too large, attempts the edit anyway, fails, and sends me through staging, copying, restyling, and fixing whatever did not paste correctly.
These are real limitations, but they are not deal-breakers. I can work around them in Studio Pro, and Mendix has been adding capabilities quickly. I have no inside information, but I would be surprised if the obvious gaps were not already getting attention.
The magic wand still needs a magician
AI does not eliminate the value of being excellent at Mendix. Marc, our CTO, is the David Blaine of Mendix. If AI makes everybody a magician, Marc is still head and shoulders above the other magicians.
The value of expertise is shifting. Less time goes into assembling basic structure. More goes into deciding how the workflow should behave, what makes sense within the whole application, and what will feel obvious to the person using it. There may be six technically possible choices and five of them are wrong.
More people can pick up the wand. The best builders can spend more time on judgment instead of grunt work. Experts can review more and construct less.
I was a citizen developer long before I knew the term. I built an application in Excel because Excel was what I had.
The next version of me is not going to stop there.