Who Owns Custom Software Code in the UK?

A startup can spend months and a serious budget building an app, platform or internal tool, only to discover that it does not clearly own the code it paid for.

The risk often appears at the worst time: during fundraising, a sale process, a security review, or when the developer relationship breaks down.

Common mistakes include assuming payment automatically transfers copyright, leaving reusable developer libraries undefined, and treating GitHub access as the same thing as legal ownership. Founders also overlook open-source licences, technical documentation and handover duties until they need to change developers quickly.

A clear custom code ownership contract helps you decide whether your company owns the new code, receives a software licence to use it, or needs a software assignment agreement. It also sets out what happens to background IP, third party tools, repositories and the practical materials needed to run the software after launch.

Custom Code Ownership Checklist for UK Founders

Your business should be able to identify each part of the software stack and match it to a clear ownership or licence position. Custom software projects are rarely made from one clean block of newly created code, so founders need a practical map of what they are getting.

Use this checklist when you are scoping a new build, reviewing an existing developer agreement, preparing for investment, or moving from one software agency to another.

• New custom code: Code written specifically for your project, such as product features, integrations, data models, frontend components and backend logic.
• Developer background IP: Pre-existing frameworks, code libraries, templates, snippets, testing tools, scripts or methods the developer already owned before the project.
• Your business IP: Your brand assets, product concepts, confidential information, customer data, designs, specifications, algorithms or documentation supplied by your team.
• Open-source components: Third party code used under open-source licences, each with its own conditions and compliance requirements.
• Commercial third party tools: Paid APIs, SDKs, plugins, cloud services, analytics tools or code packages licensed from another provider.
• Repository and deployment access: Git repositories, CI/CD pipelines, hosting accounts, staging environments, production credentials and release processes.
• Documentation and knowledge transfer: Architecture notes, API documentation, setup instructions, runbooks, database schemas and support information.
• Assignment or licence wording: The legal mechanism that says whether copyright in the deliverables transfers to you or whether you only receive permission to use them.

A founder-friendly outcome is not always full ownership of every line of code. Many developers legitimately use pre-existing tools and reusable code. The key is to make sure your company owns, or has a sufficiently broad licence to use, everything it needs to operate, modify, commercialise and exit the product.

For example, a SaaS startup might need full ownership of the customer-facing product features and the right to modify them, while the agency keeps ownership of a deployment script it uses across many clients. That can work if the licence to the script is permanent, broad enough for the product to run, and not tied to continuing to pay that agency for future work.

The checklist should also be used at each milestone. At prototype stage, you may accept a narrower arrangement. Before launch or investment, investors and acquirers usually expect clearer software development IP ownership in the UK context, especially where the platform is the core business asset.

What Copyright Law Says About Commissioned Software

Paying a contractor or agency to create software does not automatically mean your company owns the copyright in the code. In England and Wales, software code is generally protected by copyright as a literary work, and the starting point is that the author owns copyright unless an exception or valid transfer applies.

The copyright framework sits under the Copyright, Designs and Patents Act 1988. For a startup, the most practical rule is simple: employee-created code and contractor-created code are treated differently.

Employees Who Build Code for Your Company

If an employee creates code in the course of their employment, the employer will often own the copyright by default. That position depends on whether the work was created as part of the employee's duties, during their role, and using company responsibilities rather than purely personal activity.

Even where the law gives the employer a strong default position, employment contracts should still contain clear intellectual property clauses. A CTO, developer or product employee may create side tools, prototypes, documentation, scripts or experimental features, and the contract should make it clear which creations belong to the company.

Employer-side employment law also matters because disputes about IP often overlap with exits, restrictive covenants, confidentiality and misuse of company information. Your employment contracts and contractor agreements should speak the same language about ownership and confidentiality.

Contractors and Agencies Who Build Code for You

An external developer, freelancer or software agency will usually own the copyright in code they create unless there is a written assignment to your company. A brief, proposal or invoice that says custom development or work for hire may not be enough.

UK law generally requires an assignment of copyright to be in writing and signed by or on behalf of the assignor. In practical terms, if you want your company to own the custom code, the development agreement should include a proper intellectual property assignment clause.

This is where many founders get caught. They have emails saying the agency will build the platform for the business, invoices showing payment, and admin access to the repository. None of that necessarily equals ownership of copyright. It may show that the business has some permission to use the software, but the scope of that permission can be uncertain.

Uncertainty becomes a commercial problem in several common moments:

