In short
You avoid developer lock-in when another team could carry on without your developer. That means your repository, domain, hosting and all services are in your company’s name, and your contract covers usage rights and the handover of the source code. Add documentation, automated tests, build instructions an outsider can follow and a list of all components with their licenses.
Key takeaways
- Your repository, domain, hosting and services belong in your company’s name. Your developer gets their own login and the rights they need.
- GitHub recommends at least two people with the owner role in each organization, so projects stay accessible if one of them can’t be reached.
- In our review of 10 German software providers’ terms, only two commit to providing the source code, one of them not for agile projects.
- A handover test shows if another team can take over: an outside engineer builds and tests the software from the repository and docs alone.
- Source code escrow mainly helps if you don’t already get the source code. Germany’s BSI advises considering it for critical applications.
How locked in are you to your developer?
You’re locked in when only one particular person or company can run and change your software. To find out, check seven points: accounts, rights, source code, documentation, build and deployment, tests, and third-party components. The table gives the question to ask about your project and the warning sign for each point.
Our guide to SaaS explains how a SaaS project runs from idea to operations. How dependent you become on the vendor of off-the-shelf software is covered in our comparison of building and buying software.
| Point | Question about your project | Warning sign |
|---|---|---|
| Accounts | Are the repository, domain, hosting and services in your company’s name? | Accounts in the developer’s name or under their email address |
| Rights | Does the contract say what you may do with the code? | No provision, or modifying and passing on the code ruled out |
| Source code | Is the source code, with every change, in your repository? | Code held only by the developer, delivered as a ZIP file or only as an executable program |
| Documentation | Could an outside engineer get started with the documents? | Knowledge only in one person’s head |
| Build and deployment | Can the software be built and deployed by following written instructions? | Deployment only from the developer’s computer |
| Tests | Do automated tests run on every change? | No tests, or nobody knows whether they run |
| Third-party components | Is there a list of all components and their licenses? | Licenses unknown, paid licenses in the developer’s name |
Done when you can answer every row for your project and know which point to tackle first.
Who holds the accounts for your repository, domain and hosting?
Your repository, domain, hosting and every service your software needs should be in your company’s name, with a company email address. Your developer gets their own login with the permissions their work requires. That way, you decide who has access, even when you switch providers.
Repository: The repository stores your source code with every change. Create it in your company’s account, for example in an organization on GitHub. GitHub recommends at least two people with the owner role; otherwise, a project can become inaccessible if the only owner can’t be reached (GitHub on ownership continuity (external site)). Add an outside developer as an outside collaborator (external site) with access to specific repositories. If the repository is in their account, they can transfer it to your organization with its history (GitHub on repository transfers (external site)).
Domain: For .de domains, the German registry DENIC says the substantive right to a domain lies with whoever is registered as its holder. DENIC advises registering a company domain in the company’s own name, or in the owner’s name for a sole proprietorship. It also advises giving the service provider written instructions to that effect (DENIC on domain holders (external site)). As the holder, you can move the domain without your previous provider. Our guide to moving a domain without email downtime shows how to change nameservers without breaking email.
Hosting and cloud: At Amazon Web Services (AWS), the root user has complete access to all resources in the account. AWS advises giving it an email address managed by your business (external site) that forwards to a group of people. Then your company can respond to AWS in time, even if individuals are on vacation, out sick or have left. If you lose everything you use for two-factor authentication, you need the phone number and email address used to register the account.
Other services: Payment providers, email delivery, APIs, error monitoring and the project’s password manager also belong in your company’s name. For an app, that includes the App Store developer account. Apple shows the enrolled organization’s or individual’s name as the seller of the app (external site).
Common mistake: At the start, the developer sets up accounts with their own email address, and nobody ever switches them over.
Done when your list of accounts shows your company as the holder of each one, at least two people on your side have access and each provider has their own login.
What rights to the code do you need?
You need rights that cover your plans: using the software, having another team change it and, if needed, passing it on or selling it. Have the contract state which usage rights you receive, from when, and whether the source code is included. The standard terms and conditions (AGB) of German providers differ widely on this.
In everyday language, many people ask who owns the code. Contracts and standard terms in Germany address this as usage rights (Nutzungsrechte), meaning what you’re allowed to do with the code. Before you place the order, ask about these points:
- Exclusive or not: May the provider offer the same code to other customers? One set of terms in our review lets the provider reuse common software code in other projects, unless agreed otherwise.
- Changing and passing on: May you or another team develop the code further, and may you transfer the rights, for example when you sell your company or your SaaS product?
- Source code: Do you receive the source code with its version history? The executable program alone, the object code, is practically impossible to develop further.
- Timing: Do the rights apply from sign-off or from full payment, and do they cover interim versions?
- The provider’s own components: Which of its own tools and libraries does the provider bring, and what rights do you get to them? Have them listed in the quote.
- Open source: Open-source components keep their own licenses; see components and licenses.
Our review of 10 providers’ terms shows how differently they handle these points. Before you sign, have the clauses reviewed by an IT lawyer.
Common mistake: In the meeting, you hear “Of course you’ll get everything.” Yet the terms that come with the quote grant a right for internal use only, without the source code.
Done when the draft contract states the type, scope and timing of your usage rights, covers the handover of the source code and lists the provider’s own components.
What documentation does another team need?
Another team needs setup instructions, an overview of the architecture and interfaces, the reasons behind key decisions and an operations manual. Agree on these documents as part of the deliverables, keep them in the repository and check them at sign-off.
Germany’s Federal Office for Information Security (BSI) explains why documentation matters in its module CON.8 Software Development (external site) (in German). If development is poorly documented, any later change or extension can take a great deal of effort. Under CON.8, the documentation should enable experts to understand the code and develop it further. In practice, that means:
- Getting started: a file in the repository, usually called README, with the commands for setup, build, tests and deployment.
- Architecture: goals, building blocks, interfaces and deployment. A widely used structure is the free arc42 (external site) template with 12 sections; for diagrams, there’s the C4 model (external site).
- Decisions: short records of key architecture decisions, with context and consequences. Without them, newcomers to a project can only blindly accept a decision or blindly change it, Michael Nygard wrote in Documenting Architecture Decisions (external site) in 2011.
- Operations: an operations manual for deployment, backups, restores, monitoring and emergencies.
- Interfaces and data: a description of every interface and of the data model.
The documents belong in the repository and are updated with the code; CON.8 also calls for keeping them current. Our how-to on requirements specifications shows how to write acceptance criteria for them.
Our article on technical debt shows how to rate gaps such as missing documentation and when paying them down is worth it.
Common mistake: The documentation is written in the last week and signed off without anyone reading it.
Done when the documents are in the repository, the acceptance criteria name them and someone outside the project has read them.
Can the software be built without your developer?
Software can be built without your developer if the repository contains everything needed to build, test and deploy it, and an automated pipeline does this on every change. That requires pinned versions of all components, automated tests and a configuration with no passwords in the code. Passwords and keys are kept in a vault in your company’s account.
Building means turning the source code into software that runs. According to the Reproducible Builds (external site) project, a build is reproducible if anyone can recreate bit-by-bit identical files from the same source code, build environment and build instructions. For a change of team, we consider it enough that the new team can build the same software from the repository.
- Pinned versions: A lock file records the exact version of every component, for example package-lock.json in JavaScript. The npm ci (external site) command is meant for automated environments: it requires this file and stops with an error if it doesn’t match the package list.
- Automated pipeline: Building, testing and deployment run in your company’s account, for example with your repository host’s tools. Then deployment doesn’t depend on one person’s computer.
- Passwords and keys: The OWASP cheat sheet on secrets management (external site) notes that many organizations hardcode credentials in plaintext in their source code. It advises storing and managing them centrally. That vault sits in your company’s account.
- Tests: Automated tests show a new team whether a change breaks something. The BSI’s module CON.8 calls for testing during development, including negative tests, separate from production. For test coverage, the share of the code that tests execute, the Google Testing Blog (external site) calls 60% “acceptable,” 75% “commendable” and 90% “exemplary.” High coverage doesn’t guarantee good tests, though, the blog adds.
Common mistake: Deployment only works from the developer’s computer because a key or setting stored there isn’t documented anywhere.
Done when the pipeline builds and tests every change, you see the result in every demo and there’s no password in the repository.
Which components and licenses are in your software?
A software bill of materials (SBOM) lists every third-party component in your software with its version and license. Have one delivered with every version, and clarify licenses with special conditions before you sell or distribute the software. Paid licenses should be in your company’s name so they don’t depend on your developer’s contract.
SBOMs were originally used mainly for license management, the BSI writes in its Technical Guideline TR-03183-2 (external site). For each component, it requires the creator, name, version, dependencies, license and a checksum, among other fields. Each version of the software gets its own SBOM, in CycloneDX or SPDX format. In JavaScript projects, the npm sbom (external site) command generates one in either format.
Some licenses attach obligations to distribution. As the GNU Project explains, copyleft (external site) requires all modified and extended versions of a program to be free as well. According to GNU, the GNU Affero General Public License (AGPL) also ensures that modified versions used to provide services to the public are released as source code. That can affect SaaS products. For licenses like these, ask your legal counsel what they mean for your plans.
Take our own project: the lock file for datafalke.de lists 959 packages. We chose 33 of them; the rest came along as their dependencies. Of the 959, 501 are used only for development and testing, and 751 are under the MIT License. Another 16 are fully or partly under the GNU Lesser General Public License (LGPL), which GNU calls a compromise form of copyleft; they run only during builds and tests. The website we deliver contains components from 12 packages, listed under licenses for this website. For two packages, the license is missing from the lock file and appears only in an outdated field of the package description. Only someone who checks the list finds gaps like these.
Measured · Python 3.12, counted package-lock.json and the license list of datafalke.de
Common mistake: The SBOM is created once for sign-off and goes out of date with the first update.
Done when there’s an SBOM with licenses for the current version, licenses with special conditions are clarified and every paid license is in your company’s name.
How do you check whether another team can take over?
A handover test shows whether another team can take over. An engineer who doesn’t know the project uses only the repository and documentation to set up the software, build and test it and deploy it to a test environment. Your developer fills in whatever is missing. Run the test before sign-off and at regular intervals after that.
How the test works:
- Choose the engineer from your own staff or another provider, and set a fixed time frame, such as one day of work.
- The engineer gets access to the repository and documentation, but no help from your current developer.
- The tasks: set up and build the software, run the tests, deploy to a test environment, make a small change and restore a backup.
- The engineer notes every point where they got stuck.
- Your developer closes the gaps; then you repeat the test for the open points.
In its module OPS.2.3 on outsourcing (external site) (in German), the BSI describes the risk that, without suitable rules, data and access aren’t properly handed over when a working relationship ends. It recommends developing alternatives for both a planned and an unplanned end and reviewing them regularly.
A handover includes the repository with its full version history, the documentation, the list of accounts, open tasks and known bugs. After that, revoke the previous provider’s access and replace passwords and keys. If they transferred the repository to your organization on GitHub, they remain on it as a collaborator until you remove them. What switching to a new team costs is covered in our cost guide How much does software maintenance cost?
Common mistake: Nobody plans the handover until the working relationship ends in a dispute.
Done when the test has been run, the test report lists every gap with the person responsible and a due date, and all gaps are closed.
What should the contract cover?
Your contract should cover usage rights, source code, documentation, accounts, third-party components and the end of the working relationship, each with its scope and timing. Take the checklist below to your meeting with the provider, and have an IT lawyer review the draft contract.
| Point | What to have covered | Weak clause |
|---|---|---|
| Usage rights | Whether they’re exclusive, whether you may change and pass on the code, from when | A right for internal use only, with no right to modify |
| Source code | Handover with version history, continuously into your repository | Object code only, or source code only at the end of the project |
| The provider’s own components | A list in the quote and your rights to them | Unnamed components only the provider may use |
| Third-party components | An SBOM with licenses for every version, copyleft only by agreement | Third-party components you don’t know about |
| Documentation | Contents as part of the deliverables, checked at sign-off | Documentation only for an extra fee |
| Accounts and access | Your company as the account holder, separate logins for the provider | Accounts in the provider’s name |
| End of the relationship | Handover of documents and access, support with the switch, export of your data | No provision for the end |
| AI tools | Whether and how they’re used for coding | Nothing said about it |
| Data protection | Rules for personal data if the provider processes it | No rules, even though the provider can access customer data |
Our guide to choosing a software developer lists the questions to ask a provider before you sign.
Done when the draft contract covers every point on the checklist and your legal counsel has reviewed it.
What applies in Germany and the EU?
In Germany, the Federal Office for Information Security (BSI) sets out in its IT-Grundschutz Compendium what clients and developers of custom software should arrange. That ranges from documentation to source code escrow. You can use these requirements as a checklist for your project. Your contract should state explicitly which rights to the code you receive.
- Two sides: The module APP.7 Development of Individual Software (external site) (in German) covers the client side and CON.8 the developer side, both in the 2023 edition of the IT-Grundschutz Compendium.
- Version control: Under CON.8, every change to the source code must be traceable and reversible, and version control must not run without backups.
- Escrow: For applications critical to an organization, APP.7 advises checking whether to protect them against the failure of the company that makes them, for example by depositing materials with an escrow agent.
From our work: what 10 German providers’ standard terms say
On November 8, 2026, we read the publicly available standard terms of 10 custom software providers based in Germany. Eight came from our market review in October 2026, two from a web search for this article. We looked at what applies when the contract doesn’t say otherwise. We don’t name the providers.
| Provider | Rights to the custom code | Source code | Documentation |
|---|---|---|---|
| A | Exclusive, transferable and sublicensable, on full payment | Not specifically addressed | List of open-source dependencies with licenses |
| B | Exclusive, unlimited in time and territory, on full payment | A copy at project completion | None owed beyond that |
| C | Waterfall model: exclusive and transferable, on sign-off; agile model: non-exclusive, non-transferable | Waterfall model: object and source code; agile model: object code only | Waterfall model: user and developer documentation; agile model: user documentation |
| D | Non-exclusive, modification for your own purposes allowed, no sublicenses, on full payment | Called “quelltextoffen” (literally, open source), handover not addressed | Only by separate agreement and for a separate fee |
| E | Non-exclusive, non-transferable; copyright stays with the provider | Not addressed | All related documentation |
| F | Non-exclusive, internal purposes only, on full payment; modification only by agreement | No entitlement, object code only | Not addressed |
| G | Non-exclusive, on full payment; changes only where the law mandatorily allows them | Not owed, except for open-source parts | Not addressed |
| H | Non-exclusive, depending on the number of users, on full payment; exclusive rights on request | No obligation, changes to the source code prohibited | Not addressed |
| I | Non-exclusive, passing the rights on only by agreement, on full payment | Files only by separate agreement and for a fee | Only if ordered in writing |
| J | Not addressed in the terms; according to the terms, set out in each quote | Not addressed | Not addressed |
- Rights: Two of the 10 grant exclusive rights to the code written specifically for the client, and a third does so only under the waterfall model. Six grant a non-exclusive right, and one doesn’t address rights at all.
- Source code: Two commit to providing the source code, one of them only under the waterfall model. Four rule it out or make it subject to a separate agreement. One calls the code “quelltextoffen” (literally, open source) without addressing its handover. Three don’t address it.
- Payment: Under seven of the 10, the rights pass only on full payment.
- Contract model: At provider C, everything depends on the model. The waterfall model comes with exclusive rights, source code and developer documentation. The agile model comes with a non-exclusive, non-transferable right to the object code.
- AI: Three address the use of AI in coding, each differently. One allows it without labeling, one only with the client’s consent, and one announces its use and addresses the rights to purely AI-generated parts. Our eight questions about AI-generated code show what to ask a provider about AI use.
What this means for you: read the terms before you sign, and settle every point on the checklist in the contract. Four of the 10 providers say in their own terms that their rule on rights applies only if nothing else has been agreed.
Our own rule is on our software development page: your code and accounts are under your control from the start. The exclusive usage rights to the code we write for you pass to you on full payment. Open-source components keep their own licenses. What else is included is set out there under What happens if we can’t continue?
Frequently asked questions
Do I need source code escrow?
Only if you don’t already get the source code. With escrow, an escrow agent keeps the source code and documentation. It releases them in cases set out in the contract, for example if the company that made the software fails. In module APP.7, the BSI provides for depositing materials that aren’t part of the delivery, including documented code, keys and passwords. If the source code is in your repository all along, it’s part of the delivery. In our assessment, escrow is mainly worth it for software that the provider runs itself or whose source code it keeps. One German escrow agent’s price list starts at €1,200 for the first year; later years cost about a fifth less. Have a lawyer check whether the release would work in an emergency, such as the provider’s insolvency.
Source: HanseEscrow Management GmbH (external site), · date retrieved; price list undated, VAT not stated
What if I can no longer reach my developer?
First, secure what’s already in your hands: access to your company’s accounts, the contract, invoices and every copy of the code. For a .de domain, DENIC’s domain lookup shows the registered holder only for legal entities. Individuals can look up their own holder data (external site) there through a special access function. If you or your company is the holder, a new provider can request a password from DENIC. DENIC sends it by postal mail to the address on record (external site). With it, you can move the domain without your previous provider. You can reset accounts that use your company’s email address yourself. If the repository or accounts are with the developer, you need their cooperation; in that case, get legal advice.
Is a freelancer riskier than an agency?
Not inherently. In our assessment, the risk depends less on the provider’s size than on where the code, accounts and knowledge are kept. Even in a large team, a project can depend on one person. So check the same points with every provider, and run the handover test.