Je laat een prachtige applicatie bouwen en alles lijkt goed te gaan. Maar na twee jaar wil je overstappen naar een andere partij of zelf een developer aannemen. Dan komt de schok: de huidige leverancier zegt dat de code hun eigendom is, of dat je de software alleen mag gebruiken zolang je bij hen blijft. Welkom bij vendor lock-in.
Bij Serff geloven we in een radicaal andere aanpak. Wij vinden dat als jij betaalt voor de ontwikkeling, jij ook de volledige eigenaar moet zijn van het resultaat. In dit artikel leggen we uit welke vormen van lock-in er zijn, wat er juridisch echt geldt, en wat er in je contract hoort te staan.
Het korte antwoord
Betalen voor software maakt je in Nederland niet automatisch eigenaar: zonder schriftelijke overdracht blijft het auteursrecht bij de maker. Regel daarom vóór je tekent drie dingen: overdracht van de rechten op het maatwerk, doorlopende toegang tot de broncode en de Git-geschiedenis, en een exit-regeling. Dat kost je één gesprek en bespaart je mogelijk een herbouw.
De vijf vormen van lock-in
Vendor lock-in betekent dat je zo afhankelijk bent van een leverancier dat je niet kunt overstappen zonder onmogelijke kosten of operationele schade. Het zit zelden op één plek:
- Juridisch — het contract zegt dat de code eigendom van het bureau is, of geeft je alleen een gebruiksrecht dat stopt bij opzegging.
- Technisch — de software is gebouwd in een eigen, zelfbedacht framework dat alleen die leverancier begrijpt.
- Data — je gegevens zitten in een structuur waar je ze niet fatsoenlijk uit krijgt, of export kost apart geld.
- Infrastructuur — hosting, domeinnamen en de accounts bij externe diensten staan op naam van het bureau.
- Kennis — er is geen documentatie en geen tests, dus alle kennis zit in de hoofden van hun team.
De gouden kooi
De risico's van afhankelijkheid
Als je geen eigenaar bent van je code, loopt je bedrijf concrete risico's:
- Prijsstijgingen: de leverancier kan tarieven verhogen en je hebt geen alternatief.
- Faillissement: valt je leverancier om, dan staat je bedrijfsvoering letterlijk stil.
- Geen innovatie: je bent afhankelijk van hun roadmap en capaciteit, niet van je eigen prioriteiten.
- Waardevermindering: bij een bedrijfsovername of investeringsronde is software die je niet bezit geen asset. In een due diligence is dit een standaardvraag.
- Gijzeling bij conflict: zodra er een meningsverschil ontstaat, ligt je onderhandelingspositie bij de partij die de sleutels heeft.
Wie is er juridisch eigenaar?
Dit verrast de meeste ondernemers: betalen maakt je geen eigenaar. Naar Nederlands recht ligt het auteursrecht op software in beginsel bij de maker. Voor werk van eigen werknemers geldt een uitzondering, maar een extern bureau is geen werknemer. Zonder een schriftelijke akte waarin de rechten aan jou worden overgedragen, houdt het bureau die rechten — ook als de rekening volledig betaald is.
Let ook op het verschil tussen eigendom en een licentie. "U krijgt een eeuwigdurend gebruiksrecht" klinkt geruststellend, maar betekent dat je de software mag gebruiken, niet dat je hem mag laten aanpassen door iemand anders.
Dit is geen juridisch advies
Wat er in je contract hoort te staan
- Overdracht van auteursrecht op het voor jou gemaakte maatwerk, schriftelijk en expliciet.
- Toegang tot de broncode inclusief de volledige Git-geschiedenis — niet alleen een zip-bestand bij oplevering.
- Een exit-regeling: binnen welke termijn en in welk formaat wordt alles opgeleverd als je stopt, en wat kost dat?
- Documentatie: minimaal een installatiehandleiding waarmee een andere developer de applicatie draaiend krijgt.
- Accounts op jouw naam: domeinnaam, hosting, en de accounts bij betaaldiensten en externe API's.
- Onderhoud is geen gijzeling: onderhoudscontract en gebruiksrecht mogen niet aan elkaar gekoppeld zijn.
Een goed bureau heeft hier geen enkel probleem mee. Aarzeling bij deze punten is op zichzelf al informatie.
Checklist: hoe vrij ben je nu?
Loop deze zes vragen langs voor je huidige software. Kun je er meer dan twee niet met "ja" beantwoorden, dan is er werk aan de winkel:
- Kan ik vandaag bij de broncode, zonder toestemming te vragen?
- Staat er in mijn contract dat het auteursrecht aan mij is overgedragen?
- Staan domeinnaam en hosting op naam van mijn bedrijf?
- Is de software gebouwd in een gangbaar, publiek gedocumenteerd framework?
- Kan ik mijn data zelf exporteren in een bruikbaar formaat?
- Bestaat er documentatie waarmee een andere developer verder kan?
Weet je het niet zeker? Een software-audit beantwoordt precies deze vragen, ook als je nog bij je huidige partij zit.
Nul lock-in bestaat niet
Eerlijk is eerlijk: volledige onafhankelijkheid is een illusie. Kies je Laravel, dan ben je afhankelijk van dat ecosysteem. Gebruik je Mollie voor betalingen, dan zit daar een koppeling aan vast. Dat is geen probleem — het is een bewuste afhankelijkheid met een open standaard eronder, waar je binnen redelijke tijd uit kunt stappen.
Het verschil met echte lock-in zit in de vraag: kan ik hier weg als ik dat wil, tegen kosten die in verhouding staan? Bij een gangbaar framework en eigen accounts is het antwoord ja. Bij een zelfbedacht systeem op andermans server is het antwoord nee.
Onze visie bij Serff
Wij bouwen software voor de lange termijn. Dat betekent transparante afspraken over eigendom, het gebruik van open standaarden en Laravel als fundament, zodat elke goede developer het kan overnemen. Wij geloven dat onze klanten bij ons blijven omdat we goed werk leveren, niet omdat ze contractueel vastzitten.
"Sinds we eigenaar zijn van onze eigen broncode, voelen we ons weer echt de baas over ons bedrijf. We zijn niet meer bang voor wat onze leverancier besluit."
Veelgestelde vragen
Wat is vendor lock-in?
Vendor lock-in betekent dat je zo afhankelijk bent van één leverancier dat overstappen praktisch onmogelijk is zonder onaanvaardbare kosten of bedrijfsschade. Dat kan komen door het contract, maar net zo goed door techniek die niemand anders kan overnemen, data die je er niet uit krijgt of kennis die alleen bij die leverancier zit.
Ben ik automatisch eigenaar van software die ik heb betaald?
Nee. Naar Nederlands recht ligt het auteursrecht op software in beginsel bij de maker, niet bij de opdrachtgever die betaalt. Zonder een schriftelijke akte waarin de rechten aan jou worden overgedragen, houdt het bureau de rechten — ook als je de volledige rekening hebt voldaan.
Wat moet er in mijn contract staan?
Minimaal: schriftelijke overdracht van het auteursrecht op het maatwerk, doorlopende toegang tot de broncode en de Git-geschiedenis, een exit-regeling met opleverformaat en termijn, afspraken over documentatie, en helderheid over wie de hosting, domeinnamen en accounts bij externe diensten op naam heeft staan.
Wat is een broncode-escrow en heb ik dat nodig?
Bij een escrow wordt de broncode bij een onafhankelijke derde in bewaring gegeven, die hem vrijgeeft als de leverancier failliet gaat of zijn verplichtingen niet nakomt. Krijg je gewoon toegang tot de repository en ben je eigenaar, dan is escrow overbodig.
Betekent eigenaar zijn van de code dat ik zomaar kan overstappen?
Het is een voorwaarde, geen garantie. Overstappen lukt alleen echt als de code in een gangbaar framework is geschreven, er documentatie en tests zijn, en je toegang hebt tot de hosting en de gekoppelde accounts.
Is lock-in helemaal te vermijden?
Nee, en dat hoeft ook niet. Elke keuze voor een framework, hostingpartij of betaaldienst schept enige afhankelijkheid. Het doel is niet nul afhankelijkheid, maar afhankelijkheid die je bewust kiest en waar je binnen redelijke tijd en kosten uit kunt stappen.
Wil jij ook écht eigenaar zijn?
Laten we bespreken hoe we jouw software-onafhankelijkheid vastleggen.
Bespreek jouw project