• An investor asks for evidence that the company owns its core technology.
• A buyer conducts due diligence before acquiring the business.
• The company wants to appoint a new developer to maintain or rewrite the code.
• The original developer claims the business cannot copy, adapt or commercialise parts of the software.
• A dispute arises about unpaid invoices, late delivery or support obligations.

If the software is central to your business model, a vague implied licence is usually not enough. You want the agreement to state what has been assigned, when ownership transfers, whether payment is a condition, and what rights your company has if the project ends early.

What Your Development Contract Should Say

A good software development agreement should separate ownership of newly created deliverables from licences to background and third party materials. That separation gives both sides a fair position without leaving your company dependent on assumptions.

The contract should be tailored to how the project is actually delivered. A fixed scope build, agile product sprint, ongoing retainer, API integration, API access terms and AI-enabled software tool all carry different ownership and handover risks.

Define the Deliverables Precisely

The contract should define what the developer is creating for you. Deliverables can include source code, compiled code, interfaces, designs, technical specifications, documentation, databases, scripts, test suites, configuration files and deployment materials.

If the contract only refers to an app or website, the developer may later argue that only the visible product was included, not the underlying scripts, documentation or tooling needed to maintain it. A precise deliverables definition reduces that risk.

A useful definition often covers:

• All source code written specifically for the project.
• Object code, builds and deployable versions.
• UI and UX design files produced for the project.
• Technical documentation and setup instructions.
• Database schemas and configuration files.
• Testing materials and bug reports.
• Project files, tickets and relevant product specifications.

Use Assignment Wording Where Ownership Is Required

If your company needs to own the custom code, the contract should include a present or future assignment of intellectual property rights in the project deliverables. A software assignment agreement can be a standalone document, or the assignment can sit inside the main development agreement.

The clause should deal with existing and future rights, the point at which ownership transfers, and whether transfer depends on payment. Agencies often prefer IP to transfer only once invoices are paid. Founders can accept that position in some projects, but should still secure clear usage rights for paid milestones and continuity rights if the project is paused or terminated.

For example, if the agency completes sprint one and you pay for it, your business should not be left unable to use that code because sprint two is delayed. The contract can link ownership to paid deliverables while ensuring the company has access to work product for the amounts already paid.

Licence Background IP on Practical Terms

Developers commonly use their own background IP, and that is not automatically a red flag. The issue is whether your company receives a licence broad enough to use the final product as intended.

A balanced background IP clause might say the developer keeps ownership of pre-existing tools, but grants your company a perpetual, worldwide, royalty-free licence to use, reproduce, modify and have others support those tools as part of the software. The licence should survive termination and not prevent you from appointing another developer.

Founders should be careful with clauses that let the developer withdraw access to reusable components, charge extra fees for routine use, or stop a new technical team from maintaining the product. Those terms may undermine the commercial value of the custom build.

Include Moral Rights, Confidentiality and Further Assurances

Software IP clauses often sit alongside confidentiality, moral rights and further assurance obligations. These are not just legal extras. They help your business use the code without later permissions becoming a bottleneck.

Authors can have moral rights in copyright works, although the way those rights apply to software projects can be technical. Developers are commonly asked to waive or not assert moral rights where legally possible, so the business can modify and commercialise the work without attribution disputes.

Further assurance wording can require the developer to sign additional documents needed to confirm ownership, fix filing issues or support due diligence. This can be helpful where an investor asks for a clean chain of title and the original contract needs supporting documents.

Repositories, Open Source, Documentation and Handover

Legal ownership is only useful if your company can actually access, run and maintain the software. A founder may have the right IP wording but still face major disruption if the repository, credentials or documentation sit entirely with the developer.

The practical handover obligations should be written into the development contract from the beginning, not negotiated after the relationship has soured.

Repositories and Access Controls

Your company should know where the source code is stored and who controls the account. Repository access on platforms such as GitHub, GitLab or Bitbucket is often treated as a technical detail, but it has real business consequences.

Ideally, the main repository should be under an account controlled by your company, with the developer granted appropriate access. If the developer hosts the repository under its own account, the contract should require transfer or full export of repositories, commit history, branches, issues, pull requests and release notes when requested or at project end.

Access rights should also cover hosting, domain names, cloud infrastructure, analytics, error monitoring, payment gateway dashboards and deployment tools. A founder should not discover after termination that the live product depends on a personal developer account or a forgotten trial subscription.

Practical clauses can require:

• Admin access for your company to core repositories and production systems.
• No use of personal accounts for critical infrastructure without approval.
• A documented list of all third party services used by the software.
• Secure handover of credentials through an agreed password manager or access process.
• Removal of developer access once the project ends, subject to support needs.
• Regular backups and exportable copies of source code and documentation.

