Je software werkt, je leverancier levert, en toch knaagt er iets. Elke wijziging loopt via één partij, de tarieven stijgen jaarlijks, en niemand binnen je organisatie weet precies hoe het systeem in elkaar zit. Dat is geen pech, dat is vendor lock-in, en het is vrijwel altijd het gevolg van keuzes die jaren eerder zijn gemaakt.
Vendor lock-in voorkomen is het vooraf vastleggen van eigendom, dataportabiliteit en open koppelingen, zodat je van leverancier kunt wisselen zonder je systeem opnieuw te moeten bouwen. Het is geen technische discussie achteraf, maar een inkoopbeslissing die je neemt voordat de eerste regel code wordt geschreven.
Deze gids laat zien welke vormen van lock-in bestaan, hoe je herkent dat je er al in zit, en met welke afspraken en technische keuzes je je vrijheid behoudt.
Wat is vendor lock-in precies?
Vendor lock-in is de situatie waarin de kosten van het verlaten van een leverancier zo hoog zijn dat je blijft, ook als je liever weg zou gaan. Die kosten zijn niet alleen financieel: ze zitten in tijd, in risico, en in kennis die je zelf niet hebt.
Belangrijk: niet elke afhankelijkheid is lock-in. Je bent altijd afhankelijk van iemand, en een goede langjarige samenwerking met een bouwpartner is waardevol. Het verschil zit in de vraag wat er gebeurt als die samenwerking eindigt. Kun je binnen een paar maanden verder met een andere partij, dan is er sprake van gezonde afhankelijkheid. Ben je maanden aan werk en een fors budget verwijderd van een alternatief, dan zit je vast.
Dat onderscheid is geen kwestie van wantrouwen richting je huidige leverancier. Ook een uitstekende partner kan worden overgenomen, zijn prijzen verhogen, van koers veranderen of failliet gaan. Je regelt dit dus niet omdat je een conflict verwacht, maar omdat je organisatie ook moet doorlopen als het misgaat. Diezelfde logica bepaalt de bredere afweging tussen software bouwen of kopen: hoe dichter een systeem bij je kernproces komt, hoe minder afhankelijkheid je erin wilt accepteren.
Welke vormen van lock-in bestaan er?
Lock-in is geen enkel fenomeen maar een stapel van vijf verschillende bindingen. De meeste organisaties dekken er één af (meestal de broncode) en lopen op de andere vier alsnog vast.
| Vorm van lock-in | Waar het je vastzet | Hoe je het voorkomt |
|---|---|---|
| Datalock-in | Je data zit in een gesloten formaat of database | Recht op volledige export in open formaat, contractueel |
| Codelock-in | De leverancier bezit de broncode | Eigendomsoverdracht bij oplevering plus escrow |
| Platformlock-in | De app draait alleen op één platform of no-code tool | Open standaarden, containers, standaard frameworks |
| Kennislock-in | Alleen de leverancier begrijpt het systeem | Documentatie en overdracht als opleveringseis |
| Contractuele lock-in | Lange looptijd, geen exit-bepaling, hoge boetes | Opzegtermijn, transitieplicht, vaste transitietarieven |
De meest onderschatte van de vijf is kennislock-in. Je kunt eigenaar zijn van elke regel code en toch niet weg kunnen, simpelweg omdat er geen documentatie is en geen enkele andere ontwikkelaar het systeem in redelijke tijd kan overnemen. Broncode zonder uitleg is juridisch eigendom zonder praktische waarde.
Platformlock-in verdient ook aandacht, omdat die vaak sluipenderwijs ontstaat. Zie onze vergelijking van no-code versus maatwerk: een no-code platform brengt je snel live, maar wat je bouwt is meestal niet meeneembaar. Zolang de toepassing klein en vervangbaar blijft, is dat een verdedigbare keuze. Wordt het een kernproces, dan koop je een risico in.
Hoe herken je dat je al vastzit?
Lock-in kondigt zich zelden aan. Deze signalen wijzen erop dat je positie zwakker is dan je denkt:
- Elke wijziging loopt via één partij, en jij hebt geen zicht op wat een aanpassing werkelijk kost aan werk.
- Je krijgt geen bruikbare export. Een pdf of een schermafdruk is geen data-export; een gestructureerde database-dump of een gedocumenteerde API wel.
- Er is geen actuele documentatie van de architectuur, de koppelingen en de deploystraat.
- Niemand weet zeker wie de broncode bezit. Als je het antwoord niet binnen vijf minuten in een contract kunt aanwijzen, is het antwoord meestal: niet jij.
- Het contract heeft geen exit-bepaling en verlengt stilzwijgend.
- De prijs stijgt jaarlijks zonder dat de dienst meegroeit, en je accepteert dat omdat het alternatief duurder voelt.
Herken je drie of meer punten, dan is dit geen theoretisch risico maar een openstaande rekening. Hoe je daar vervolgens uit komt, staat in onze gids over een softwareleverancier wisselen.
[ TIJDWINST ]
Bespaar 6 uur per week op het handmatig overtypen van gegevens tussen systemen die niet met elkaar kunnen praten
Welke afspraken leggen je vrijheid vast?
Vrijheid regel je op papier, voordat er gebouwd wordt. Vijf bepalingen doen het meeste werk.
Ten eerste eigendom van de broncode: leg vast dat alle intellectuele eigendomsrechten op maatwerk bij oplevering en betaling naar jou overgaan, inclusief de infrastructuurconfiguratie. Ten tweede dataportabiliteit: je hebt op elk moment recht op een volledige export van je data in een open, gedocumenteerd formaat, te leveren binnen een afgesproken termijn en tegen een vooraf vastgesteld tarief.
Ten derde broncode-escrow voor situaties waarin de leverancier failliet gaat of niet meer levert, met heldere afgiftecriteria. Ten vierde een exit-regeling met een transitieplicht: de leverancier werkt aantoonbaar mee aan de overdracht naar een opvolger, tegen een tarief dat nu al vaststaat en niet op het moment van vertrek wordt bepaald. En ten vijfde een documentatie-eis: een oplevering geldt pas als opgeleverd wanneer de bijbehorende technische documentatie er is.
Deze punten horen thuis in elke opdracht die verder gaat dan een eenvoudige website. In onze gids over maatwerk software laten bouwen staat hoe je ze in een offertetraject naar boven krijgt, voordat je tekent.
Welke technische keuzes houden je vrij?
Naast het contract bepaalt de architectuur hoeveel vrijheid je overhoudt. Vier keuzes tellen het zwaarst.
Open formaten en standaarden. Data in PostgreSQL, JSON, CSV of een gedocumenteerd API-schema volgens OpenAPI kan altijd mee. Data in een gesloten, leverancierseigen structuur niet.
Standaard technologie boven een niche-stack. Een applicatie in TypeScript, Python of .NET kan door duizenden ontwikkelaars worden overgenomen. Een systeem in een zelfbedacht framework of een obscure taal kan dat niet, en die schaarste is precies waar lock-in van leeft.
Portabele infrastructuur. Een applicatie in containers, met de configuratie vastgelegd in code, kun je verplaatsen naar een andere hostingpartij. Bouw je diep op de exclusieve diensten van één cloudleverancier, dan is verhuizen een herbouwproject.
Open modellen bij AI. Bij AI-toepassingen zit de afhankelijkheid niet alleen in software maar ook in het model en de prijs per token. Modellen met open gewichten die je zelf kunt draaien, geven je die controle terug; onze pijler over lokale AI voor bedrijven behandelt wanneer dat verstandig is.
Wat kost lock-in je in de praktijk?
Lock-in is zelden één grote rekening. Het is een reeks kleine, die je jaar na jaar betaalt: prijsverhogingen die je niet kunt weigeren, meerwerktarieven zonder marktvergelijking, en de uren die je team kwijt is aan workarounds voor functionaliteit die er niet in mag.
Daar bovenop komt de bedragen die je op enig moment alsnog moet uitgeven. Een gedwongen migratie of herbouw kost vaak een bedrag in dezelfde orde van grootte als de oorspronkelijke bouw, plus de doorlooptijd waarin je organisatie op twee systemen tegelijk draait. Die cijfers zijn indicatief en verschillen per situatie, maar de verhouding klopt: voorkomen is structureel goedkoper dan losmaken.
Het echte verlies is bovendien niet financieel maar strategisch. Een organisatie die haar kernsysteem niet kan aanpassen, kan haar proces niet aanpassen. Daarmee wordt je snelheid als bedrijf begrensd door de agenda en de prijslijst van iemand anders.
Conclusie: vrijheid regel je vooraf
Vendor lock-in voorkomen kost bij de start weinig en levert jarenlang op. Dek de vijf vormen af (data, code, platform, kennis en contract), leg eigendom, export, escrow, exit en documentatie schriftelijk vast, en kies voor open formaten, standaard technologie en portabele infrastructuur.
Doe je dat, dan blijft je leverancier een leverancier in plaats van een poortwachter, en blijf je zelf eigenaar van het systeem waar je bedrijf op draait. Wij leveren maatwerk software standaard met broncode-eigendom, documentatie en een exit-regeling, juist omdat een klant die kan vertrekken de beste reden is om goed te blijven leveren.