Owning a business application is not the same as having permission to log in or having paid the development invoices. Control is spread across intellectual property rights, source code, data, infrastructure, domains, supplier accounts, documentation and the practical ability to operate or replace the system.
This guide explains the ownership questions a UK business should resolve before commissioning, buying or taking over a web application. It is practical commercial guidance rather than legal advice; the final position depends on the written agreements and the facts of the project.
Start with the outcome the business needs
Different projects need different ownership models. A business commissioning a unique internal system may want broad rights to use, modify and transfer the custom work. A company buying a standard SaaS product will normally receive a limited right to use the service, not ownership of the platform. A supplier may also need to retain reusable tools or framework components that existed before the project.
The useful question is not simply “Do we own it?” Ask whether the business can:
- continue operating the service if the supplier relationship ends;
- appoint another competent supplier;
- access and export important business data;
- maintain and change the custom parts of the system;
- control accounts, billing and renewal decisions;
- prove which rights were assigned and which were licensed.
Separate the assets
| Asset | What the business should establish |
|---|---|
| Custom source code | Who owns the copyright, what rights are assigned or licensed, and whether the repository is complete. |
| Pre-existing supplier components | Which parts remain supplier-owned and what continuing licence the business receives. |
| Open-source and third-party software | Applicable licence conditions, fees, restrictions, notices and replacement risk. |
| Business data | Control, export format, retention, deletion, migration support and data-protection responsibilities. |
| Cloud and hosting | Whose account holds the environments, who controls billing, and how access can be transferred. |
| Domains and DNS | Registrant, administrative access, renewal control and recovery details. |
| Deployment and configuration | Whether pipelines, infrastructure definitions, secrets-management procedures and build instructions are available. |
| Documentation and design assets | Rights to use them and whether they are current enough for another team. |
Understand the difference between assignment and licence
An assignment transfers specified intellectual property rights from one party to another. A licence leaves ownership with the rights holder but permits defined use. A licence may be perfectly suitable when the business buys a repeatable product or the supplier contributes established platform components. The risk arises when the permitted use is too narrow, ends unexpectedly or does not allow maintenance by another supplier.
Do not assume that payment automatically transfers copyright in commissioned software. The contract should identify the relevant work, the owner, the timing of any assignment and the rights granted for material that is not assigned. Obtain specialist advice on the actual wording.
Distinguish access from legal rights
Repository access is operationally important, but it does not itself prove ownership. Conversely, a contract may say that rights transfer while the business still lacks the current code, build process or credentials needed to use those rights.
Check both dimensions:
- legal control: assignment, licence, permitted users, modification, transfer and termination terms;
- practical control: repository access, current branches, releases, deployment, accounts, data exports and documentation.
Account for supplier and third-party components
Most applications combine custom code with libraries, commercial services, templates, APIs and supplier tooling. Requiring ownership of everything may be unrealistic and unnecessarily expensive. Instead, require a component register that distinguishes:
- work created specifically for the project;
- supplier background intellectual property;
- open-source packages and their licences;
- commercial components and subscription services;
- assets provided by the business.
The contract and handover should make clear what happens if a subscription ends, a licence cannot be transferred or a component is no longer supported.
Keep critical accounts under appropriate business control
Where practical, the business should hold or have protected administrative access to critical accounts: domain registration, cloud tenancy, source-code organisation, payment provider, transactional messaging, monitoring and backup services. Day-to-day supplier access can then be delegated and revoked.
Do not share one administrator login. Use named accounts, least privilege and a controlled route for emergency access. Keep recovery methods and billing contacts current.
Plan ownership evidence throughout delivery
Ownership should not be a document reviewed only at project closure. Build evidence into delivery:
- record the agreed ownership model before work begins;
- maintain a component and licence register;
- place current code in the agreed repository;
- verify business access to critical accounts;
- review new third-party dependencies before adoption;
- test that another authorised person can build, deploy and recover the service;
- confirm assignments, licences and handover obligations at acceptance.
Questions to put to a supplier
- Which deliverables will be assigned to the business, and when?
- Which supplier-owned components will remain, and what licence covers them?
- Can another supplier legally and practically maintain the custom system?
- Which accounts are held in the supplier's name?
- How will the business receive code, deployment information, data and documentation?
- What happens to licences and hosted services on expiry or termination?
- How are subcontractor contributions and third-party rights handled?
Ownership readiness check
A useful ownership position exists when the written rights, repository contents, accounts, data and operating knowledge tell the same story. If the business cannot demonstrate those elements, the issue is not solved merely because the contract uses the word “ownership”.