Do You Actually Own Your Software? A Control Checklist for Non-Technical Founders

Ownership has three parts

Founders rarely put this question to us in the words “do we own our software”. What we hear instead is a set of much more direct worries. Can someone else switch it off? Could anyone else run this if our developer disappeared? We paid for it, so it is ours, isn’t it?

Those are the right things to be asking, and they usually come from the founder who signed the cheques rather than the one who talks to the developers. They are asking about control rather than about copyright law, and control has three components that can each fail on their own.

A product can be fully paid for, working well, and generating revenue while failing all three of those tests. We see it often enough that we treat it as the normal starting position rather than a warning sign, and it is almost never evidence of bad faith by the supplier. It is what happens when a small team builds something quickly, the arrangement works, and nobody has a reason to make any of it explicit until the day the product matters more than it did.

The legal rights

Who owns the copyright by default

Under the Copyright, Designs and Patents Act 1988, the author of a literary work owns the copyright in it, and source code counts as a literary work. If an agency wrote your product, that agency owns the copyright unless your contract says otherwise. Paying for the work does not transfer ownership on its own, and what payment usually buys is a licence to use the result.

That surprises people, so it is worth being precise about when it actually bites. A licence can be perfectly adequate for what you need, provided it is broad, perpetual, irrevocable, and includes the rights to modify and to sublicense. A licence limited to internal use is a different matter, particularly if you intend to sell the product to other organisations, and a licence that can be terminated is a problem whatever else it says.

The four moments when this becomes real

Founders sometimes tell us the distinction feels academic while the product is small and the relationship is good. In practice there are four moments when it stops being academic, and all four tend to arrive with a deadline attached.

• Changing supplier. A new development partner needs the right to modify the code. If your licence does not cover sublicensing or third-party modification, they cannot legally touch it.
• Selling the product or the company. Buyers and their lawyers will ask for a clean chain of title, and a licence held from a third party reduces what they are willing to pay, or stalls the deal while it is fixed.
• Raising investment. Investor due diligence covers IP ownership early. Discovering a gap mid-process costs you leverage as well as time.
• A dispute with the supplier. Rights you assumed you had are worth what the contract says they are worth, and never more.

What to check in your contract

Find the agreement and look for these specific things:

• Assignment or licence. Does the contract assign the intellectual property to you on payment, or grant you a licence? If it is a licence, check whether it is perpetual, irrevocable, and worldwide, and whether it covers modification and sublicensing.
• Trigger conditions. Is the assignment conditional on payment in full? That is normal and reasonable, and you should still confirm the condition has been met and that you can evidence it.
• Pre-existing materials. Most agencies reuse their own frameworks and components, and these are commonly carved out of the assignment and licensed to you instead. Find out what has been carved out and on what terms, because that carve-out is the part that follows you.
• Source code delivery. Does the contract oblige the supplier to hand over source code, and at what point in the engagement?
• Termination. What happens to your rights and your access if either party brings the arrangement to an end?
• Moral rights and subcontractors. If the agency used freelancers or subcontractors, check that their work was assigned to the agency in the first place, because the agency cannot pass on rights it never held.

That last point catches more products than founders expect. A small agency that scaled up with contractors during your build may never have papered the contractor relationships properly, and the gap only appears when a buyer’s solicitor goes looking for it.

Our guide to IP licensing and source code handover works through the contract mechanics in more detail.

Open source and third-party components

Your product almost certainly contains code your supplier did not write. Open-source libraries, commercial components, and software development kits all carry their own licence terms, and those terms travel with the product regardless of who owns the rest of it.

Permissive licences such as MIT, BSD, and Apache 2.0 rarely cause problems. Copyleft licences such as GPL and AGPL can impose obligations when you distribute the software, and AGPL can be triggered simply by offering the software to users over a network, which covers most web products.

What you want is a software bill of materials (SBOM), which is an inventory of every component, its version, and its licence. Modern build tooling generates one automatically, so asking for it is not a large request. When we ask a supplier for an SBOM and they cannot produce one, we treat that as a finding in itself. It usually means nobody has been tracking what the product depends on, or whether those dependencies are still maintained.

Commercial components deserve their own look. A paid library or a third-party control suite may be licensed to the agency rather than to you, and per-developer or per-deployment terms can restrict what you do next. We have picked up systems where a licence sat with an individual developer who had left the supplier, which is a small problem while nobody notices and an awkward one during a customer’s audit.

Possession of the code

Who owns the repository

The question is less about whether you have a copy of the code and more about whether you control the place the code lives.

