Blog AI Mendix

Mendix Meetup-inzichten: waar betaal je in 2034 eigenlijk voor?

author
Jeroen Appel
Last Update
October 7, 2026
Published
October 13, 2026

Deel 3 van 4, van de Mendix Community Netherlands Round Table in Amersfoort, 2 juni 2026. In deel 1 en 2 stelden we de vraag wat er nog overblijft voor de consultant en of we een agent kunnen vertrouwen om dat werk te doen; dit deel richt zich op het platform dat aan beide ten grondslag ligt.

Iemand aan tafel vatte het pleidooi voor Mendix in een paar woorden samen: je koopt een hoop gedoe af. Een beheerde cloud, een gevalideerde stack, beveiliging die geregeld is, Siemens dat erachter staat; alles wordt op orde gehouden zodat jij dat niet hoeft te doen. Niet de snelheid. Zelfs niet echt een model dat je kunt lezen. Het hele platform.

Ik heb inmiddels twee keer over 2 juni geschreven. Het eerste artikel verkende wat er nog overblijft voor de consultant. Het tweede vroeg zich af of we een agent kunnen vertrouwen om dat werk te doen. Dit derde artikel richt zich op het fundament onder beide: het platform waarop we alles bouwen. Is kiezen voor Mendix in 2026 nog wel een verdedigbare beslissing, nu concepten als TCO en ontwikkelaarsproductiviteit maandelijks lijken te veranderen?

‍

Wat de verdedigers daadwerkelijk verdedigden

De stelling aan tafel was bewust bot: de reden om in 2026 voor Mendix te kiezen in plaats van voor AI-ondersteunde React is niet de bouwsnelheid; het is dat het resultaat in 2034 nog steeds overeind staat, leesbaar is en beheerd wordt.

De groep die het verdedigde, deed iets wat ik niet als eerste argument had verwacht. Ze verdedigden Mendix zonder ook maar één keer op snelheid te leunen. "Snelheid is nooit het allerbelangrijkste geweest," zei een van hen, "want dan zou iedereen al low-code gebruiken." Dus als het niet de snelheid is, wat dan wel?

Vooral beveiliging en governance. Je koopt geen snellere manier van typen. Je koopt een beheerde cloud die al is ingericht, een stack die jarenlang is gevalideerd, iets dat, in de woorden van een consultant, "gewoon klopt", met Siemens als ruggengraat. "Als ik nu een klant was," zei iemand, "zou ik nog steeds voor Mendix kiezen met Siemens erachter." De pitch was nooit het bouwen zelf. Het was alles wat eromheen zit en wat je anders zelf zou moeten samenstellen, beveiligen en verantwoorden.

Dat is een valide argument, en een betere dan "wij leveren sneller". Met Mendix zijn we al lang gewend om sneller software op te leveren. Uit eigen ervaring weten we dus dat het geweldig is om de broodnodige tijd te kunnen besteden aan het helder krijgen van de vereisten en de adoptie, in plaats van te worstelen met coderingstax.

Een persoonlijke noot die ik hier moet toevoegen, is dat ik er sterk in geloof dat communicatie een van de meest kostbare en tijdrovende obstakels is bij het creëren van nieuwe dingen, of het nu om software gaat of iets anders. Al decennia stelt Mendix zeer kleine teams in staat om software van enterprise-niveau te bouwen, terwijl high-code benaderingen veel grotere teams vereisen om hetzelfde te bereiken. AI kan de omvang van die teams tot op zekere hoogte helpen verkleinen, maar dat betekent niet dat de verantwoordelijkheid wordt gedeeld met een organisatie als Siemens. In plaats daarvan deel je die met een LLM dat door iemand anders is ontwikkeld, inclusief een houdbaarheidsdatum voor de beschikbaarheid ervan. Dat is op zijn zachtst gezegd iets om je bewust van te zijn.

‍

Leesbaarheid is onderdeel van "het klopt"

Eén onderdeel van dat pakket is nu belangrijker dan twee jaar geleden, en het is het punt waar mensen als eerste naar grijpen: je kunt het nog steeds lezen.

Wanneer een agent de code schrijft, is het vermogen om die te openen en te begrijpen geen luxe meer. Het wordt het verschil tussen eigenaar zijn van je app en het huren van een black box. "Ik zie een app niet graag als een black box," zei een ontwikkelaar, "waarbij je een prompt geeft, het bouwt, en je niet weet hoe het vanbinnen werkt." Zijn zorg was concreet en klantgericht: wanneer de klant vraagt hoe je het hebt gebouwd, wil je niet dat je enige eerlijke antwoord is: "dit was mijn prompt." Wanneer er op een ongelegen moment een productieprobleem op je bureau belandt, wil je een flow die je kunt lezen, zelfs als een agent die heeft geschreven. En het leesbare model is wat een ontwikkelaar en iemand van de business in staat stelt om naar hetzelfde te kijken en echt met elkaar te praten. Zelfs als de AI het hele ding genereert, zo stelden de verdedigers, kun je altijd terugvallen op iets leesbaars en het samen doornemen.

