Paying an agency to build your app does not automatically mean you own the copyright in the code.

That is one of the most important — and most frequently misunderstood — parts of outsourced software development in the UK.

The practical version is simple: if an external agency, contractor or freelancer creates software for you, the contract should make ownership explicit. If it does not, the legal position may be very different from what the buyer assumes.

According to the UK Intellectual Property Office's current guidance on commissioned copyright works, the person or organisation that creates a commissioned copyright work is normally the first legal owner unless ownership is agreed otherwise in writing. GOV.UK also states that a transfer of copyright requires a written, signed agreement.

Software is protected by copyright in the UK. GOV.UK's copyright overview explicitly includes software, web content and databases, while section 3 of the Copyright, Designs and Patents Act 1988 treats a computer program as a literary work for copyright purposes.

That means founders should not treat code ownership as a vague commercial courtesy. It is an intellectual-property question that belongs in the contract.

This article explains the practical position for UK app and software projects in 2026. It is general information, not legal advice. For a contract involving material IP value, investment, licensing or a dispute, take advice from a UK solicitor who works in technology or intellectual property.

If you are still choosing a supplier, see LocoWeekend's guide to the best custom software development companies in the UK, our comparison of UK MVP development companies, and freelancer vs agency vs in-house for MVP development.

Note

Editorial disclosure: Wall & Fifth is affiliated with LocoWeekend's publisher and is referenced because it publicly states that clients receive full code, IP, design and infrastructure ownership. That relationship is disclosed because it matters. Independent UK providers with similarly explicit ownership policies are also included below.

The short answer

If a UK agency builds your app, you should not assume that paying the invoice alone transfers the copyright.

The safest commercial position is for the development agreement to state clearly that:

• project-specific source code and object code are assigned to the client;
• project-specific designs and documentation are included;
• the agency has the right to transfer that IP to you;
• subcontractors have assigned any relevant rights into the agency before those rights are passed to you;
• third-party and open-source components remain subject to their own licences;
• repositories, cloud infrastructure, domains, app-store accounts and other operational assets are either client-owned from the start or transferred at handover;
• the assignment takes effect at a clearly defined point, commonly on payment for the relevant work.

Under section 90 of the Copyright, Designs and Patents Act 1988, a copyright assignment is not effective unless it is in writing and signed by or on behalf of the assignor. GOV.UK gives the same practical guidance: copyright can be licensed or sold, but a transfer needs a written, signed document.

The key distinction is therefore:

| Question | What it actually means | |---|---| | Do I have the source code? | You can access the files | | Can I use the software? | You have some form of licence or permission | | Do I own the copyright? | The legal IP rights have been assigned to you | | Do I control the product? | You control the repo, infrastructure, accounts, domains, stores and credentials needed to operate it |

A founder can have one of those without necessarily having the others.

What UK copyright law says about commissioned software

The starting point is more surprising than many buyers expect.

The creator is usually the first owner

The Intellectual Property Office says that when a person or organisation commissions another party to create a copyright work, the creator is normally the first legal owner, not the commissioner, unless ownership is agreed otherwise in writing.

That rule matters for software because computer programs are copyright works in the UK.

So if a founder hires an independent developer to build an app and the contract says nothing about IP, the founder should not assume that payment automatically makes them the copyright owner.

The buyer may have an implied licence to use the work in some circumstances, but the IPO specifically warns that this does not necessarily transfer ownership. An implied licence and ownership are different things.

Employees are different

Section 11 of the Copyright, Designs and Patents Act 1988 provides an important exception for employees.

Where a copyright work is created by an employee in the course of employment, the employer is normally the first owner, subject to any agreement to the contrary.

That creates a common software-development chain:

agency employee → agency owns the employee's work → agency assigns project IP to client.

But outsourced teams are not always made up exclusively of employees.

Subcontractors are where the chain can become messy

An agency may use freelance engineers, specialist designers, offshore developers or independent contractors.

Those people are not automatically covered by the employee rule.

If a freelancer creates copyrightable code for the agency, the freelancer may initially own that copyright unless their agreement assigns it to the agency. The agency then needs a clean right to pass the relevant project IP on to its client.

That is why a serious client agreement should not only say “you own the code”. It should also give the agency responsibility for ensuring it has obtained the rights it is promising to transfer.

This is often referred to as the chain of title: the sequence showing how ownership moved from the people who created the work to the party that ultimately owns it.

Copyright assignment versus a licence

These terms are often used interchangeably in casual conversations. Legally, they are not the same.