Check who owns the source control organisation. If your repository sits inside your supplier’s GitHub or Azure DevOps organisation, your access is a permission they grant, and permissions can be revoked, can expire, and disappear altogether when a company closes. What you want is a source control organisation registered to your company, holding the full commit history, with the supplier added as a member of it.

Moving a repository between organisations takes minutes and preserves the history, which makes this one of the easiest items on the list to put right. The history matters more than founders assume, because it is the record of why the system looks the way it does, and a fresh repository seeded with a single initial commit throws that away.

Whether the code you hold can actually be deployed

A zip file of code proves very little on its own. The test we apply is whether a competent engineer who has never seen the system can take what you hold and produce a running deployment from it.

That needs more than source files:

• Build scripts and pipeline definitions
• Infrastructure definitions, for example Bicep or Terraform templates
• Environment configuration, including the full list of required settings and where each value comes from
• Database schema and migration scripts
• Any seed or reference data the system needs to start
• Deployment documentation, ideally demonstrated rather than described

In our experience this is where handovers come unstuck rather than at the legal stage, and the problem stays invisible until somebody actually tries it. The failure is rarely dramatic. It is a missing configuration value, a certificate somebody installed by hand two years ago, or a build step that only ever ran on one laptop. Each is small, and together they are the difference between a product you own and a product you are told you own.

We run this test early in a technical discovery for that reason, and we would rather find six of those problems in week one than one of them during an incident.

Backups, restores, and your data

Ask when a backup was last restored into a working environment, and ask to see the evidence. Backup configuration is easy to set up and restore testing is tedious. It is common to find products where backups have run faithfully for years and nobody has ever confirmed that the data comes back. A backup that has never been restored is a plan rather than a protection.

Two related questions are worth asking at the same time. The first is whether you can export your data in a usable format without the supplier’s help, which is the practical floor of your position if everything else goes wrong. The second is where the production data sits and who can read it, because that shapes what you can tell your own customers under UK GDPR.

Rotate the credentials once you hold the accounts

When you take control, change everything the outgoing team could have seen: cloud access, database passwords, API keys, signing certificates, and third-party service tokens. Do it as a scheduled piece of work rather than opportunistically, and keep a record that you did it.

This is not a judgement on the outgoing team, and we do it on handovers from suppliers we like and expect to work alongside again. It is the same reasoning behind changing the locks when you buy a house, and it is also a question your enterprise customers will ask once they start reviewing you as a supplier.

Operational control of the accounts

This is the part that answers “can someone switch it off”, and contracts rarely cover it.

Every account should be in your company’s name

Work through the list below and, for each item, write down the name of the legal entity that owns the account rather than the name of the person who administers it.

• Cloud subscription. The Azure subscription, AWS account, or equivalent should be owned by your company and billed to your company, with the supplier given access as a guest or through a service principal. Billing ownership matters as much as technical ownership, because it is what proves the account is yours if anyone disputes it.
• Domain names. Registered to your company, with registrar credentials you hold. Domains expire, and an expired domain held by a third party turns into an emergency very quickly.
• DNS. Whoever controls DNS controls where your traffic goes, which makes it one of the highest-leverage items on this list.
• TLS certificates. Usually automated these days, and still worth knowing where they are issued, where they renew, and what happens if the renewal fails.
• App store accounts. Apple Developer and Google Play accounts should be enrolled under your company. Transferring a published app between accounts is possible, and it is a process with conditions attached rather than a click, so it is better done deliberately than in a hurry.
• Payment and identity providers. Stripe, GoCardless, authentication providers, and anything else holding customer or payment data.
• Email and messaging services. Transactional email providers, SMS gateways, and push notification services, along with the sending domains and authentication records that go with them.
• Monitoring and error tracking. Less critical than the rest, and it is where your operational history lives, which is worth keeping.
• Secrets. API keys, connection strings, and certificates belong in a key vault inside your own subscription rather than in a configuration file, a chat thread, or a developer’s laptop.

When we take on a system built by another team, we set all of this up in the client’s name as a matter of course. We do it even where we expect to be running the system ourselves for years. If a client ever wants to move to another supplier, we would rather they could do it without needing anything from us. We say so at the start, because it changes how the rest of the relationship feels.

Keeping a register

Put the list above into a single document with four columns: the service, the account owner, who holds administrative access, and what it costs. Then keep it current.

That register does several jobs at once. It shows you where control actually sits, it becomes the checklist for any future handover, and it is among the first things an acquirer or an enterprise customer will ask you for. Building it takes an afternoon, and keeping it current takes a few minutes a month.

Access should survive a person leaving

