Do We Own the Code You Write?

Short Answer

Yes, and the contract should say so explicitly. With a reputable agency, you own the source code, the database, the deployment infrastructure, and any custom design assets on delivery. The agency may retain rights to its internal frameworks, libraries, or tooling used across multiple clients, but anything specifically built for your project belongs to you. You should be able to take the entire codebase to another agency or an in-house team at any time, without paying additional fees or requesting permission. If an agency cannot say this clearly in a contract, that is the most important warning sign in the whole evaluation. See How Do I Evaluate a Software Agency? for what else to check before signing.

What Code Ownership Actually Means

Code ownership has three practical components, and all three need to be addressed in writing.

Intellectual property. Who legally owns the work product? In a well-structured engagement, all custom code, database schemas, designs, and documentation produced specifically for your project transfer to you on payment. The agency assigns IP rather than licenses it. Licensing is like renting; assignment is ownership. The language in the contract matters.

Access and infrastructure. Owning the code is only useful if you can get to it. You should have administrative access to the source repository (typically GitHub or GitLab), the hosting platform (AWS, Cloudflare, DigitalOcean, etc.), the domain and DNS, the database, and any third-party services the system depends on. If the agency holds these accounts, ownership of the code is theoretical.

Portability. Can you actually move the system elsewhere? A codebase with no documentation, no environment setup instructions, and dependencies on proprietary agency tools is technically yours but practically unusable by anyone else. Real ownership means another competent developer could pick up the project and continue. See Can You Take Over an Existing Project? for how that handover process works in practice.

The exception that does come up legitimately is agency-owned reusable components. If the agency has built an internal framework, billing module, or admin panel that they use across many clients, they may license it to you rather than transfer ownership. This is fine as long as the license is perpetual, transferable, and clearly named in the contract, and as long as your project-specific code is fully yours.

Why This Matters

Code ownership becomes important the moment the agency relationship changes. You might want to bring development in-house, switch agencies, sell the business, or simply have an independent developer audit the work. Any of these requires that you genuinely own what was built. We have seen businesses discover after years of payment that they did not own the platform they depended on, and the cost of unwinding that is far higher than negotiating it correctly at the start.

There is also a security angle. Code you own can be audited independently for vulnerabilities, backdoors, or compliance issues. Code locked behind an agency’s account cannot. For regulated industries, this distinction can have legal weight.

What to Look For

• Explicit IP assignment clause. Not a license, not a “right to use”, but a transfer of ownership on payment.
• Source code in your repository, not theirs. Your project should sit in a Git repository under your organisation from day one, with the agency invited as a collaborator.
• All infrastructure accounts in your name: hosting, domain, third-party services. Pay the bills directly where you can.
• A documented handover at the end of the project. README, environment variables, deployment instructions, and a list of all credentials and access points.
• No exit fees or “buyout” clauses. Some agencies charge to release code at the end of an engagement. Avoid this.

Common Mistakes

The most common mistake is not reading the contract carefully. Standard agency contracts vary widely: some assign IP cleanly, others retain ownership and grant a license, and a few are written so ambiguously that the answer is unclear without a lawyer.

Letting the agency hold the infrastructure accounts is the second. Even with full code ownership, if the deployment, domain, and DNS are in the agency’s account, switching providers is painful and expensive.

Treating handover as a finishing touch rather than a deliverable is the third. A proper handover takes a day or two of focused work and should be part of the original scope.

How We Approach This

Every project we deliver assigns full IP to the client on payment, with the source code, infrastructure, and documentation in the client’s accounts from the start. We provide a written handover at the end of every engagement so the work is fully transferable.

Make Ownership Explicit

If you want to talk through contract terms before any commitment, that is the right place to start. The Custom Software Development page describes how we structure engagements, including IP and handover terms. You can also browse related topics in the Knowledge Center.