You commission custom software and on paper you get “the code”. But two years later you want to switch to another party, and it turns out half the system runs on a proprietary agency platform, the deploy pipeline is a black box, and nobody knows how to get the production database out. Classic vendor lock-in, and it happens more often than owners think. This article explains what code ownership means legally and practically, how vendor lock-in arises, which red flags show up in a quote, and which questions to ask before you sign.
What is code ownership exactly?
Code ownership is a combination of legal rights and practical access. The legal side is intellectual property: copyright on the source code, the database structure, the configurations and the accompanying documentation. In the Netherlands copyright sits with the maker by default, so without an explicit transfer in the contract it stays with the developer or the agency.
The practical side matters just as much. A paper transfer is worthless if the Git repository sits under an agency account you cannot access, the production server runs at a supplier where you have no root access, and the OAuth tokens for your integrations are registered to someone else. For broader context, read our guide to commissioning custom software.
What is vendor lock-in and how does it arise?
- Proprietary frameworks. The agency runs a proprietary platform or engine on top of which your application sits.
- Agency hosting. The system runs on infrastructure only the agency manages.
- In-house tooling. Custom build tools or a proprietary CMS that only this agency knows.
- Abstracted code. The code is full of references to internal libraries that are not in the repository.
- Account ownership. All external accounts are in the agency name. On handover everything has to be set up again.
Four variants of vendor lock-in at agencies
| Variant | What does it look like? | Why is it lock-in? | What to ask |
|---|---|---|---|
| Proprietary framework | Agency builds on a proprietary engine with a marketing name | No external documentation, nobody else can work on it | Can I Google the name and see the public docs? |
| In-house hosting stack | Application runs on infra only the agency manages | Migrating means redeploy plus DNS cutover plus database export | Do I get root access and can I download a production backup? |
| Private dependencies | Code references packages on a private registry | Without those packages the code will not build | Are all dependencies public? |
| Visual builders without export | CMS or dashboards in a no-code tool without code export | The configuration sits in the tool, not in your repo | Which part is in code, which part is in a tool? |
How do you spot vendor lock-in in a quote?
- “We host it for you” with no option to self-host. Hosting should be a choice.
- “On our platform” or “on our suite”. A marketing name for the underlying framework. Ask which actual open-source framework sits beneath it.
- No mention of a Git repository. In 2026 every quote should specify which version control is used.
- Monthly licence fees alongside the build budget. A hidden licence on your own software.
- No IP transfer in the terms and conditions. Read our terms and conditions as an example of how IP transfer is named explicitly.
- “We will arrange the accounts for you” without a transfer plan. Everything in the agency name is a time bomb.
- No handover session in scope. A professional project closes with a proper handover.
What do you get at TopDevs by default?
- Git repository under your account. From day one we create a GitHub or GitLab repository under your company account.
- README and deployment document. Every delivery includes a README with architecture, dependencies, local run instructions and deployment steps.
- All credentials in your password manager. API keys, hosting credentials, database passwords, OAuth tokens. Nothing stays on our laptops.
- 90-minute handover session. Live session walking through the architecture and deploys, recorded.
This applies to small automations (starting at €495) just as much as to custom platforms of €15,000.
When is vendor lock-in acceptable?
- Real SaaS products. HubSpot, Salesforce or Pipedrive. But that is a licence on a commercial product.
- Specialised tools with strong market position. Vercel or Supabase. Deliberate lock-in in exchange for development speed.
- Market-standard frameworks. A Next.js or Django app is “tied” to that framework, but the whole world knows it.
What does the legal side say?
In the Netherlands, copyright on software is set out in article 10, paragraph 1, sub 12 of the Dutch Copyright Act. For commissioned work, copyright does not transfer automatically. For open-source definitions, opensource.org is the reference point.
- IP transfer. An explicit clause that all intellectual property rights transfer to the client on delivery.
- Source escrow option. For larger projects, an escrow arrangement can make sense.
- Licence versus ownership. The terms and conditions must make explicit what becomes owned versus what stays licensed.
For EU rules on software IP, the EU Intellectual Property Office is a good entry point. For general definitions and best practices around free software, the Free Software Foundation Europe is an authority.
How do you migrate away from vendor lock-in?
- Step 1: inventory what belongs to whom. List all systems, accounts and services.
- Step 2: formally request code and data. Written request with a 10 working-day deadline.
- Step 3: build a new environment in parallel. DNS cutover only happens once everything works.
- Step 4: data migration and regression tests. A test suite to verify all workflows work.
- Step 5: cutover and shut down the old environment. 30 days of safe fallback, only then close it.
Which questions should you ask a potential partner?
- Which account will the Git repository sit under?
- Which open-source framework do you use under the hood?
- Can I download a production backup of the database today?
- What does the handover look like if I want to switch after 2 years?
- Will external accounts be registered in my name?
- Can a different agency start working on this codebase tomorrow?
- What monthly costs are there after delivery?
- Are these commitments also stated in your terms and conditions?
Migration timeline: which weeks do you spend on what?
The five migration steps sound reasonable, but in practice owners want to know how many weeks they are concretely committing. Our experience with second-opinion projects gives a fairly stable pattern for an average SMB platform (two to four database tables, a handful of integrations, one public web app). For larger systems, add roughly two to three days per extra integration.
| Week | Activity | Who does what | Result |
|---|---|---|---|
| Week 1 | Inventory and formal request | Client sends letter, old agency collects | List of systems, accounts, Git link, database dump requested |
| Week 2 to 3 | Code review and gap analysis | New agency reads repo, writes gap list | Migration plan with technical risks and costs |
| Week 4 to 7 | Build parallel environment | New agency sets up hosting, CI/CD and database | Working staging under your accounts |
| Week 8 | Data migration and regression tests | New agency migrates data, you run acceptance tests | Full dataset in new environment, test results |
| Week 9 | DNS cutover and monitoring | New agency schedules cutover, monitors for 48 hours | Live on new infra, old environment on read-only |
| Week 10 to 13 | Stabilisation and old shutdown | New agency fixes incidents, old environment closes | 30-day fallback expires, old environment shuts down |
Which contract clauses should you demand explicitly?
A good contract removes 80 percent of vendor lock-in risks before the first line of code is written. Our terms and conditions already contain the IP transfer and handover clause as standard, but you can have these wordings added to any other contract too. Do not negotiate the content, only the scope.
- Explicit IP transfer. “All intellectual property rights to the commissioned software, including source code, database structure and documentation, transfer to the client upon full payment of the invoice.”
- Repository location. “The contractor commits all code to a Git account managed by the client. Contractor access is revoked upon delivery at the client’s request.”
- Account transfer. “All external accounts (hosting, domains, API providers, email services) are registered under the client’s company name and billing on delivery.”
- Handover deliverable. “On final delivery, the contractor provides a README, deployment document and a handover session of at least 90 minutes, recorded and owned by the client.”
- Exit clause. “On termination of the engagement, the client receives within 10 working days a production database dump, all credentials and a written confirmation that the contractor retains no copies.”
- No hidden licence fees. “The contractor will not charge recurring licence fees for components developed as part of the deliverables.”
Tip: ask for these six points to be attached as an annex to every quote above €10,000. If an agency refuses, you already have a strong signal about what working with them will be like after delivery.
Safe open-source frameworks vs frameworks with risk
The technical stack determines 60 percent of whether you can switch later. A Next.js app can be maintained by any serious front-end developer. An application on a proprietary engine with a marketing name is tied to exactly one supplier. Below are the stacks we use as standard and the stacks where we raise question marks in second-opinion projects.
| Layer | Safe (wide community) | Risky (narrow community or proprietary) |
|---|---|---|
| Front-end framework | Next.js, Astro, Remix, SvelteKit | Unknown house framework, “our UI platform” |
| Back-end framework | NestJS, Django, Rails, Laravel, FastAPI | In-house PHP engine, undocumented Node.js fork |
| Database | Postgres, MySQL, MongoDB | Proprietary key-value store, in-house ORM layer without export |
| Hosting | Vercel, Cloudflare, AWS, Hetzner | Agency-only data centre with no migration path |
| CMS | Sanity, Strapi, Payload, headless WordPress | ”Our own CMS”, visual builders without code export |
Account-ownership checklist: who pays, who manages, who has admin?
Code ownership without account ownership is a half-solution. We regularly see clients whose source code sits neatly in their own Git repo, but whose production database, email service and domain registration are in the old agency’s name. On handover, everything has to be rebuilt, with downtime and DNS redesign as a result. Walk through this checklist before going to production.
| Account type | In whose name? | Who pays? | Who has admin role? |
|---|---|---|---|
| Domain name | Client | Client | Client (agency optionally as technical contact) |
| Hosting (Vercel, Hetzner, AWS) | Client | Client | Client, agency as collaborator |
| Database (Supabase, Neon, RDS) | Client | Client | Client |
| Git repository (GitHub, GitLab) | Client | Client | Client, agency as collaborator |
| Email service (Postmark, Resend) | Client | Client | Client |
| OAuth apps (Google, Microsoft) | Client | n/a | Client |
| Analytics (Plausible, GA4) | Client | Client | Client |
| Monitoring (Sentry, Better Stack) | Client | Client | Client, agency as collaborator |
What we hand over in week 12 concretely
A handover is not an email with a link, it is a structured package that helps the next developer or the next agency get going without further explanation. On every TopDevs engagement we deliver this package in the final week, whether it is a small automation project or a custom platform of €25,000.
- Git repository under your account with all commits. Branch strategy and releases documented.
- README with architecture overview. Which services, which databases, which external APIs and how they connect.
- Deployment document with exact steps. From local clone to production deploy in under 30 minutes for a new developer.
- Password-manager transfer. A shared 1Password or Bitwarden vault with all credentials, transferred to your ownership.
- Recorded handover session of 90 minutes. Live walkthrough of architecture, deploys and known pitfalls, shared as a video file.
- List of active dependencies and their licences. Which packages, which versions, which licences.
- Access to all monitoring and analytics. Sentry, uptime monitoring and analytics handed over.
- Written statement that we keep no copies. Part of the closing document.
How do you start in practice?
- Step 1: make an inventory of your current stack. Which systems are running, under which accounts, and who has access.
- Step 2: ask your current supplier for a Git link and a production backup. The response time tells you more than any quote.
- Step 3: compare the answers with this checklist. If more than two items come back red, you need a conversation.
Want us to take a look? Plan a free second-opinion call. Our way of working and guarantees sit in our terms and conditions, and how we do this in practice you can read in the Mastone case study.
