What to check in a software development contract before you sign

Who owns the code - and does the contract actually say so?

This is the single most common gap. Under UK law, unless a contract states otherwise, a freelance developer or agency may retain intellectual property rights in code they write for you, even though you paid for it. Verbal assurances or an assumption that 'obviously it's ours' are not enough.

The contract should state explicitly that intellectual property in the deliverables transfers to you on payment (or on final payment, if staged), and should distinguish this from any pre-existing tools, frameworks or libraries the supplier reuses across clients, which they typically retain rights to license you rather than assign outright. We cover this in more depth in who owns the code.

Source code access and escrow

Owning the IP on paper is only useful if you can actually get hold of the code. The contract should specify how and when you receive the source code - not just the running application, but the actual buildable codebase, documentation and credentials needed to maintain it elsewhere if the relationship ends.

• During the project - code should be kept somewhere you have visibility of, such as a shared repository, not solely on the developer's own machine.
• On completion - a full handover of source code, build instructions and access credentials should be a contractual deliverable, not a favour.
• Source code escrow - for larger or higher-risk projects, a third-party escrow arrangement releases the code to you automatically if the supplier stops trading or breaches the contract. Worth considering for anything business-critical.

Acceptance: how is 'finished' defined?

The contract should set out an acceptance process - a formal point at which delivered work is tested against agreed criteria and signed off, ideally referencing a software requirements specification directly rather than describing scope only in prose.

Without this, disagreements about whether something is 'done' become subjective, and payment can get stuck in a dispute that neither side can resolve by pointing at the contract.

Change control: what happens when scope shifts

Almost every bespoke project changes shape somewhat once building starts - that's normal, and covered in our note on agile vs waterfall. What isn't normal is a contract with no process for handling it. A change control clause should require any change to scope, cost or timeline to be agreed in writing before work proceeds, with a simple mechanism for estimating and approving it.

Warranty: what's covered after launch, for how long?

A warranty period is a window, usually 30 to 90 days after launch, during which the supplier fixes defects - genuine bugs against the agreed specification - at no extra cost. It should be distinguished clearly from paid software maintenance, which covers everything after the warranty ends and any work beyond fixing what was originally specified.

1. 01Check the length of the warranty period and what it explicitly covers.
2. 02Check it's clear that new features or changed requirements aren't covered under warranty as 'bugs'.
3. 03Check what happens next - is there an automatic move to a maintenance agreement, or a gap?

Data protection: UK GDPR obligations

If the system will process personal data - customer records, employee data, anything identifiable - the contract needs a data processing agreement, or clauses covering the same ground, setting out how the supplier will handle that data on your behalf under UK GDPR. This is a legal requirement, not a nice-to-have, when a third party processes personal data on your behalf.

The ICO publishes free guidance on what a compliant data processing arrangement needs to include, and it's worth checking your contract against it directly rather than assuming your supplier has it covered.

A quick pre-signature checklist

• Does it state clearly who owns the finished IP, and when it transfers?
• Does it guarantee you access to source code, both during and at the end of the project?
• Is there a defined acceptance process tied to a written specification?
• Is there a change control process for scope, cost and timeline?
• Is the warranty period and its scope stated explicitly, and distinguished from paid maintenance?
• If personal data is involved, is there a UK GDPR-compliant data processing clause?

None of this replaces proper legal advice - have a solicitor review the final contract, particularly the liability and termination clauses, before signing anything significant. If you'd like to see how we structure ours, our how we work page sets it out, or get in touch to talk through a specific contract you've been sent.