UK Software Development Contract Checklist

You have picked the agency, agreed the number, and a PDF has landed in your inbox with a signature block at the bottom. This is the last moment where you have leverage, and most founders spend about four minutes on it. The contract is not admin — it is the document that decides whether you own the thing you are paying for, what happens when the scope moves, and what you walk away with if the relationship ends badly. Here is what to read before you sign.

This is general commercial guidance, not legal advice. For anything significant, have a solicitor review the actual document.

What should you check in a software development contract?

Check IP ownership first — the contract must assign all rights in the code, designs and deliverables to you, and that assignment should happen on payment of each invoice, not on completion of the whole project. Everything else — scope, change control, milestones, acceptance, warranty, data protection, termination — matters, but none of it saves you if the agency still owns the code when things go wrong.

That distinction between on payment and on completion is the most common trap in the document. A project that stalls at 80% under an "assignment on completion" clause leaves you having paid for a codebase you have no right to use. Assign on payment and every invoice you settle buys you clear title to the work it covered.

The clause-by-clause checklist

| Clause | What good looks like | Red flag | |---|---|---| | IP ownership | Full assignment of all deliverables to you, vesting on payment of each invoice | Assignment "on final payment", or a licence instead of ownership | | Third-party code | Open-source components listed, licences disclosed, no copyleft surprises | Silence on libraries and licensing | | Scope | A written feature list or statement of work, attached as a schedule | "As discussed", or a scope that lives only in an email thread | | Change control | Written request, priced impact on cost and timeline, your sign-off before work starts | Verbal changes, or "reasonable adjustments at our discretion" | | Payment milestones | Tied to delivered, demonstrable outcomes | Calendar-based invoicing regardless of progress | | Acceptance criteria | Defined per feature, with a stated testing window | "Deemed accepted" after a few days of silence | | Warranty | 30–90 days of free bug fixes after handover | No warranty, or bugs billed as new work from day one | | Source-code access | Your repository, your accounts, from the first commit | Code delivered as a zip at the end | | Confidentiality | Mutual, survives termination, covers your data and your idea | One-way, or expires with the contract | | Data protection | UK GDPR terms, a data processing agreement, named sub-processors | No DPA at all | | IR35 | Status position stated for any individual contractors | Nobody has thought about it | | Termination | Either side can exit on notice; you keep what you paid for | Only they can terminate, or a long lock-in | | Exit and handover | Documentation, credentials, deployment guide, transition period | No obligation to hand anything over | | Liability | A capped but meaningful limit, usually tied to fees paid | Liability capped at a token amount, or excluded outright |

Read the contract with that table beside you and mark each row. Anything you cannot find is a question, not an omission to let slide.

Who owns the code — and when?

You should own it outright, and you should own it progressively as you pay. The default position in the UK is that whoever writes a work owns the copyright in it, which means an agency or contractor owns what they produce unless the contract says otherwise. This surprises founders constantly: paying an invoice does not by itself transfer ownership. You need an express assignment in writing.

Look for three specific things:

1. Assignment, not licence. A licence lets you use the code on their terms. An assignment makes it yours. The word you want is "assigns", covering present and future copyright and all other intellectual property rights in the deliverables.
2. A trigger on payment. The assignment should vest as each invoice is paid, so a half-finished project still leaves you owning the half you paid for.
3. A full definition of deliverables. Source code, designs, documentation, database schemas and bespoke assets. Agencies reasonably retain their own pre-existing tools and libraries — that is normal, provided you get a perpetual, royalty-free licence to use them inside your product.

Separately, insist on your own repository from day one. Ownership on paper and possession in practice are different things, and chasing a zip file out of a disengaged supplier is a bad week. If an agency resists this, treat it as a selection problem rather than a drafting one — the signals are in how to choose a software development agency.

What does good change-control look like?

Change is not the problem; undocumented change is. Every build discovers something, and a contract that pretends otherwise will be argued over by week three. What you want is a mechanism that turns each change into a small, explicit decision instead of an invoice-day surprise.

A workable clause has four parts: a change is requested in writing, the agency responds with the cost and schedule impact, you approve or decline, and nothing is built until you have. That protects both sides — it stops you being billed for work you never sanctioned, and stops the agency quietly absorbing scope creep until quality suffers.

