Software Development Contract Checklist: IP, SLAs and Escrow (UK)

This is a practical checklist for a business commissioning software, written from the supplier side of a lot of these contracts. It is not legal advice, and a contract of any size should be read by a solicitor before signing — including ours.

1. Intellectual property

• Does IP transfer, and when? “On payment in full” is standard and reasonable. Silence is not.
• What is carved out? A supplier retaining pre-existing tools and libraries is normal — but you need a perpetual licence to use them as embedded in your deliverables.
• Open-source components. Ask for them to be identified. Most are permissive; a copyleft licence in the wrong place is worth knowing about early.
• Is anything licensed back to you rather than transferred? If so, understand exactly what, because that is the lock-in.

2. Termination and handover

The clause nobody reads until it matters. What notice applies, what you pay on termination, and — most importantly — what you receive. A contract that transfers IP but says nothing about handing over repositories, infrastructure configuration and credentials leaves you owning something you cannot access. Spell out the handover.

3. Warranties and what they exclude

A reasonable warranty says the work will be performed with reasonable skill and care and will materially conform to the agreed specification, with a defined period to report defects. Be suspicious of a warranty promising defect-free software — no honest supplier can offer it, and a promise that cannot be met is worth nothing when you try to rely on it.

4. Change control

Requirements change on every project. What matters is whether the contract describes a process — proposed, costed, approved in writing before work starts — or leaves it to goodwill. On a fixed-price contract this clause determines how the inevitable disagreement goes.

5. Accounts, credentials and data

• Hosting, domain and DNS in your name, with the supplier given access rather than ownership.
• Premium licences in your name, not the agency’s.
• App store accounts yours, where relevant.
• A data processing agreement under Article 28 where the supplier processes personal data on your behalf.

What about source code escrow?

Escrow — a third party holding the code, released if the supplier fails — makes sense for licensed software you do not own. For bespoke development where IP transfers to you on payment and the repository is already handed over, it is usually solving a problem you do not have. Ask whether you already hold what escrow would release; frequently you do.

Frequently asked questions

Do we automatically own software we paid for?

Not automatically. Under UK law the author generally owns copyright in commissioned work unless the contract assigns it. Paying for software does not by itself transfer the IP — the contract has to say so, which is why this is the first item on the list.

Is a limitation of liability capped at fees reasonable?

It is standard in software contracts and generally reasonable. What is not acceptable is any attempt to exclude liability for death or personal injury caused by negligence, or for fraud — UK law does not permit it, and its presence tells you something about the contract.

Should we insist on an SLA?

For ongoing support, yes — response times by severity, in writing. For a build project an SLA is less relevant than the change control and warranty clauses, which is where build disputes actually arise.

What if the supplier refuses to transfer IP?

Understand precisely why. Retaining a general-purpose framework they reuse across clients is legitimate; retaining the thing you commissioned is not. If they will not transfer the deliverables themselves on payment, that is worth resolving before signing rather than afterwards.

Our own terms transfer IP in full on payment with no lock-in, and the custom software page sets out how engagements are structured.