Bijna elke directie die bij ons aanklopt met een overnametraject zegt dezelfde zin: “we willen niet nog een keer vastzitten.” Vendor lock-in is een reëel risico, maar het ontstaat zelden door een gemene clausule. Het ontstaat door keuzes die bij de start onschuldig leken.
Wat lock-in werkelijk is
Lock-in is niet dat je niet wég mag. Lock-in is dat vertrekken zo duur of zo riskant is dat je het niet doet. Dat kan op vier manieren ontstaan: juridisch (de code is niet van jou), technisch (niemand anders begrijpt of draait het), operationeel (alleen zij weten hoe het werkt) en via data (je krijgt je gegevens er niet bruikbaar uit).
Van die vier is de juridische het makkelijkst dicht te timmeren en tegelijk de minst voorkomende. De andere drie zijn het echte probleem.
Zes vragen die je vooraf stelt
Stel ze in het eerste gesprek. Een goede leverancier antwoordt zonder aarzelen:
- Van wie zijn broncode, documentatie en data, en waar staat dat?
- Op welke technologie bouwen jullie, en hoeveel developers in Nederland kunnen daarmee overweg?
- Waar draait de omgeving, en kan ik die overnemen zonder jullie account?
- Hoe krijg ik mijn data eruit, in welk formaat, en kan ik dat vandaag testen?
- Wat gebeurt er als jullie omvallen of het contract eindigt? Is er een exitprocedure?
- Hoe lang heeft een nieuwe partij nodig om dit over te nemen, en wat is daarvoor nodig?
Technische lock-in is de sluipende variant
Een exotische stack, een eigen framework of een low-code platform waar maar één partij mee werkt: dat zijn de dingen die je later vastzetten. Niet omdat het niet werkt, maar omdat de markt van mensen die het kan overnemen te klein is.
Daarom bouwen wij bewust met breed gedragen technologie: React en TypeScript aan de voorkant, .NET of Node aan de achterkant, cloud-native hosting. Niet omdat het het spannendst is, maar omdat elke competente developer er later mee verder kan.
Wat er in de afspraken hoort
Leg minimaal drie dingen vast: dat broncode, documentatie en data jouw eigendom zijn; dat je bij beëindiging een volledige, werkende overdracht krijgt inclusief een redelijke overdrachtsperiode; en dat de documentatie actueel wordt gehouden, niet alleen bij oplevering.
Bij ons staat dat standaard in het contract. Dat klinkt genereus, maar het is vooral eerlijk: wij willen dat klanten blijven omdat het werkt, niet omdat weggaan te duur is.
Al vastgelopen bij je huidige partij?
Dat komt vaker voor dan je denkt, en het is zelden onoplosbaar. We beginnen met een technische audit: hoe gezond is de code, welke risico’s zitten erin en wat is de logische volgende stap. Daarna kunnen we beheer en doorontwikkeling overnemen. Herbouwen is lang niet altijd nodig.