The UK Government's current guide to IP in agreements describes the difference cleanly: an assignment transfers ownership, while a licence permits use without changing ownership.

Assignment

If the agency assigns the copyright in the project code to you, you become the owner of that copyright, subject to the exact scope of the assignment and any third-party rights.

Section 90(3) of the Copyright, Designs and Patents Act says the assignment must be written and signed by or on behalf of the person transferring the rights.

That is why an agreement containing a proper IP-assignment clause matters.

Licence

A licence gives you permission to use software that somebody else still owns.

That can be completely legitimate.

SaaS platforms work this way all the time: customers pay to use software without owning its source code or copyright. Some development agencies also build on proprietary frameworks that they retain and license to clients.

The commercial question is whether that is what you actually intended to buy.

If a founder believes they commissioned a unique product that can later be sold, funded or moved to another developer, a licence-only arrangement may be materially different from what they expected.

Why source-code access is not the same as ownership

A GitHub repository is not a title deed.

An agency can give a client access to a repository while retaining copyright. Equally, a client can legally own code while still being operationally dependent on an agency account if the repository, cloud environment or deployment keys were never handed over.

Both legal ownership and practical control matter.

A useful way to test practical independence is to ask:

Could another competent development team take over this product next week without needing permission from the original agency?

If the answer is no, find out why.

Possible blockers include:

• the GitHub or GitLab repository belongs only to the agency;
• the production database sits in an agency-owned cloud account;
• the Vercel, AWS, Azure or Google Cloud organisation is not accessible to the client;
• the domain is registered in the agency's name;
• Stripe or another payment account belongs to the supplier;
• Apple App Store or Google Play listings are controlled by the agency;
• environment variables and deployment secrets have not been documented;
• design files remain inside an agency-owned Figma workspace;
• build scripts or internal tooling required for deployment were excluded from handover.

None of those issues automatically determines copyright ownership. They determine whether the client can operate the product they supposedly own.

What should actually be transferred when an app is handed over?

For a conventional custom product where the client is meant to own the result, the handover should usually be broader than a ZIP file containing source code.

1. Source-code repositories

You should know where the canonical repository lives and who administers it.

That normally means access to:

• application source code;
• backend code;
• database migrations and schema;
• infrastructure-as-code where used;
• deployment configuration;
• automated tests;
• build scripts;
• relevant technical documentation.

For active projects, many teams give the client repository access during development rather than waiting until the final day.

2. Cloud infrastructure

A production app may depend on AWS, Vercel, Supabase, Firebase, Azure, Cloudflare or similar services.

If those resources sit inside an agency account indefinitely, the client remains operationally dependent even if the contract says the client owns the IP.

A cleaner setup is either client ownership from the beginning or a documented transfer at handover.

3. Domains and DNS

The domain is often one of the most commercially important assets in the product.

It should be obvious who the registrant is, which account controls DNS and how access is recovered if a team member leaves.

4. App-store accounts

For mobile products, clarify who owns the Apple and Google developer accounts and store listings.

The product should not become hostage to an agency relationship simply because the original supplier created the store listing under its own account.

5. Design files

If the agency created original product design, the contract should clarify whether the client receives the relevant design rights and editable files as well as screenshots or exported assets.

That may include Figma files, design systems, icons, custom illustrations and brand assets created specifically for the product.

6. Documentation and credentials

The practical value of code drops quickly if nobody knows how to run it.

A useful handover may include:

• environment-variable inventory;
• deployment instructions;
• architecture notes;
• external-service inventory;
• API documentation;
• database backup and restore procedures;
• test credentials where appropriate;
• admin-user setup;
• known issues and technical debt.

The exact list depends on the product, but the principle is simple: another qualified team should be able to understand and operate the system.

What you do not automatically own: open-source and third-party software

No realistic modern application is 100% original code.

A React application may use React itself, Next.js, PostgreSQL libraries, Stripe SDKs, authentication libraries and hundreds of package dependencies. An AI product may call OpenAI, Anthropic or another model provider. A mapping app may depend on Google Maps, Mapbox or HERE.

The client does not suddenly own those third-party technologies because an agency used them in the project.

Instead, they remain governed by their own licences and service terms.

HMRC's current software-licensing engineering standard makes the principle explicit: organisations need to understand the licences of open-source code they depend on because different licences can affect how software can be used, modified and distributed.

So a sensible IP clause distinguishes between:

Project IP — original code, designs and documentation created specifically for the client; and

Background / third-party IP — pre-existing agency tools, open-source libraries, vendor SDKs and external platforms that are not being transferred as original client property.

