Vendor lock-in bij low-code: het eerlijke antwoord en hoe je het beheerst

Je overweegt een applicatie te laten bouwen op een low-code platform. Het bevalt in de demo, het plan is helder, en dan stelt je financieel directeur de vraag die je verwacht had: "En als we over vijf jaar iets anders willen? Zitten we dan niet vast?"

Het eerlijke antwoord is: ja, tot op zekere hoogte. Dat geldt bij low-code, maar ook bij een standaardpakket en bij maatwerk. De vraag is niet of je afhankelijk wordt, maar waarvan, hoe duur vertrekken wordt en wat je vooraf kunt doen om dat te beperken.

Waar zit de afhankelijkheid eigenlijk?

Lock-in is geen enkel ding. Bij low-code zitten er minstens vier lagen in, en ze wegen niet even zwaar.

De data. Dit is meestal het waardevolste deel van je applicatie: klanten, orders, installaties, certificaten. Data in een gewone database is over te zetten. Hoe makkelijk hangt af van hoe het platform de gegevens opslaat en welke toegang je hebt.

De logica en schermen. Bij low-code teken je processen en schermen in een visuele omgeving. Dat model is het resultaat van jouw bedrijfskennis, maar het is geschreven in de taal van het platform. Die taal neem je niet zomaar mee naar een ander systeem.

De kennis in mensen. Wie het platform beheert, moet het kennen. Voor een MKB-bedrijf dat één of twee mensen heeft die het platform snappen, is dat een reëel risico, ook bij maatwerk in een gewone programmeertaal.

Het contract. Looptijd, opzegtermijn, wat er met je omgeving gebeurt na afloop en of je je data kunt meenemen. Dit deel is het makkelijkst te beïnvloeden, en het wordt het vaakst vergeten.

Wat zegt OutSystems zelf?

OutSystems is op dit punt stellig. In hun evaluatiegids staat dat het platform geen eigen runtime-engine of eigen interpreter gebruikt en dat het je applicatiemodellen omzet in standaard .NET-applicaties die op een gewone webserver kunnen draaien. Ze noemen zichzelf daar zelfs de enige oplossing die echt geen vendor lock-in biedt.

Dat klinkt geruststellend, maar lees de details. Het uitgangspunt is het zogeheten detach-proces, dat OutSystems beschrijft op een eigen supportpagina. Daar staat wat er gebeurt als je echt weggaat:

• Het werkt alleen voor de .NET-variant van OutSystems 11, vanaf versie 11.18.1.
• Het is alles of niets. Je kunt niet een paar applicaties losmaken en de rest op het platform laten draaien.
• Het is een eenrichtingsstraat. Zodra je de gegenereerde broncode zelf gaat onderhouden, kun je niet terug naar het visuele model.
• Je verliest de platformgereedschappen: de visuele ontwikkelomgeving, het automatisch uitrollen en de monitoring. Wijzigingen die je zelf in de code maakt, worden niet meer door OutSystems ondersteund.

Onze eerlijke lezing: je hoeft dus niet bang te zijn dat je applicatie van de ene op de andere dag stopt, en je bezit een werkende .NET-applicatie. Maar je koopt daarmee ook een codebase die gegenereerd is en bedoeld was om via het platform onderhouden te worden. Wie die overneemt, wordt eigenaar van een onderhoudsklus. "Geen lock-in" is een marketingzin. "Een uitweg die tijd en werk kost" is realistischer.

Let ook op de versie. Deze beschrijving geldt voor OutSystems 11. OutSystems heeft daarnaast een nieuwer platform, OutSystems Developer Cloud. Voor de uitweg daar hebben wij geen gelijkwaardige, publieke beschrijving gevonden. Vraag je leverancier dat schriftelijk voordat je tekent, en neem het antwoord op in je afspraken.

Vijf maatregelen die het risico echt verkleinen

