Software is the value in most scaling tech businesses. It is also the area where the contracts most often fail to say what founders assume they say.
The assumption is usually the same. We paid for the development, so we own the code. That is not how the law works, and the gap between what you think you own and what you actually own can surface at the worst time. During due diligence, at a funding round, or when a key developer leaves.
Paying for it does not mean you own it
This surprises people every time. Under UK law, if you pay a developer or agency to build software, the intellectual property in that code does not automatically pass to you. Unless the contract clearly assigns it, the developer can retain ownership and simply grant you a licence to use it.
The commercial consequences are serious. If you only hold a licence, you may not be free to sell your business cleanly, change providers, or stop the developer using similar code elsewhere. Buyers and investors check this early, and a weak position here can reduce your valuation or stall a deal.
The fix is an express assignment of intellectual property in writing. Confirm it is there before you assume you own what you paid for.
The open source you did not know was in there
Almost all modern software includes open source components. That is normal and usually fine. The risk is in the licence terms attached to those components.
Some open source licences are permissive and cause no difficulty. Others are far more demanding, and can require you to make your own source code available if you distribute software built on them. For a business whose value sits in proprietary code, that is a genuine commercial threat.
- Do you know which open source components sit inside your product?
- Do you know what each of those licences requires of you?
- Would any of them force you to expose code you consider proprietary?
Most founders cannot answer these questions with confidence. A buyer's technical and legal team will ask them directly, so it is far better to know the answers first.
Development contracts. Where projects go wrong
Whether you build in house, use an agency or work with contractors, the development contract sets the ground rules. When it is thin, disputes follow.
- Scope. What is being built, to what standard, and when? Vague scope is the most common source of cost overruns and arguments.
- Acceptance. How do you confirm the work is actually finished and fit for purpose before you pay in full?
- Warranties. What happens if the software is defective after delivery, and for how long is the developer on the hook?
- Maintenance and support. Who fixes problems later, and on what terms and cost?
A clear development contract is not bureaucracy. It is the difference between a project that stays on track and one that turns into a slow, expensive dispute.
Contractors and the ownership trap
Contractors and freelancers create a specific risk. Employees generally create intellectual property that belongs to the business by default. Contractors do not. The default runs the other way.
So if a contractor wrote part of your core product without a proper assignment in place, they may still own that part. Discovering this during due diligence, when it is too late to fix quietly, is a painful and avoidable position. Every contractor who touches your product should sign a clear assignment of intellectual property.
Escrow and business continuity
If your business depends on software built or hosted by someone else, ask what happens if that supplier fails or goes under. Losing access to critical software with no route to keep it running is a direct threat to the business.
There are contractual ways to protect against this, so the key is to identify the dependency and address it deliberately rather than hoping it never happens.
What to check
- Confirm you hold a written assignment of intellectual property for all software you paid to have built.
- Get an inventory of open source components and understand what each licence requires.
- Make sure development contracts cover scope, acceptance, warranties and support.
- Ensure every contractor and freelancer has assigned their work to the business.
- Identify critical software dependencies and put continuity protection in place.
The bottom line
For a tech business, the software is the asset. If the contracts behind it do not clearly establish who owns what, the value you think you have built may not be fully yours.
This is not a problem to discover during a funding round or a sale, when the pressure is highest and the options are fewest. It is far cheaper to get right early, while it is still a quiet piece of housekeeping rather than a deal breaker.
If you are not certain you own the software your business runs on, get it checked before it becomes the problem. Book a call with the Ethiqs Team