The client should still receive all rights reasonably required to operate the finished product.

What about an agency's reusable internal code?

This is another area where absolute language can become unrealistic.

Suppose an agency has built a generic authentication helper, deployment script, analytics wrapper or internal component library before your project starts.

It may use that same tool across several client projects.

The agency may reasonably retain ownership of that pre-existing material rather than assigning it exclusively to one client.

What matters is that the contract distinguishes it from the bespoke product IP and gives the client a sufficient licence to keep using anything embedded in their app.

Otherwise a clause saying “client owns everything” can conflict with the reality of modern reusable software engineering.

When should ownership transfer?

Agencies structure this differently.

One common model is for ownership to transfer once the relevant invoices have been paid.

That makes commercial sense: the client receives the IP it has paid for, while the supplier does not assign unpaid work.

Current public policies show this approach in practice.

thoughtbot's public consulting playbook says its contract provides that the client owns each week's source code once that week's invoice has been paid.

CodeLeap similarly states that clients receive all code and IP on payment.

The exact trigger should be written clearly. Ambiguity about whether ownership transfers on creation, milestone payment, full project payment or final handover is unnecessary.

What current UK software companies publicly say about code ownership

Several UK product companies now make their ownership position unusually explicit.

Wall & Fifth

Wall & Fifth says clients own the full codebase, infrastructure and store listings, with no licensing or platform lock-in. Its MVP service goes further, stating that clients receive 100% of the code, IP and design.

The important part commercially is not only the copyright claim. The company also says infrastructure and store listings are handed over, which addresses practical product control alongside IP ownership.

GoodCore

GoodCore states that clients retain full ownership of software created for them and that its contracts establish the relevant IP rights.

Its SaaS service similarly says the client is the exclusive owner of the finished product, while its case studies describe full codebase and infrastructure handover on bespoke platforms.

CodeLeap

CodeLeap says the code and IP belong to the client outright once the product is delivered and paid for, and that editable design files are included.

Its infrastructure service also says the operational setup is designed to be handed over, with infrastructure-as-code, documentation and credentials intended to remain portable.

thoughtbot

thoughtbot publicly describes a weekly ownership model: the client owns that week's source code once the corresponding invoice has been paid.

These are public statements rather than substitutes for reading the actual contract. The signed agreement remains the document that matters for a specific project.

Seven things to check in a software-development agreement

Before signing, a founder or buyer should be able to answer these questions clearly.

1. Who owns newly created project IP?

Look for a direct statement covering the code and other relevant project outputs.

Avoid relying on phrases such as “full access” or “the software is yours to use” if what you actually want is ownership.

2. Is there a written copyright assignment?

If the intention is to transfer copyright, the agreement should actually assign it rather than merely granting usage rights.

Under UK law, assignment must be in writing and signed by or on behalf of the assignor.

3. Does the agency warrant that it has rights from employees and subcontractors?

The client should not discover later that a freelance developer who contributed a critical subsystem never assigned their rights.

4. What is excluded from the assignment?

Open-source code, third-party software and genuine pre-existing agency IP should be identified conceptually rather than hidden inside a vague carve-out.

5. When does ownership transfer?

On creation? On milestone payment? On final payment? At formal handover?

There should be a clear answer.

6. Who controls the operational accounts?

Check repository, cloud, domain, DNS, app stores, analytics, payment provider, email infrastructure and any other critical external account.

7. What happens if the project ends early?

If the agency relationship ends at week six of a twelve-week project, who owns the paid work? What repositories and documentation are delivered? Can another team continue?

Termination clauses matter most when the relationship is already going badly, so they are worth understanding while it is still going well.

Red flags before signing

A development contract deserves closer attention if:

• the agency refuses to say who owns the source code;
• “ownership” is promised on the website but not reflected in the agreement;
• the client receives only a perpetual licence when they expected assignment;
• the agency retains an unrestricted right to withhold the repo after all relevant invoices are paid;
• the contract does not address subcontractor IP;
• there is no distinction between project-specific IP and third-party dependencies;
• production infrastructure must remain in the agency's account indefinitely;
• the client cannot move the product to another development team;
• a platform licence or monthly fee is required simply to keep using the custom software after development ends;
• key handover assets are undefined.

None of those facts automatically means the supplier is acting improperly. Some software business models intentionally rely on licensing or managed infrastructure. The issue is whether the buyer understands and accepts that model before signing.

Is full code ownership always necessary?

No.

There are plenty of situations where licensing is perfectly sensible.

