Probably not all of it. Under UK law, the person who writes a piece of code owns it, not the company that paid for it. The only exception is an employee doing it as part of their normal job. Contractors, agencies, technical friends who helped out at weekends, and founders who wrote code before the company existed all keep ownership of what they made until they sign it over in writing.

That is the whole problem, and it is close to free to fix before you raise.

Why your company might not own its own code

The rule is simple, and most founders have never heard it: whoever writes the code owns it personally, by default. Your company only becomes the owner if that person was your employee, doing the work as part of their job, or if they have formally signed the rights over to you.

An invoice does not do that. Neither does a purchase order, a Stripe receipt, or three years of a good working relationship.

Courts will sometimes accept that a company has an informal right to use work it paid for. That is what most founders are quietly relying on without knowing it. But permission to use something is not the same as owning it, and it is not what an investor thinks they are buying when they buy shares in your company.

The same logic applies to anything else your product depends on: an invention, a design, a piece of proprietary tooling. If an employee builds it as part of their day job, the company owns it. If a contractor builds it, the company does not, unless there is a signed agreement saying otherwise.

The code you wrote before you incorporated isn't automatically the company's

The most common gap is also the easiest one to miss. You built the first version in the months before you set up the company. You are the founder. You assume it became the company's property the moment the company existed.

It did not. You owned that code personally, and a company cannot simply inherit assets like that. Until you formally hand it over, your own company is technically just borrowing its founder's code.

This is rarely a problem while everyone is on good terms. It becomes a problem in exactly one scenario: a founder leaves, and the company still needs the code they wrote before it was even incorporated.

Contractors and agencies: why ownership doesn't transfer on its own

Development agencies almost always include ownership terms in their contracts. Read them properly. Many will hand over the bespoke work they built for you but keep ownership of their own underlying frameworks, tools and reusable components, and simply license those back to you. That can be a perfectly reasonable deal, but you should know it is the deal you made, rather than finding out about it during due diligence.

Individual contractors are the harder case, because there is often no written agreement at all. A transfer of ownership needs to be in writing and signed by the person giving it up. A Slack message saying "it's yours" is not enough.

What you actually need is a short, signed document covering everything that person built for you, including past work, confirming that ownership sits with the company. Get it signed while they still like you.

AI-generated code and open source: two ownership questions with no easy answer

Two newer questions now come up regularly in investor due diligence, and neither has a clean answer yet.

The first is what happens to code generated with the help of an AI tool. Ownership of AI-assisted output is a genuinely unsettled area, and the answer is not the same for every tool. In practice, investors care less about the theory and more about whether your engineers can explain what was generated, what was reviewed by a person, and whether the tool's own terms give you the rights you assume you have. Check those terms properly.

The second is open source. Some open source licences come with conditions that can attach to the product you build around them, depending on how the code is combined and shared. Running a check on your dependencies takes an afternoon. Being told to rip a component out of a shipping product does not.

The contractor you cannot reach

Sometimes the problem surfaces late. The person who built your MVP has moved abroad, changed their email address, or worked out that your request for a signature is suddenly worth something to them.

Your options at that point are all slower and more expensive: paying for a late signature, rebuilding the component from scratch, or disclosing the gap to investors and accepting a lower valuation to reflect it. The price of getting that signature goes up sharply once a deal is on the table, and it is hard to blame the contractor for knowing it.

An investment round will ask you to confirm, formally, that your company owns its own IP. An undisclosed gap in that ownership becomes a problem after the money lands. A disclosed one is just a conversation.

How to check your startup actually owns its IP

List everyone who has ever written code, designed an interface, or produced anything your product depends on, starting from the very first line. Founders included. For each person, find the signed document that moves what they made into the company. Where there is no document, that is your task list.

Most founders find somewhere between two and five gaps when they do this properly. Almost all of them are simple to close if you start now. Almost none of them are simple to close if you start in the middle of a raise.

Aether helps UK founders get their IP properly assigned and diligence-ready before a raise, from contractor agreements to founder assignments, at aetherlegals.com.