Vendor lock-in

Vendor lock-in voorkomen vóór je tekent

Broncode bij de leverancier, hosting op zijn account, SaaS-tools waar je niet aan kunt: wegkomen wordt een onderhandeling in plaats van een keuze. Vier voorzorgen die voorkomen dat je commercieel gegijzeld raakt.

Check je offerte op lock-in Of laat een expert kijken

Vier plekken waar lock-in ontstaat

1. Broncode-eigendom

De code die specifiek voor jou is gebouwd hoort van jou te zijn. In een offerte hoort dat letterlijk te staan, met benoemd op welke account de repository (GitHub, GitLab, etc.) komt. "Wij leveren het op" is niet hetzelfde als "jij wordt eigenaar". Zonder expliciete vermelding kan de leverancier later claimen dat hij het auteursrecht houdt, en heb je voor doorontwikkeling alleen hém als optie.

2. Hosting en domeinen op naam

Klassieke valkuil: de leverancier registreert je domein "voor het gemak" op zijn eigen TransIP-account, en zet je site bij zijn AWS-omgeving. Bij vertrek moet je het domein terugkopen of overdragen onder hoge tijdsdruk, en de hosting opnieuw inrichten op een eigen account. Voorkomen: zelf registreren, leverancier alleen toegang geven. Of overdracht eisen vóór live-gang.

3. SaaS-tools waar het systeem op leunt

Moderne websites en applicaties draaien zelden alleen op eigen code. Er zit een CMS-abonnement onder, een zoekdienst (Algolia, Meilisearch), een AI-API (OpenAI, Anthropic), een betaaldienst (Mollie, Stripe), een mailprovider (Postmark, Resend), analytics, beeldverwerking en formulier-builders. Als die op de leverancier-account staan, ben je dubbel afhankelijk: van de SaaS-leverancier én van de bouwer die je credentials niet wil geven.

Vraag in de offerte: welke SaaS-diensten zijn kritisch, op wiens naam staan ze, en wat is het migratie-pad als er een prijs-verhoging komt of de leverancier stopt.

4. Geen exit-clausule

Wat gebeurt er als jullie uit elkaar gaan? Een exit-clausule beschrijft: overdracht van credentials, repository-toegang, hosting-accounts en domeinen; archivering of vernietiging van data; en hoeveel tijd dat in beslag mag nemen. Zonder clausule kan een leverancier maanden traineren, of je dwingen tot een "afkoop-fee". Met clausule weet je vooraf wat je krijgt.

Wat je je leverancier kunt vragen

Een handvol concrete vragen om voor te tekent te stellen. Veel goede leveranciers vinden het prima om dit op papier te zetten; degenen die er omheen draaien zeggen iets over hoe het traject zich zal ontwikkelen.

  • Wie wordt eigenaar van de broncode na oplevering, en kan dat schriftelijk worden vastgelegd?
  • Wordt de repository opgeleverd onder mijn account, of bij jullie?
  • Op wiens account komen de hosting, het domein, de DNS en de externe SaaS-diensten?
  • Welke SaaS-tools zijn kritisch voor het systeem, en wat is jullie advies als zo'n leverancier z'n prijs verhoogt of stopt?
  • Hoe ziet de overdracht eruit als de samenwerking eindigt? Termijn, formaat, kosten?
Veelgestelde vragen

Vragen over vendor lock-in en broncode-eigendom

Wat is vendor lock-in bij een website of softwareproject?

Vendor lock-in betekent dat je commercieel of technisch afhankelijk bent geworden van één specifieke leverancier en niet zonder hoge kosten weg kunt. Bij digitale projecten zit lock-in vaak in: broncode op de leverancier-account, hosting en domein op zijn naam, een CMS waar alleen hij in kan, AI-API's waarop de prijs eenzijdig wordt verhoogd, of SaaS-tools waarvan de leverancier sub-administrator is.

Hoe voorkom ik vendor lock-in vooraf?

Vraag voor je tekent vier dingen schriftelijk: 1) wie wordt eigenaar van de broncode na oplevering, 2) op wiens account komt de hosting en het domein, 3) welke externe SaaS-diensten zijn kritisch en is er een uitwisselbaar alternatief, en 4) wat is de procedure als de samenwerking eindigt (exit-clausule met overdracht van credentials). Staat het er niet, vraag het na. Staat het er nadat je hebt nagevraagd nog steeds niet, dan is dat een signaal.

Wie hoort eigenaar te zijn van de broncode?

Standaard hoort de opdrachtgever (jij) eigenaar te worden van de broncode na betaling. Dat moet expliciet in de offerte of overeenkomst staan, niet alleen geïmpliceerd door "wij leveren het op". Open-source componenten in het project hebben hun eigen licenties (MIT, GPL, etc.) en blijven onder die licenties vallen, maar het maatwerk dat de leverancier specifiek voor jou bouwt hoort van jou te zijn, met de bijbehorende repository onder jouw beheer.

Wat doe ik met hosting en domein die op naam van de leverancier staan?

Vraag overdracht. Domeinen kunnen gratis overgedragen worden naar jouw eigen registrar (TransIP, Mijndomein, Cloudflare, etc.). Hosting-accounts (bij AWS, Hetzner, etc.) kun je ofwel laten migreren naar een eigen account, of de leverancier overschrijven als account-eigenaar. Doe het bij voorkeur tijdens een lopende samenwerking, want bij conflict heeft de leverancier de sleutels.

Wat als een SaaS-leverancier waar mijn systeem op leunt z'n prijs verhoogt?

Dat is precies het risico van SaaS-afhankelijkheid. Een AI-API die nu €50 per maand kost kan over een jaar €500 of stopgezet zijn. Een goede offerte benoemt deze kritische afhankelijkheden vooraf, schat de migratie-kosten in, en stelt waar mogelijk uitwisselbare alternatieven voor (bv. Mollie of Stripe; OpenAI of Anthropic; Algolia of Meilisearch). Zonder die voorbereiding ben je commercieel overgeleverd aan elke prijswijziging.

Loop je offerte langs

Check op de vier lock-in-risico's en meer

De gratis zelf-test heeft een sectie Eigendom en intellectueel eigendom plus een sectie Hosting en infrastructuur, samen tien vragen die de lock-in-risico's blootleggen. Twintig minuten, in je eigen omgeving.

Begin de zelf-test