Open-Source Components

Open-source software can be extremely useful, but it must be managed because licences come with conditions. Some licences are permissive, while others may require notices, source code availability or sharing modifications under similar terms.

The right approach depends on the licence and how the component is used. A small utility library may create little risk. A core component integrated deeply into proprietary software may require closer review, particularly if the business plans to license, sell or white-label the platform.

Your contract should require the developer to disclose open-source components used in the project and comply with their licence terms. This is often handled through an open-source schedule or software bill of materials. At minimum, you should receive a list of key packages, licences and any obligations affecting distribution or commercial use.

Founders should watch for these issues:

• Use of components with licence terms that conflict with your commercial model.
• No record of which packages were used and why.
• Copying code snippets from forums, repositories or AI tools without checking rights.
• Missing copyright notices or attribution requirements.
• Security vulnerabilities in outdated open-source dependencies.

Open-source compliance also intersects with security and data protection. If your product processes personal data, poor dependency management can increase security risk under the UK GDPR and the Data Protection Act 2018. You may need appropriate technical and organisational measures, especially where the developer has access to personal data during build, testing or support.

Documentation and Handover Duties

Documentation is part of the value you are paying for, not a nice-to-have. Without it, your next developer may spend weeks reverse engineering decisions that should have been recorded during the project.

Your agreement should specify the documentation required at each stage. For an MVP, that may be a concise setup guide and API notes. For a live SaaS product, it may include architecture diagrams, deployment instructions, environment variables, database schema notes, incident response procedures and user permission settings.

Handover should also include a defined process. A final zip file or source code escrow arrangement is rarely enough for a serious product. You may need a handover call, a transition period, bug fixes after release, and reasonable IT support services for a new developer.

For example, a healthtech startup changing agencies might need the outgoing developer to explain data flows, admin roles, audit logs, integrations and security controls. The contract should state whether that handover is included in the fee or charged at an agreed rate.

Data, Confidentiality and Customer Materials

Software projects often involve access to personal data, customer records, trade secrets and commercially sensitive product plans. Ownership clauses do not replace privacy and confidentiality obligations.

If the developer processes personal data for your company, you may need a data processing agreement that reflects UK GDPR requirements. This should cover processing instructions, confidentiality, security, sub-processors, international transfers where relevant, assistance with data rights requests, breach support and deletion or return of data at the end of the engagement.

The contract should also make clear that your business materials remain yours. That includes customer lists, datasets, brand assets, product strategy, financial information, API keys, licensed datasets and training materials. If the developer wants to showcase the project in a portfolio, the contract should state when that is allowed and whether your approval is required.

FAQs

Do I Own Custom Code If I Paid the Developer?

Not necessarily. Payment alone does not usually transfer copyright from an external developer or agency to your company. You should have a written assignment of the relevant IP rights, or at least a clear licence that lets you use, modify and commercialise the software.

What Is a Software Assignment Agreement?

A software assignment agreement is a document that transfers intellectual property rights in software from one party to another. It is often used when a founder needs to confirm that a contractor, agency, co-founder or previous developer has assigned rights in custom code to the company.

Can the Developer Keep Reusing Code From My Project?

It depends on the contract. A developer may be able to reuse general skills, know-how and their own background IP, but they should not reuse your confidential information, proprietary product features or assigned custom code unless the contract allows it.

Should My Company Control the Git Repository?

Usually, yes. Company control of the main repository helps prevent disruption if the developer relationship ends. The contract should also deal with commit history, deployment access, backups, documentation and removal of user permissions after handover.

Do Open-Source Components Stop Me Owning My Software?

Not automatically. Open-source components can sit inside proprietary software, but the licence terms matter. You need to know which components are used, what obligations apply, and whether any licence terms affect distribution, disclosure or commercialisation.

Key Takeaways

• External developers and agencies usually keep copyright in code they create unless there is a written assignment or a clear contractual transfer to your company.
• A strong custom code ownership contract should separate new project deliverables, developer background IP, your business materials, open-source components and third party tools.
• Repository access, hosting accounts, credentials, documentation and handover support are practical ownership issues that should be agreed before work starts.
• Open-source software is common in custom builds, but founders should require disclosure of components, licence terms and any obligations affecting commercial use.
• For investor readiness, sale readiness and future maintenance, your company should have a clear chain of title and enough rights to use, modify, support and commercialise the software.

If you are hiring a developer or agency, Sprintlaw can help with your software development agreement, IP assignment wording, open-source and handover clauses, and data processing terms. Contact us on 08081347754 or at team@sprintlaw.co.uk for a free, no-obligations chat.