Change control interacts with your pricing model. Fixed-price contracts need it most, because a fixed number only means something if the scope behind it is fixed too; time-and-materials contracts need visibility instead, since every change is billable by default. Understand that trade-off before you sign either — see fixed-price vs time-and-materials.

The strongest defence against change disputes happens before the contract exists: a clear, written brief. If your scope came out of a well-structured one, the change-control clause rarely gets used. Our guide to writing a brief for a development agency covers the format.

What about data protection and UK GDPR?

If your product touches personal data — user accounts, email addresses, anything identifying — and the agency will see production data or operate your infrastructure, they are processing that data on your behalf. You are the controller, they are the processor, and UK GDPR requires that relationship to be governed by a written contract.

Practically, look for:

• A data processing agreement, as a schedule or a separate document. It should set out the subject matter, duration, nature and purpose of the processing, the types of data, and the categories of data subject.
• Named sub-processors. Your agency will use hosting, email and monitoring providers. You want that list, and notice before it changes.
• Where data is stored and processed. International transfers need an appropriate safeguard, so "UK or EU region" is the simple answer if your data is sensitive at all. This matters most if you are weighing offshore vs UK development.
• Security measures and breach notification — specific commitments and a defined notification window, not "industry standard practices".
• Deletion or return on termination, so their copies do not linger indefinitely on someone's laptop.

If the agency staffs your build with individual contractors rather than employees, ask how they handle IR35 status determination. Depending on how the engagement is structured, the assessment and the liability that follows it can land with you rather than with them. It is a five-minute question now and a tax problem later.

Your pre-signature checklist

Copy this and work through it before you sign anything:

• [ ] IP assigned to me in writing, vesting on payment, not on completion
• [ ] Deliverables defined: source code, designs, docs, schemas, assets
• [ ] Pre-existing agency tools licensed to me perpetually and royalty-free
• [ ] Open-source dependencies and their licences disclosed
• [ ] Scope attached as a written schedule, feature by feature
• [ ] Change control requires my written approval before work starts
• [ ] Payment milestones tied to demonstrable deliverables
• [ ] Acceptance criteria per feature, with a stated testing window
• [ ] Warranty period for bug fixes after handover — and what it excludes
• [ ] Repository and cloud accounts are mine from day one
• [ ] Mutual confidentiality that survives termination
• [ ] DPA in place, sub-processors named, data location confirmed
• [ ] IR35 position clear for any individual contractors
• [ ] Either side can terminate on reasonable notice
• [ ] Handover obligations spelled out: docs, credentials, transition support
• [ ] A liability cap I could actually live with
• [ ] A solicitor has read it, if the value warrants it

Frequently asked questions

Do I need a solicitor to review a development contract?

For a small first engagement the checklist above catches most of the real risk, but anything material — a five-figure build, your core product, or a contract you did not draft — deserves a couple of hours of a commercial solicitor's time. It is cheap relative to the value of the code, and IP and liability are exactly the clauses non-lawyers misread.

Should the agency hold my repository?

No — the repository should sit in your GitHub organisation, under your account, from the first commit, with the agency added as collaborators. Same for hosting, domain and database accounts. It costs nothing to set up on day one and it is the difference between a clean transition and a hostage negotiation. An agency that insists on holding your code has told you something useful.

What happens if we part ways mid-project?

With assignment-on-payment and your own repository, you keep everything you have paid for and another team can pick it up. Check that termination works both ways on reasonable notice, that you are liable only for work completed to the termination date, and that handover obligations survive termination — that last point is what gets you documentation and credentials rather than just a pile of code.

Is a proposal or SOW enough without a full contract?

A statement of work defines what is being built; it rarely covers ownership, liability, data protection or exit. Most agencies run a master services agreement with an SOW attached per project, which is a sensible structure — but read both, because the terms that matter most to you usually live in the MSA, not in the pretty document.

The bottom line

The clause that matters most is IP assignment on payment. Get that right, keep your code in your own repository, insist on written change control, and make sure there is a DPA if you handle personal data. Those four things cover the overwhelming majority of the ways a development contract hurts a founder.

The rest is negotiation — and how a supplier responds to reasonable contract questions is itself information. A good partner explains their terms and adjusts the unreasonable ones. A bad one tells you it is "just our standard agreement".

Our terms do the boring version of all of this: your repo, your IP from the first commit, scope in writing, and a fixed price you see before we start. See what a build costs, read how we approach software development, or book a free scoping call and we will pin down the scope before anyone signs anything.