A surprising number of small products depend on one individual’s personal account, often a developer who set something up quickly and never revisited it. Check that administrative access to each service is held by at least two people at your company, using company email addresses, with multi-factor authentication enabled.

The failure mode here is mundane and expensive. Somebody leaves, their email is closed, and with it goes the recovery route for an account nobody realised was theirs.

How to work through it

If you want to do this systematically, we would take it in this order, because each step is cheap and each one tells you something that shapes the next.

Steps one to four are administrative, and a founder with a spreadsheet can do them without technical help. Step five is where the real position tends to become clear, which is why we build a maintainability review around it rather than around a document review.

When the supplier relationship is a good one

Most of these conversations happen with a supplier who has done nothing wrong. A small agency builds a competent first version, the product finds a market, and the scale of what comes next sits outside what that agency does. In the cases we see, the supplier has often raised it first, and told the founders plainly that they are not the right firm for the next stage.

That is the best possible moment to sort ownership out. A supplier on good terms will transfer accounts, hand over code, sign an assignment, and answer questions, because none of it costs them anything and it closes the engagement cleanly. They will also tell you things no amount of code reading will reveal, including which parts of the system they were never happy with.

Approaching it as an accusation makes the whole thing harder for no benefit. The framing we find works is simply true: our investors, our insurers, or our enterprise customers are asking, and we need to be able to answer them. We take the same approach when we run a discovery on somebody else’s work. A supplier who feels blamed becomes unavailable, and their knowledge is worth more to our client than the satisfaction of criticising the code.

When the relationship has broken down

If the supplier is unresponsive, in dispute, or already gone, the position is harder and rarely hopeless.

• Work out what you can reach today. Anything held in an account you control is recoverable now, so start there and document it before anything changes.
• Read the contract for termination and handover obligations. These are enforceable, and a solicitor’s letter citing a specific clause often moves a stalled conversation.
• Check whether the running system can be recovered. A deployed application, a database you can back up, and the ability to export your data is a survivable position even without source code, and it buys you the time to plan properly.
• Price the alternatives properly. There is a point at which rebuilding costs less than recovering, and AI-augmented development has moved that point closer than most founders assume. Our guide to modernise, rebuild, or replace sets out how to make the call.

If the supplier has entered administration, the practical constraint is that an insolvency practitioner now controls the assets and has duties to creditors rather than to you. Assets can be sold, including the intellectual property in your product, and a buyer is not obliged to care about your deployment. This is the scenario software escrow is sold to address, and our guide to software escrow covers why an unverified deposit tends to disappoint at exactly this point.

What investors and acquirers check

If you expect to raise money or sell the business, the control audit above is a rehearsal for a process somebody else will run on you, with less patience and a fixed timetable.

Technical and legal due diligence on a software company covers much the same ground, and the findings that hurt valuations are consistent:

• An unclear chain of title, where the IP sits with an agency, a former contractor, or a founder’s earlier company rather than with the entity being bought.
• Open-source licences nobody has reviewed, particularly copyleft components in a product being sold commercially.
• Key-person dependency, where one individual is the only person who can deploy or who understands a core subsystem.
• No history, meaning a repository with no meaningful commit record, which makes it hard to evidence who wrote what and when.
• Undocumented infrastructure, where the running environment cannot be reproduced from anything written down.

Each of those is fixable with notice and awkward without it. A buyer who finds them mid-process will either discount the price, hold money back in escrow pending a fix, or extend the timetable while their lawyers work through it.

The useful part is that the work is the same either way. A founder who has done the audit in this guide, holds a current register, and can produce an SBOM has already assembled most of a technical due diligence pack. They can hand it over rather than build it while negotiating.

Questions you should be able to answer in a sentence

A founder in full control of their product can answer each of these without checking:

• Who owns the intellectual property, and where is that written down?
• Which company owns the cloud subscription the product runs in?
• If our supplier stopped answering the phone today, who deploys the next change?
• When did we last restore a backup, and did it work?
• Which open-source components are in the product, and under what licences?
• Who holds administrative access to each service, and is there a second person for each?

Anything that takes longer than a sentence is the item to start with.

Where to go next

• If your supplier has just left or is winding down: your development team left, what happens next
• For the contract detail behind ownership: IP licensing and source code handover
• If someone has proposed escrow as the answer: software escrow, what it is and when it works
• If you are about to appoint a new partner: tendering for a long-term technology partner
• If enterprise customers are starting to ask about your security posture: the evidence enterprise buyers ask for

We run technical discovery on products built by other teams, and we set infrastructure up in the client’s name as standard so that changing supplier stays possible. If you want an independent view of what you actually control, book a consultation or read about our maintainability review.