If you commission a solution built on an agency's mature proprietary platform, the lower cost may depend on reusing that platform. Requiring exclusive ownership of the entire underlying system would be commercially unrealistic.

Similarly, if your business is buying ordinary SaaS, ownership is not the objective at all. You are paying for access to a maintained service.

Full project-IP ownership matters most when:

• the software itself is a core company asset;
• you expect to raise investment against the product;
• another buyer may eventually acquire the business;
• you need freedom to change development supplier;
• proprietary workflows or technology contribute materially to company value;
• you intend to licence the product to others;
• the app is the primary product rather than an internal convenience.

The right question is not “Must I own every line of software involved?”

It is “Do I own and control enough of this product to operate, modify, finance and sell the business without being trapped by the original supplier?”

Why investors and acquirers care

Software ownership becomes much less theoretical during due diligence.

An investor or acquirer may want evidence that the company actually owns the IP it claims is valuable.

Questions can include:

• Who wrote the code?
• Were they employees or contractors?
• Were contractor rights assigned?
• Does the company own the repository?
• Are there restrictive third-party licences?
• Is core software dependent on a supplier that could terminate access?
• Who controls infrastructure and production accounts?
• Are there disputes over ownership?

A weak chain of title can turn what founders think is a technical housekeeping issue into a financing or transaction issue.

That is one reason to resolve ownership at the start rather than trying to reconstruct it years later.

Does paying for the app mean I own it?

Not automatically.

The IPO's guidance on commissioned works is explicit: the creator of a commissioned copyright work is usually the first owner unless ownership has been agreed otherwise in writing.

Payment can be part of the commercial arrangement that triggers an assignment, but the transfer should still be documented properly.

Can an agency legally keep ownership of code I paid it to build?

Potentially, yes, if that is what the contract provides or if there was no effective transfer of copyright.

The commercial fairness of that arrangement is a separate question from the legal ownership position.

Some suppliers deliberately licence software rather than assign it. Others assign all bespoke project IP. Both models can exist; the buyer needs to know which one they are purchasing.

Do I own open-source code inside my app?

No. Open-source components remain subject to their own licences.

You can receive ownership of the original project code created for you while still relying on libraries owned by other copyright holders and licensed under MIT, Apache, GPL or other terms.

That is normal modern software development.

Should the GitHub repository be in my company's account?

It is usually a strong practical signal of control, but repository location alone does not determine copyright ownership.

A client-owned organisation can make handover easier, while an agency-owned repository can still be transferred later. What matters is that the contract and operational setup both support the level of independence the buyer expects.

What happens if the agency goes out of business?

If the client already controls the repository, infrastructure accounts, documentation and relevant IP rights, the product is far easier for another team to continue.

If everything sits inside supplier-owned systems, the failure of the agency can create avoidable operational risk even where the client believes it owns the product.

What should I ask an agency before hiring them?

Ask one direct question:

“After I have paid for the project, can I give the complete product to another development team and continue operating it without needing your permission or paying you a licence?”

Then confirm that the written agreement, repository setup and infrastructure arrangements actually support the answer.

The bottom line

For UK commissioned software, ownership should never be left to assumption.

The law starts from the creator as first owner of commissioned copyright unless the parties agree otherwise. A copyright assignment needs to be written and signed. Software itself is protected by copyright, and third-party code remains subject to its existing licences.

For founders buying a custom app, the strongest arrangement is therefore usually a clear written assignment of project-specific IP plus practical control of the repository, infrastructure, design files and operational accounts needed to run the product.

That does not require pretending every open-source package or pre-existing agency tool belongs to the client. It requires drawing the boundary clearly.

If a supplier says “you own everything”, the next question is not whether the sentence sounds reassuring.

It is whether the contract and handover process make it true.

Sources and review date

This article was researched and reviewed on 8 September 2026.

Primary legal and government sources:

• UK Intellectual Property Office — Ownership of copyright works
• GOV.UK — How copyright protects your work
• GOV.UK — Using somebody else's intellectual property: copyright
• GOV.UK — License, sell or market your copyright material
• GOV.UK — KAM Guide: IP in agreements
• Copyright, Designs and Patents Act 1988
• HMRC Engineering — Software licensing

Current supplier ownership policies reviewed:

• Wall & Fifth — App Development
• Wall & Fifth — MVP Development
• GoodCore — Software Development Services
• CodeLeap — Product Development
• thoughtbot — Consulting Playbook

Supplier statements describe those companies' current published positions. A specific client's rights are determined by the agreement they actually sign and the facts of the project.