Vendor lock-in is de situatie waarin je zo afhankelijk bent van één leverancier dat overstappen naar een alternatief bijna onmogelijk of onevenredig duur wordt. Bij software ontstaat dat vaak ongemerkt: de broncode is niet van jou, de documentatie ontbreekt of je data zit vast in een gesloten systeem. Met goede afspraken vooraf en een paar bewuste technische keuzes houd je de regie.
Dit artikel is praktische uitleg, geen juridisch advies. Laat contracten bij twijfel toetsen door een jurist.
Wat is vendor lock-in?
“Vendor” is Engels voor leverancier, “lock-in” voor opgesloten zitten. Er is sprake van vendor lock-in als de kosten of de moeite om over te stappen zo hoog zijn dat je in de praktijk niet meer kunt kiezen. Je blijft dan bij een bepaalde leverancier, niet omdat die de beste is, maar omdat weggaan te veel pijn doet. De klant is afhankelijk geworden van de leverancier, in plaats van andersom.
Dat merk je pas als het ertoe doet. De leverancier verhoogt zijn tarieven, er komen geen updates meer, de doorontwikkeling stokt, het contact loopt stroef of de leverancier gaat failliet. Wie dan geen toegang heeft tot de broncode, de servers en de data, staat met lege handen.
Leveranciersafhankelijkheid is niet altijd slecht
Enige afhankelijkheid hoort bij elke samenwerking. Kies je voor een standaard softwarepakket, een low-code platform of een clouddienst, dan krijg je snelheid en gemak terug. Het gaat erom dat je die afhankelijkheid bewust kiest, weet wat overstappen zou kosten en een uitweg hebt als het nodig is.
Drie vormen van vendor lock-in bij software
Bij een softwareleverancier of bureau
Bij maatwerk zit het risico vooral in de afspraken en in de techniek die de leverancier kiest. Typische vormen van lock-in bij een bureau:
- de broncode is niet van jou, omdat het auteursrecht nooit is overgedragen;
- het bureau heeft een eigen, gesloten framework of CMS waar alleen hun developers mee kunnen werken;
- de code staat in een repository waar alleen de leverancier toegang toe heeft;
- de hosting en domeinnaam staan op naam van de leverancier.
Auteursrechtelijke bescherming van software
Laat je software in opdracht bouwen, dan is de vraag wie eigenaar is van de broncode. Software valt onder het auteursrecht: de Auteurswet noemt computerprogramma’s uitdrukkelijk als beschermd werk (artikel 10). Die auteursrechtelijke bescherming geeft de rechthebbende het recht om te bepalen wie de software mag verveelvoudigen, aanpassen en distribueren.
Volgens artikel 7 van de Auteurswet is bij software die een werknemer in loondienst maakt de werkgever de maker, tenzij anders is afgesproken. Maar een extern bureau is geen werkgever van jou. Het auteursrecht op het computerprogramma blijft dan bij het bureau, tenzij het is overgedragen. Volgens artikel 2 van de Auteurswet gaat die overdracht via een daartoe bestemde akte; een mondelinge afspraak of een betaalde factuur is niet genoeg.
Zonder overdracht heb je hooguit een gebruiksrecht. Wil je later met andere partijen verder, dan heb je toestemming nodig van de auteursrechthebbende. Krijg je bovendien alleen de objectcode (de uitvoerbare versie) en niet de broncode, dan kun je de software wel gebruiken maar niet laten aanpassen.
Bij platforms en low-code
Bij low-code platforms en SaaS-software ben je per definitie afhankelijk van het platform. Je applicatie draait op hun techniek, met hun licenties en hun voorwaarden. Dat kan een prima keuze zijn, zolang je weet wat je kunt meenemen als je stopt. Kun je je data exporteren? Kun je de logica en functionaliteiten van je applicatie terugvinden in een vorm die een ander kan herbouwen? En wat gebeurt er met je kosten als het aantal gebruikers groeit? Meer over die afweging lees je in low-code of maatwerk.
In de cloud
Bij cloudhosting ontstaat lock-in als je applicatie zwaar leunt op diensten die alleen één aanbieder heeft, zoals een eigen database, wachtrij of serverless functies. Overstappen betekent dan deels herschrijven. Ook data terughalen kost soms geld en tijd. De Europese Data Act, die sinds 12 september 2025 van toepassing is (per oktober 2026), bevat regels om overstappen tussen cloudaanbieders makkelijker te maken. Dat helpt, maar vervangt goede eigen keuzes niet.
| Vorm | Waar de afhankelijkheid zit | Belangrijkste vraag |
|---|---|---|
| Softwareleverancier | Eigendom broncode, toegang, kennis | Mag en kan een ander verder met de code? |
| Low-code of SaaS | Platform, licenties, dataformaat | Wat neem je mee als je stopt? |
| Cloud | Specifieke diensten, data-export | Hoeveel moet je herschrijven om te verhuizen? |
Signalen dat je vastzit aan je leverancier
Herken je een of meer van deze signalen, dan is het tijd om je positie te bekijken:
- Je hebt geen toegang tot de broncode of weet niet waar die staat.
- Hosting, domeinnaam en accounts staan op naam van de leverancier, niet op die van jouw organisatie.
- Er is geen documentatie van de architectuur, de installatie of de koppelingen.
- Alleen één developer kent het systeem. Valt die weg, dan ligt alles stil.
- De techniek is onbekend of eigen ontwikkeld, waardoor je geen alternatief vindt dat het kan overnemen.
- Je krijgt je data niet in een bruikbaar formaat terug, of alleen tegen hoge kosten.
- Het contract zegt niets over beëindiging en de overdracht bij een exit.
Contractueel vendor lock-in voorkomen
De meeste lock-in is te voorkomen in de overeenkomst, voordat de eerste regel code is geschreven. Neem in elk geval deze punten op.
Eigendom broncode en intellectuele eigendomsrechten
Leg vast dat de intellectuele eigendomsrechten op de maatwerkcode aan jou worden overgedragen: de broncode, het ontwerp en de documentatie die in jouw opdracht zijn gemaakt, en dat die overdracht ook formeel wordt geregeld. Let op de uitzonderingen: een bureau gebruikt vaak open source software en eigen standaardcomponenten. Daarop krijg je meestal geen eigendom, maar wel een gebruiksrecht. Zorg voor eeuwigdurende licenties die overdraagbaar zijn, zodat een andere partij er ook mee verder mag. Zo is de intellectuele eigendom van het geheel helder. Bij open source software gelden de voorwaarden van de betreffende licentie.
Krijg je geen eigendom maar een licentie, bijvoorbeeld bij een standaardproduct, kijk dan naar de reikwijdte: mag je de software laten aanpassen door derden, en wat gebeurt er als de leverancier stopt?
Toegang tot repository en hostingaccounts
Laat de code vanaf dag één in een repository staan waar jouw organisatie eigenaar of in elk geval beheerder van is. Hetzelfde geldt voor de hostingaccounts, de domeinnaam, de DNS en accounts bij externe diensten zoals e-mail of betalingen. Je leverancier krijgt toegang; jij houdt de sleutels.
Documentatie
Spreek af welke documentatie wordt opgeleverd en bijgehouden: een overzicht van de architectuur, installatie-instructies, de koppelingen met andere software en de afspraken over de omgevingen. Zonder documentatie is de broncode wel van jou, maar kost het een nieuwe partij veel tijd om ermee aan de slag te gaan.
Escrow
Bij standaardsoftware of SaaS waar je de broncode niet krijgt, kan een escrowregeling helpen. Een onafhankelijke partij bewaart dan de broncode en geeft die vrij als de leverancier bijvoorbeeld failliet gaat of zijn verplichtingen niet nakomt. Escrow werkt alleen als de gedeponeerde code actueel en compleet is, dus spreek af hoe vaak die wordt bijgewerkt.
Exitclausule
Leg vast hoe de samenwerking eindigt: welke opzegtermijn geldt, dat de leverancier meewerkt aan de overdracht naar een andere partij, in welk formaat je data terugkrijgt en tegen welke voorwaarden. Een exit regel je liever als de verhoudingen goed zijn dan als ze al onder druk staan.
Technische keuzes die je vrijheid geven
Contractuele afspraken zijn het fundament. De techniek bepaalt of een overstap in de praktijk ook haalbaar is.
- Bekende frameworks. Een applicatie in een veelgebruikt framework zoals Symfony of Laravel kan door veel developers worden overgenomen. Een eigen framework van de leverancier niet.
- Open standaarden. Gebruik gangbare formaten en protocollen voor data en koppelingen, zoals REST API’s, JSON en standaard SQL-databases. Dat bevordert ook de interoperabiliteit met andere software.
- Data-export. Zorg dat je klantgegevens en andere data altijd in een gangbaar formaat kunt exporteren, zonder tussenkomst van de leverancier.
- Cloud met een uitweg. Gebruik de diensten van een cloudaanbieder bewust. Draait je applicatie in containers en met een standaard database, dan kun je verhuizen naar een andere aanbieder of on premise.
- Geautomatiseerde tests en een vaste deploy-procedure, zodat een nieuwe partij veilig wijzigingen kan doorvoeren.
Vendor lock-in en aanbesteden
Organisaties die moeten aanbesteden, zoals overheden en onderwijsinstellingen, hebben extra last van vendor lock-in. Zit je vast aan één leverancier, dan is er bij een nieuwe aanbesteding in de praktijk geen echt alternatief. Neem eisen over eigendom van de broncode, documentatie, open standaarden en de exit daarom al op in de aanbestedingsdocumenten. Dat geldt ook voor bedrijven die software inkopen zonder aanbesteding: je onderhandelingspositie is het sterkst vóór de handtekening.
Wat als je al vastzit?
Zit je al vast aan een leverancier of een systeem, begin dan met inventariseren: wat staat er in het contract over auteursrecht en beëindiging, waar staat de broncode en welke accounts heb je zelf in handen? Vraag in een goede verhouding om toegang en documentatie, voordat je de samenwerking ter discussie stelt. Daarna kun je een overstap plannen. Een stappenplan vind je in onze checklist voor het overnemen van een applicatie. Wil je dat een ander team het beheer overneemt, kijk dan bij applicatie overnemen.
Hoe wij met eigendom omgaan
Bij Inesta is de code altijd eigendom van de klant. We bouwen maatwerk in bekende frameworks als Symfony en Laravel, zodat ook een andere partij ermee verder kan. Waar low-code beter past, zoals bij interne tools in Retool, bespreken we vooraf wat die platformkeuze betekent voor je afhankelijkheid. Wil je maatwerk software laten maken zonder vast te zitten aan je leverancier? Vertel ons wat je wilt bouwen; je krijgt binnen één werkdag reactie.