Je laat custom software bouwen en op papier krijg je “de code mee”. Maar twee jaar later wil je overstappen naar een andere partij, en blijkt dat de helft van het systeem op een eigen agency-platform draait, de deploy-pipeline een black box is, en niemand weet hoe je de productie-database eruit krijgt. Klassieke vendor lock-in, en het gebeurt vaker dan ondernemers denken. Dit artikel legt uit wat code-eigendom juridisch en praktisch betekent, hoe vendor lock-in ontstaat, welke rode vlaggen in een offerte staan en welke vragen je moet stellen voor je tekent.
Wat is code-eigendom precies?
Code-eigendom is een combinatie van juridische rechten en praktische toegang. Juridisch gaat het om intellectueel eigendom: de auteursrechten op de broncode, de databasestructuur, de configuraties en de bijbehorende documentatie. In Nederland ligt het auteursrecht standaard bij de maker, dus zonder expliciete overdracht in het contract blijft het bij de developer of het bureau.
De praktische kant is minstens zo belangrijk. Je hebt niets aan een papieren overdracht als de Git-repository onder een agency-account staat waar jij niet bij kunt, de productie-server bij een leverancier draait waar jij geen root-toegang hebt, en de OAuth-tokens voor je integraties op iemand anders zijn naam zijn geregistreerd. Lees voor de bredere context onze gids over custom software laten bouwen.
Wat is vendor lock-in en hoe ontstaat het?
- Proprietary frameworks. Het bureau heeft een eigen platform of engine waar jouw applicatie bovenop draait.
- Agency-hosting. Het systeem draait op infrastructuur die alleen het bureau beheert.
- Eigen tooling. Custom build-tools of een eigen CMS dat alleen bij dit bureau bekend is.
- Abstracted code. De code zit vol verwijzingen naar interne bibliotheken die niet in de repository staan.
- Account-eigendom. Alle externe accounts staan op naam van het bureau. Bij overdracht moet alles opnieuw worden ingesteld.
Vier varianten van vendor lock-in bij agencies
| Variant | Hoe ziet het eruit? | Waarom is het lock-in? | Wat te vragen? |
|---|---|---|---|
| Proprietary framework | Bureau bouwt op een eigen engine met marketing-naam | Geen externe documentatie, niemand anders kan eraan werken | Mag ik de naam googlen en de docs publiek zien? |
| Eigen hosting-stack | Applicatie draait op infra die alleen het bureau beheert | Migreren betekent re-deployen plus DNS-cutover plus database-export | Krijg ik root-toegang en kan ik een productie-backup downloaden? |
| Private dependencies | Code verwijst naar pakketten op een private registry | Zonder die packages bouwt de code niet | Staan alle dependencies publiek? |
| Visual builders zonder export | CMS of dashboards in een no-code tool zonder code-export | De configuratie zit in de tool, niet in jouw repo | Welk deel zit in code, welk deel in een tool? |
Hoe herken je vendor lock-in in een offerte?
- “Wij hosten het voor je” zonder optie om zelf te hosten. Hosting moet een keuze zijn.
- “Op ons platform” of “op onze suite”. Een marketing-naam voor het onderliggende framework. Vraag wat het werkelijke open-source framework eronder is.
- Geen vermelding van Git-repository. In 2026 moet elke offerte specificeren welke versie-controle wordt gebruikt.
- Maandelijkse licentiekosten naast het bouwbudget. Een verkapte licentie op je eigen software.
- Geen IE-overdracht in de algemene voorwaarden. Lees onze algemene voorwaarden als voorbeeld van hoe IE-overdracht expliciet wordt benoemd.
- “Wij regelen de accounts voor je” zonder transferplan. Alles op naam van het bureau is een tijdbom.
- Geen handover-sessie in de scope. Een professioneel project sluit af met een overdracht.
Wat krijg je bij TopDevs standaard?
- Git-repository onder jouw account. Wij maken vanaf dag een een GitHub of GitLab repository aan onder jouw bedrijfsaccount.
- README en deployment-document. Bij elke oplevering een README met architectuur, dependencies, lokale draaiing en deployment-stappen.
- Alle credentials in jouw password manager. API-keys, hosting-credentials, database-wachtwoorden, OAuth-tokens. Niets blijft op onze laptops staan.
- Handover-sessie van 90 minuten. Live-sessie waarin we de architectuur en deploys doorlopen, met opname.
Dit geldt voor kleine automations (vanaf €495) net zo goed als voor custom platforms van €15.000.
Wanneer is vendor lock-in acceptabel?
- Echte SaaS-producten. HubSpot, Salesforce of Pipedrive. Maar dat is een licentie op een commercieel product.
- Gespecialiseerde tools met sterke markpositie. Vercel of Supabase. Bewust gekozen lock-in in ruil voor ontwikkel-snelheid.
- Markt-standaard frameworks. Een Next.js- of Django-app is “vast” aan dat framework, maar de hele wereld kent het.
Wat zegt de juridische kant?
In Nederland is auteursrecht op software geregeld in artikel 10 lid 1 sub 12 van de Auteurswet. Bij opdrachtwerk gaat het auteursrecht niet automatisch over. Voor de open-source definities is opensource.org het referentiepunt.
- IE-overdracht. Een expliciete bepaling dat alle intellectuele eigendomsrechten bij oplevering overgaan naar de opdrachtgever.
- Source-escrow optie. Voor grotere projecten kan een escrow-regeling zinvol zijn.
- Onderscheid licentie versus eigendom. De algemene voorwaarden moeten expliciet maken wat eigendom wordt versus wat licentie blijft.
Voor EU-regels rond IE-software is de EU Intellectual Property Office een goede ingang. Voor algemene definities en best practices rond vrije software is de Free Software Foundation Europe een autoriteit.
Hoe migreer je weg bij vendor lock-in?
- Stap 1: inventariseer wat van wie is. Lijst alle systemen, accounts en services.
- Stap 2: vraag formeel om code en data. Schriftelijk verzoek met deadline van 10 werkdagen.
- Stap 3: parallel een nieuwe omgeving opbouwen. DNS-cutover komt pas wanneer alles werkt.
- Stap 4: data-migratie en regression-tests. Test-suite om te controleren dat alle workflows werken.
- Stap 5: cutover en oude omgeving afsluiten. 30 dagen veilige terugval, daarna pas afsluiten.
Welke vragen stel je een potentiele partner?
- Op welk account komt de Git-repository te staan?
- Welk open-source framework gebruik je onder de motorkap?
- Kan ik vandaag een productie-backup van de database downloaden?
- Hoe ziet de handover eruit als ik na 2 jaar wil overstappen?
- Worden de externe accounts op mijn naam aangevraagd?
- Mag ik een ander bureau morgen aan deze codebase laten werken?
- Welke maandelijkse kosten zijn er na oplevering?
- Staan deze toezeggingen ook zwart op wit in je algemene voorwaarden?
Migratie-tijdlijn: welke weken besteed je waaraan?
De vijf migratiestappen klinken redelijk, maar in de praktijk willen ondernemers weten hoeveel weken ze concreet kwijt zijn. Onze ervaring met second-opinion trajecten geeft een vrij stabiel patroon voor een gemiddeld MKB-platform (twee tot vier database-tabellen, een handvol integraties, één publieke web-app). Voor grotere systemen tel je per extra integratie ongeveer twee tot drie dagen op.
| Week | Activiteit | Wie doet wat | Resultaat |
|---|---|---|---|
| Week 1 | Inventarisatie en formeel verzoek | Opdrachtgever stuurt brief, oude bureau verzamelt | Lijst systemen, accounts, Git-link, database-dump aangevraagd |
| Week 2 tot 3 | Code-review en gap-analyse | Nieuw bureau leest repo, schrijft tekortenlijst | Migratieplan met technische risico’s en kosten |
| Week 4 tot 7 | Parallelle omgeving opbouwen | Nieuw bureau zet hosting, CI/CD en database op | Werkende staging onder jouw accounts |
| Week 8 | Data-migratie en regression-tests | Nieuw bureau migreert data, jij voert acceptatietests uit | Volledige dataset in nieuwe omgeving, testresultaten |
| Week 9 | DNS-cutover en monitoring | Nieuw bureau plant cutover, monitort 48 uur | Live op nieuwe infra, oude omgeving op read-only |
| Week 10 tot 13 | Stabilisatie en afsluiting oud | Nieuw bureau lost incidenten op, oude omgeving wordt afgesloten | 30 dagen terugval verstreken, oude omgeving uit |
Welke contractclausules vraag je expliciet?
Een goed contract neemt 80 procent van de vendor-lock-in-risico’s weg voordat de eerste regel code is geschreven. Onze algemene voorwaarden bevatten al de IE-overdracht en handover-clausule als standaard, maar je kunt deze formuleringen ook in elk ander contract laten opnemen. Onderhandel niet over de inhoud, alleen over de scope.
- IE-overdracht expliciet. “Alle intellectuele eigendomsrechten op de in opdracht ontwikkelde software, inclusief broncode, databasestructuur en documentatie, gaan bij volledige betaling van de factuur over op opdrachtgever.”
- Repository-locatie. “Opdrachtnemer commit alle code naar een door opdrachtgever beheerd Git-account. Toegang van opdrachtnemer wordt bij oplevering ingetrokken op verzoek van opdrachtgever.”
- Account-overdracht. “Alle externe accounts (hosting, domeinen, API-providers, e-mailservices) worden bij oplevering geregistreerd onder de bedrijfsnaam en facturatie van opdrachtgever.”
- Handover-leverbestanddeel. “Bij eindoplevering levert opdrachtnemer een README, deployment-document en een handover-sessie van minimaal 90 minuten, opgenomen en in bezit van opdrachtgever.”
- Exit-clausule. “Bij beëindiging van de samenwerking ontvangt opdrachtgever binnen 10 werkdagen een productie-database-dump, alle credentials en een schriftelijke bevestiging dat opdrachtnemer geen kopieën behoudt.”
- Geen verborgen licentiekosten. “Opdrachtnemer brengt geen wederkerende licentiekosten in rekening voor componenten die als onderdeel van de oplevering zijn ontwikkeld.”
Tip: laat deze zes punten als bijlage toevoegen aan elke offerte boven €10.000. Als een bureau weigert, krijg je nu al een goed signaal over hoe het na oplevering zal zijn.
Veilige open-source frameworks vs frameworks met risico
De technische stack bepaalt voor 60 procent of je later kunt overstappen. Een Next.js-app kan elke serieuze front-end-developer onderhouden. Een applicatie op een proprietary engine met marketing-naam zit vast aan precies één leverancier. Hieronder de stacks die wij standaard gebruiken en de stacks waar wij vraagtekens bij zetten in second-opinion trajecten.
| Laag | Veilig (brede community) | Risico (smalle community of proprietary) |
|---|---|---|
| Front-end framework | Next.js, Astro, Remix, SvelteKit | Onbekende house-framework, “ons UI-platform” |
| Back-end framework | NestJS, Django, Rails, Laravel, FastAPI | In-house PHP-engine, ongedocumenteerde Node.js-fork |
| Database | Postgres, MySQL, MongoDB | Proprietary key-value store, eigen ORM-laag zonder export |
| Hosting | Vercel, Cloudflare, AWS, Hetzner | Agency-only datacenter zonder migratie-pad |
| CMS | Sanity, Strapi, Payload, headless WordPress | ”Ons eigen CMS”, visual builders zonder code-export |
Account-eigendom checklist: wie betaalt, wie beheert, wie heeft admin?
Code-eigendom zonder account-eigendom is een halve oplossing. Wij zien geregeld klanten bij wie de broncode keurig in een eigen Git-repo staat, maar de productie-database, e-mailservice en domein-registratie op naam van het oude bureau zijn geregistreerd. Bij overdracht moet alles dan opnieuw worden opgezet, met downtime en hertekening van DNS als gevolg. Loop deze checklist langs voor je in productie gaat.
| Account-type | Op wiens naam? | Wie betaalt? | Wie heeft admin-rol? |
|---|---|---|---|
| Domeinnaam | Opdrachtgever | Opdrachtgever | Opdrachtgever (bureau eventueel als technisch contact) |
| Hosting (Vercel, Hetzner, AWS) | Opdrachtgever | Opdrachtgever | Opdrachtgever, bureau als collaborator |
| Database (Supabase, Neon, RDS) | Opdrachtgever | Opdrachtgever | Opdrachtgever |
| Git-repository (GitHub, GitLab) | Opdrachtgever | Opdrachtgever | Opdrachtgever, bureau als collaborator |
| E-mailservice (Postmark, Resend) | Opdrachtgever | Opdrachtgever | Opdrachtgever |
| OAuth-apps (Google, Microsoft) | Opdrachtgever | n.v.t. | Opdrachtgever |
| Analytics (Plausible, GA4) | Opdrachtgever | Opdrachtgever | Opdrachtgever |
| Monitoring (Sentry, Better Stack) | Opdrachtgever | Opdrachtgever | Opdrachtgever, bureau als collaborator |
Wat wij in week 12 concreet overdragen
Een handover is geen e-mail met een link, het is een gestructureerd pakket dat de volgende ontwikkelaar of het volgende bureau zonder verdere uitleg op weg helpt. Bij elk TopDevs-traject leveren wij in de laatste week dit pakket aan, ongeacht of het om een klein automation-traject gaat of een custom platform van €25.000.
- Git-repository onder jouw account met alle commits. Branch-strategie en releases gedocumenteerd.
- README met architectuur-overzicht. Welke services, welke databases, welke externe API’s en hoe ze samenhangen.
- Deployment-document met exacte stappen. Van lokale clone tot productie-deploy in onder de 30 minuten voor een nieuwe developer.
- Password-manager-overdracht. Een gedeelde 1Password- of Bitwarden-vault met alle credentials, overgezet naar jouw eigenaarschap.
- Opgenomen handover-sessie van 90 minuten. Live walkthrough van architectuur, deploys en bekende valkuilen, gedeeld als video-bestand.
- Lijst van actieve afhankelijkheden en hun licenties. Welke packages, welke versies, welke licenties.
- Toegang tot alle monitoring en analytics. Sentry, uptime-monitoring en analytics overgedragen.
- Schriftelijke verklaring dat wij geen kopieën behouden. Onderdeel van het slot-document.
Hoe begin je concreet?
- Stap 1: maak een inventarislijst van je huidige stack. Welke systemen draaien er, op welk account staan ze, en wie heeft toegang.
- Stap 2: vraag bij je huidige leverancier om een Git-link en een productie-backup. De reactietijd vertelt je meer dan elke offerte.
- Stap 3: vergelijk de antwoorden met deze checklist. Als er meer dan twee items op rood staan, is er een gesprek nodig.
Wil je dat we meekijken? Plan een gratis second-opinion gesprek. Onze werkwijze en garanties staan in onze algemene voorwaarden, en hoe wij dit in praktijk doen lees je in de Mastone case study.