Wij bouwen zelf op OutSystems, ook het certificeringsplatform voor MEA Beveiliging, en werken met deze maatregelen.

1. Houd de kennis van je proces buiten het platform. Leg vast wat de applicatie doet: welke rollen, welke schermen, welke koppelingen, welke regels. Begin daarbij met een mockup die je zelf bewaart. Als je ooit opnieuw moet bouwen, heb je dan een specificatie in plaats van een raadsel.
2. Zorg dat je data altijd bereikbaar is. Ons advies: bewaar bij complexe toepassingen de kritieke gegevens op een plek die je zelf beheert, en leg vast hoe je de rest van je data na afloop van het contract terugkrijgt. Dat is een architectuurkeuze die je vooraf maakt en achteraf nauwelijks kunt inhalen.
3. Koppel via standaard interfaces. Laat andere systemen praten met je applicatie via gangbare API's, niet via platform-specifieke trucs. Dan raakt een latere vervanging de rest van je landschap niet.
4. Houd de applicatie modulair. Een aantal kleinere onderdelen met duidelijke grenzen is makkelijker te vervangen dan één grote kluwen. Dat geldt voor elk systeem, maar bij low-code is het verleidelijk om het over te slaan omdat bouwen zo snel gaat.
5. Regel de exit in je contract en test hem. Vraag wat er gebeurt met je gegevens en je omgeving na afloop, hoe je ze krijgt en in welk formaat. Doe eens per jaar een proefexport en kijk of je er iets mee kunt.

En de wet dan?

Regelgeving uit Brussel helpt ook. De Data Act bevat regels waarmee klanten makkelijker kunnen overstappen tussen aanbieders van dataverwerkende diensten, en is sinds 12 september 2025 van toepassing. Of jouw low-code platform daaronder valt, hangt af van hoe het wordt aangeboden. Wij zijn geen juristen en beweren dat dus niet voor een specifiek platform. Wel is het een goede reden om je leverancier te vragen hoe hij deze regels invult, en dat te laten vastleggen.

Is lock-in dan een reden om het niet te doen?

Meestal niet. Vergelijk het eens met de alternatieven. Een standaardpakket bindt je aan de logica van het pakket en aan de leverancier van de aanpassingen. Maatwerk bindt je aan de ontwikkelaar die het schreef, en aan de code die alleen die persoon begrijpt. Lees ook onze beslishulp voor maatwerk, standaardpakket of low-code en het stuk over wanneer OutSystems wel en niet past.

De vraag is dus niet "lock-in ja of nee", maar wat afhankelijkheid je oplevert en wat het kost om er uit te komen. Een applicatie die in weken staat in plaats van in maanden, en die je proces echt automatiseert, kan die afhankelijkheid ruimschoots waard zijn. Onder de voorwaarde dat je de uitweg vooraf hebt bekeken.

Wat betekent dit voor jouw bedrijf?

1. Schrijf op waarvan je afhankelijk wordt. Loop de vier lagen langs: data, logica, kennis, contract. Geef per laag aan hoe erg het zou zijn als de leverancier morgen wegviel of zijn voorwaarden wijzigde.
2. Stel drie vragen aan elke leverancier, ook aan ons. Hoe krijg ik mijn data eruit, in welk formaat en binnen welke termijn? Wat gebeurt er met mijn omgeving na afloop van het contract? Kan ik dat schriftelijk krijgen?
3. Bewaar de specificatie zelf. Mockups, rollen, koppelingen en bedrijfsregels horen bij jou, niet bij het platform.
4. Plan een exit-test. Een keer per jaar een proefexport is een kleine investering die een grote verrassing voorkomt.

Wil je weten hoe dit er bij jouw situatie uitziet, of heb je een bestaand systeem waar je niet meer vanaf lijkt te kunnen? Neem contact met ons op. We kijken graag eerlijk mee, ook als de conclusie is dat low-code niet de juiste keuze is.