Tot zover is dit een sterk, volwassen pleidooi voor Mendix. Beheerd, veilig, leesbaar voor een breed publiek, en iemand anders houdt het op orde. Dat maakt het volgende deel interessant.

‍

Waarom zei de helft van de zaal dan "geen van beide"?

Omdat het hele pakket rust op één aanname, en de sceptici vielen die direct aan. Het platform blijft alleen de moeite waard als Mendix zelf stabiel blijft en voorop blijft lopen. 54% van de stemmen viel op "geen van beide"; de claim van duurzaamheid veronderstelt dat Mendix zijn zaakjes op orde houdt, en ze waren er niet zeker van of dat zou lukken.

De andere kant van de zaal zei het ronduit. "Over tien jaar zien mensen Mendix als high-code," zei iemand, "of als legacy." Een ander dacht niet dat we over tien jaar überhaupt nog code zouden schrijven, ook niet in Mendix. Iemand wees op de pure prompting-tools, waarbij "ik hoef niets meer te doen; het is gewoon prompten," en "het heeft alles veranderd." Het beheerde, gevalideerde, leesbare platform is een geweldig antwoord, totdat iemand anders dezelfde governance "gratis" aanbiedt en je laat prompten om daar te komen. Maar is dat überhaupt mogelijk zonder dat je naar binnen kunt kijken? En als iemand dit kan met jarenlange ervaring in gedeelde verantwoordelijkheden op precies dit vlak, dan zou dat Mendix zijn, toch?

Hoewel ik zelf niet in die zaal zat, geloof ik nog steeds dat het platform zelf hier de grootste waarde bewijst. Veel Mendix-klanten besteden liever niet veel tijd of budget aan hun IT-landschap als dat niet nodig is. Zelfs als je heel snel "werkende" software kunt leveren: als er geen plek is om het zo neer te zetten dat je rustig kunt slapen zonder dat er een kostbare afdeling of ander mechanisme naar omkijkt, wat heeft die snelheid van de eerste oplevering je dan echt gebracht? Met het grote klantenbestand profiteert Mendix simpelweg al van schaalvoordelen. Klanten laten meegenieten van die uniforme aanpak voor de kosten van een licentie.

‍

Het punt waar Mendix zich het meest zorgen over moet maken

Dit kwam niet van een scepticus in de zaal. Het kwam van iemand die Mendix verdedigde.

Hij zette het hele betoog uiteen – de beheerde cloud, de gevalideerde stack, Siemens, alles – en zei toen hardop wat iedereen dacht: "Als je naar 2034 kijkt, waarom zou een AI-code-oplossing dan niet hetzelfde vertrouwen en dezelfde governance kunnen bieden? En dat is de grootste uitdaging voor Mendix."

Dat is de echte concurrentie, en dat is niet de bouwsnelheid van AI-ondersteunde React. Het gaat erom of een AI-native stack dezelfde mate van vertrouwen, governance en leesbaarheid kan bieden als waar Mendix vandaag de dag voor staat. Geen van die drie is een natuurwet; het is een voorsprong. Het gemak dat je bij Mendix inkoopt, is een gemak dat je ook elders zult vinden zodra een concurrent het aanbiedt. Terwijl ik dit schrijf op basis van de uitkomsten van de rondetafelconferentie, vertrouw ik er volledig op dat Mendix scherp blijft. Het bijhouden van de maandelijkse releasenotes was al nooit een sinecure (in positieve zin), maar de breedte en diepgang van de releases zijn nu nog verder toegenomen.

‍

Dus, verdedigbaar of niet?

Ja, en wel om de juiste redenen: het beheerde platform en het leesbare model, niet de snelheid van een demo. Maar die positie is niet vanzelfsprekend. Mendix concurreert niet echt op de vraag of ze een app kunnen bouwen. Ze concurreren op de vraag of ze de meest beheerste, meest leesbare en meest gestructureerde manier van bouwen blijven, terwijl AI-tools gestaag naar diezelfde belofte toewerken. Dat is een race, geen slotgracht. Terugkomend op mijn persoonlijke notitie: betere software bouwen met minder mensen is een van de grootste krachten van het Mendix-ecosysteem. En wat dat betreft heb ik nog niet veel sterke uitdagers gezien als het gaat om enterprise-grade software die niet gebonden is aan een specifiek domein of software-ecosysteem.

De verdedigers in die ruimte hadden geen ongelijk. Ze waren alleen eerlijk over de tijd die tikt. De reden om voor Mendix te kiezen is nog steeds valide. De vraag is voor hoe lang, en dat antwoord hangt minder af van wat AI hierna doet dan van wat Mendix hierna doet. Met de onlangs aangekondigde Intelligence Center Xkunnen we zeker stellen dat Siemens voorop loopt.

Wat nog één vraag overlaat van 2 juni, en dat is de ongemakkelijke commerciële vraag. Als dit allemaal waar is, wie heeft het dan eigenlijk nodig? Daarover de volgende keer meer.

‍

Oorspronkelijk gepubliceerdhier.

Find out how CLEVR can drive impact for your business

Contact us

FAQ

Can't find the answer to your question? Just get in touch

No items found.
join the newsletter

Receive personal news and updates in your inbox

CLEVR Company picture Alicia - Ech