A software development contract checklist is the cheapest insurance policy your business will ever buy. It costs an afternoon of reading and a handful of awkward questions, and it decides whether the system you paid to have built is genuinely yours, whether you can walk away from a supplier who stops performing, and whether the code survives the relationship that produced it.
Most disputes in bespoke software development are not about quality. They are about ownership, access and exit — three things almost nobody negotiates while everyone is still optimistic. The contract gets signed because the price and the timeline look right, and the clauses a software development contract checklist exists to catch get skimmed. Two years later the supplier holds the repository, the intellectual property assignment was never triggered, and moving to another partner means rebuilding from scratch.
This software development contract checklist works through the clauses that matter in the order they cause trouble: intellectual property and ownership, source code and escrow, third-party and open-source components, exit rights and termination, data and security obligations, warranties and liability, and payment and acceptance. Each section gives you the specific wording to look for, the red flag that means you are about to sign something expensive, and the practical fallback when a supplier will not move.
Table of contents
- What a Software Development Contract Checklist Must Cover
- Software Development Contract Checklist: Intellectual Property and Ownership
- Software Development Contract Checklist: Source Code, Repositories and Escrow
- Third-Party Components, Open Source and Licence Risk
- Software Development Contract Checklist: Exit Rights and Termination
- Data, Security and Compliance Clauses
- Software Development Contract Checklist: Warranties, Support and Liability
- Payment, Change Control and Acceptance
- How to Use This Software Development Contract Checklist Before You Sign
- Frequently Asked Questions
- References
What a Software Development Contract Checklist Must Cover
Every clause worth arguing about answers one of four questions. A software development contract checklist that is organised around those questions catches far more than one organised around the contract’s own section headings.
The four questions behind every clause
Who owns what was made? Who can get to it, and how quickly? What happens when one side wants out? And who pays when something goes wrong? Price, timeline and methodology all sit downstream of those four. A contract can be silent on daily stand-ups and still be perfectly safe; a contract that is silent on repository access is not, which is why a software development contract checklist starts with rights rather than process.
Why a checklist beats a template
Supplier templates are not dishonest, but they are written by the supplier’s solicitor to protect the supplier. Client templates are usually adapted from a services agreement that never anticipated software. Working through a software development contract checklist forces both documents to answer the same questions, which is what makes gaps visible. The clause that is missing entirely is always more dangerous than the clause you dislike.
Where the disputes actually come from
Reviewing the shape of software supplier disputes reveals a consistent pattern: the arguments concentrate in a small number of clauses, and they are rarely the ones that took longest to negotiate. Commercial terms get scrutinised because everyone understands money. Ownership, access and exit get waved through because they describe a future nobody wants to imagine — and that is exactly the imbalance a software development contract checklist corrects.
Where software supplier disputes concentrate
Indicative distribution for UK mid-market bespoke builds. Ownership, access and exit account for roughly seven disputes in ten.
The order to review in
Read ownership first, access second, exit third, and money last. That order feels wrong to a finance director and right to anyone who has had to recover a project from a failed supplier. If ownership, access and exit are sound, a bad commercial deal is survivable. If they are not, a good commercial deal is worthless — the reason every item in this software development contract checklist is sequenced that way.
Software Development Contract Checklist: Intellectual Property and Ownership
This is where the most expensive mistakes hide, and where a software development contract checklist repays the time it takes, because the wording that protects you and the wording that does not look almost identical to a non-specialist.
Paying for it does not mean owning it
Under UK law the author of a work is the first owner of copyright in it. When a supplier’s employees write your code, the supplier owns that copyright by default, and paying an invoice does not move it. Ownership transfers only through an express written assignment. Any software development contract checklist that does not open with this point is not doing its job — “the Client shall have full rights to use the Software” grants a licence, not ownership, and the two behave completely differently the day you want to take the code elsewhere.
Assignment, exclusive licence, or something weaker
The three realistic outcomes are outright assignment, an exclusive perpetual licence, and a non-exclusive licence. Each is defensible depending on what you are buying. What is not defensible is discovering which one you signed after the relationship has soured, so a software development contract checklist should force the answer into writing at signature. Compare them on the four things that actually differ.
| Model | Can you modify freely? | Can the supplier reuse it? | Survives supplier insolvency? | Typical price effect |
|---|---|---|---|---|
| Full assignment | Yes, without consent | No, unless carved out | Yes — you own it outright | Highest |
| Exclusive perpetual licence | Yes, if expressly permitted | No, for the licensed field | Usually, if drafted to survive | Moderate |
| Non-exclusive licence | Often restricted | Yes, including for competitors | Risky without escrow | Lowest |
| Silent contract | Unclear — expect a dispute | Yes, by default | No | Cheapest, then ruinous |
Background IP and the supplier’s toolkit
No competent supplier will assign its pre-existing frameworks, libraries and internal tooling, and you should not ask. What you must insist on is that background IP is listed, not merely referenced, and that you receive a perpetual, irrevocable, transferable licence to use it as embedded in your system. An unlisted background-IP carve-out is a blank cheque: it lets a supplier reclassify almost any component as its own after delivery.
Contractors, moral rights and the assignment chain
If the supplier uses subcontractors or freelancers, the chain of assignment has to reach all the way back to the individual who typed the code. Require a warranty that every contributor has assigned their rights to the supplier, so the supplier can assign them onward to you. This part of the software development contract checklist takes one sentence to fix and is close to unfixable once a freelancer has moved on and stopped answering email.
When assignment should be triggered
Assignment on final payment is standard and reasonable. Assignment on full and final settlement of all sums including future support is not — it can leave ownership hostage to an unrelated support invoice years later. Tie the transfer to payment for the work that produced the code, and make it automatic on payment rather than conditional on the supplier executing a further document. A software development contract checklist should treat any assignment that needs a second signature later as unfinished business.
Software Development Contract Checklist: Source Code, Repositories and Escrow
Owning the copyright in code you cannot obtain is a legal position, not a practical one. Access is a separate clause and needs separate attention, and it is the item a software development contract checklist most often finds missing entirely.
Continuous access beats a final handover
The strongest arrangement is simple: the repository lives in your organisation’s account from day one and the supplier is granted access to it. If that is not acceptable, require a mirrored push to a repository you control on every merge to the main branch. A software development contract checklist that only requires delivery of source code “on completion” leaves you exposed for the entire build, which is precisely when a supplier relationship is most likely to fail.
Deliverables are more than the application code
Source code alone will not get a new team running. The list you specify should cover infrastructure-as-code definitions, build and deployment pipelines, environment configuration, database schemas and migrations, seed and test data, secrets held in a manageable form, third-party account ownership, and current architecture and runbook documentation. Anything not listed is, in practice, optional, so this part of the software development contract checklist is worth turning into a literal schedule in the agreement. See our guide to the discovery phase for how these artefacts should be defined before the build even starts.
The cost of reconstructing what you were not given
The gap between having continuous access and negotiating for it after a breakdown is not a legal abstraction — it is a bill. Reconstructing environments, undocumented deployment steps and tribal knowledge is the single most predictable cost of a badly drafted handover clause.
Relative cost to onboard a new supplier (indexed: full documented access = 100)
Indicative multipliers for a mid-sized bespoke system. The access clause, not the ownership clause, drives this number.
When escrow is worth paying for
Source code escrow — a third party holding a verified copy, released on defined trigger events — matters most when the supplier hosts the system and you have no continuous access. It is worth the annual fee for business-critical systems, and close to worthless if the deposit is never verified or updated. If you use escrow, this part of the software development contract checklist has three requirements: scheduled deposits, independent verification that the deposit builds, and release triggers that include insolvency and sustained material breach.
Verify the handover before you need it
Ask for a rehearsal. A supplier who can stand up the system from the repository into a clean environment in front of you has proven the handover works; a supplier who cannot has just shown you the exact risk you were worried about, while you still have leverage. Booking that rehearsal is the most useful thing a software development contract checklist will ever make you do.
Third-Party Components, Open Source and Licence Risk
Most of the code in your system was written by people you have never paid. That is normal and efficient, and it carries obligations your contract has to acknowledge.
Your codebase is mostly other people’s code
A typical modern application is overwhelmingly third-party libraries by volume. Assignment of the supplier’s copyright does not — and cannot — transfer ownership of any of it. What a software development contract checklist asks for instead is a warranty that every component is properly licensed for your intended use, and a list of what is in there.
Copyleft is a commercial decision
Strong copyleft licences can require that derivative works are distributed under the same terms. For an internal web application that is usually irrelevant; for software you intend to license to customers or embed in a device, it can be existential. This item belongs on the software development contract checklist as a business question, not a legal footnote: state your distribution model in the contract, and warrant the components against it.
| Licence family | Typical obligation | Risk if you distribute | Contract action |
|---|---|---|---|
| Permissive | Attribution, keep notices | Low | Require an attribution file |
| Weak copyleft | Share changes to the component | Moderate | Permit only with written notice |
| Strong copyleft | Share the whole derivative work | High if you distribute | Prohibit without prior approval |
| Source-available | Use restrictions, not open source | Commercial and legal | List individually, review each |
| Unlicensed or unclear | None granted | Severe — no right to use | Ban outright in the contract |
Ask for the bill of materials
Require a software bill of materials as a named deliverable, refreshed at each release. It costs the supplier almost nothing to generate from the build pipeline and it converts an unbounded risk into a document you can review. It is also what any acquirer’s technical due diligence will ask for first, which makes it one of the few software development contract checklist items with a direct effect on company valuation.
Generated code and AI assistance
Assistants that suggest code are now standard in professional DevOps practice, and the licensing position of generated output is still developing. The pragmatic clause is a warranty that all delivered code is either original, properly licensed, or generated in a manner that does not encumber your ownership — plus the indemnity that backs it.
Software Development Contract Checklist: Exit Rights and Termination
Exit rights are the clauses that convert everything above from a promise into something you can actually enforce. They are also the ones most often reduced to a single vague sentence, which is why this part of the software development contract checklist deserves the most attention and usually gets the least.
Three ways out, all of which need drafting
Termination for convenience gives you an exit on notice without proving fault, usually with a fee. Termination for cause requires a material breach and a cure period. Termination on insolvency protects you when the supplier fails. A software development contract checklist should confirm all three exist, and that each one triggers the same exit-assistance obligations — a contract where handover duties apply only on expiry is a contract with no exit at all.
Exit assistance must be specific
“Reasonable assistance” means whatever the party with more leverage says it means. Specify the duration, the deliverables, the personnel and the rate. The clause that works reads roughly: on termination for any reason, the supplier will provide up to a defined number of person-days of transition support over a defined window, at agreed rates, including knowledge transfer sessions, current documentation, and a verified handover of code, environments and credentials.
| Exit right | What to insist on | Red flag wording |
|---|---|---|
| Termination for convenience | 30–60 days’ notice, fee capped and stated | Silent, or supplier-only right |
| Exit assistance | Named days, window and rate card | “Reasonable co-operation” |
| Handover contents | Itemised deliverables list | “All relevant materials” |
| Credentials and accounts | Client owns all accounts throughout | Supplier holds domains or cloud tenancy |
| Effect of unpaid invoices | Disputed sums do not block handover | Lien over code or data |
| Survival | IP, confidentiality and exit clauses survive | No survival clause at all |
Never let the supplier hold the keys
Domains, cloud tenancies, app store accounts, payment gateways and DNS should be registered to your organisation with the supplier added as a user. This costs nothing at the start of a project and is the single most common reason an exit turns into a negotiation, so put it near the top of your software development contract checklist rather than in the appendix. If your supplier already holds them, migrating ownership is a reasonable first ask at renewal.
Watch for liens over your own system
Some agreements permit the supplier to suspend service or withhold deliverables while any sum is outstanding, including sums you are legitimately disputing. Narrow this so that only undisputed, overdue amounts can trigger suspension, and so that it can never apply to your data or to code already paid for. Where the commercial model itself is under negotiation, our comparison of fixed-price vs time-and-materials contracts explains how payment structure changes the leverage on both sides.
Data, Security and Compliance Clauses
If the system touches personal data, a second set of obligations applies regardless of what the commercial terms say, and a software development contract checklist has to cover them separately.
The data processing terms are not optional
Where the supplier processes personal data on your behalf, UK GDPR requires a written contract covering subject matter, duration, purpose, categories of data, and the processor’s obligations. Standard data protection schedules exist for exactly this reason. Confirm the schedule is attached and specific to the system being built, not a generic annex describing a different service.
Sub-processors and where the work happens
Development teams are frequently distributed. That is fine, and it needs to be disclosed. Require a list of sub-processors, notice before changes, and clarity on the countries the data and the development environments sit in. Test data derived from production is the usual weak point, and no software development contract checklist should pass it over — the clause that fixes it requires masked or synthetic data in all non-production environments.
Security obligations that outlive the contract
Confidentiality, secure deletion and breach notification must survive termination. Specify what happens to copies held by the supplier after handover: a defined deletion window, written confirmation, and an exception only for backups that are cycled out on a stated schedule. Strong IT governance practice treats that confirmation as a closure requirement, not a courtesy.
Handover speed follows preparation, not goodwill
How long an exit takes is decided by the contract, not by the mood of the parties at the time.
Typical elapsed time to a working handover, in weeks
Indicative elapsed time from termination notice to a new team deploying changes safely.
Software Development Contract Checklist: Warranties, Support and Liability
These clauses decide who pays when the software is wrong, and for how long anyone is obliged to care. They are the part of a software development contract checklist where suppliers expect a negotiation, so there is usually room to move.
A warranty is not a support contract
A defect warranty obliges the supplier to fix, at its own cost, faults that were present at acceptance and reported within a defined period — typically 90 days to 12 months. Support is a separate, paid arrangement covering everything after that. Conflating the two is a common and expensive drafting error; our guide to software maintenance cost after launch sets out what the ongoing arrangement should actually contain.
Liability caps and their exclusions
A cap set at the fees paid is normal in the UK mid-market. What matters more is what sits outside it. Breach of confidentiality, data protection breaches, and IP infringement should be excluded from the cap or carry a materially higher one, because those are the failures whose cost bears no relationship to the project fee. Checking the exclusions rather than the number is what separates a real software development contract checklist from a skim.
The IP indemnity you actually need
Require the supplier to indemnify you against third-party claims that the delivered software infringes their intellectual property, and to fund the defence. Then read the remedies: the standard supplier remedy is to modify, replace or refund. A refund of fees for a system you now cannot use is not a remedy, so negotiate the sequence so that modification and replacement come first.
Insurance that matches the risk
Professional indemnity cover, at a level proportionate to the project, backs every warranty in the contract. Ask for the certificate rather than the assertion, and check that the cover runs for a period after completion — claims tend to arrive later than defects.
Payment, Change Control and Acceptance
Commercial mechanics interact directly with everything above, because payment is what triggers ownership and leverage is what makes exit rights real. A software development contract checklist that stops at the legal clauses leaves half the protection unbuilt.
Tie milestones to acceptance, not effort
A milestone that pays on “completion of development” pays for activity. A milestone that pays on acceptance of defined criteria pays for outcomes. Write the acceptance criteria for each milestone before the work starts, and give yourself a defined testing window with a stated consequence if you miss it — deemed acceptance after a reasonable period is fair, provided the period is genuinely workable.
Retention that lasts to handover
A retained percentage, released on completion of handover rather than on go-live, keeps exit obligations funded. It is a small commercial concession to negotiate and it changes the incentives at the exact moment they otherwise stop being aligned, which is why it belongs on the software development contract checklist next to the exit clauses rather than with the payment terms.
Change control that is not a toll booth
Every bespoke project changes. What a good clause fixes is the process: a defined format, a stated turnaround for quotes, agreed rates for change work that match the original rate card, and a written record. Rates that jump once the contract is signed are the mechanism through which a competitive price becomes an expensive project. The proposal stage is where this is easiest to control — our guidance on writing a software development RFP covers how to get the rate card fixed before the commercial commitment is made.
Who signs off, and how quickly
Name the individuals who can accept deliverables and approve changes, on both sides, with a deputy for each. Decision latency is one of the largest hidden costs in bespoke delivery, and it is a contract problem before it is a management problem.
How to Use This Software Development Contract Checklist Before You Sign
A checklist only helps if it changes what you do next. Three passes, roughly two hours in total, will catch nearly everything that matters.
Pass one: hunt for silence
Read for what is missing rather than what is wrong. Search the document for “assign”, “escrow”, “termination”, “exit”, “sub-processor” and “source code”. A term that never appears is a gap, and gaps are where this software development contract checklist earns its keep. Missing clauses are also the easiest to add, because nobody has to defend wording they never wrote.
Pass two: score, do not just list
Mark each item as sound, weak or absent. Take the absent items and the weak ones that touch ownership, access or exit into the negotiation; leave the rest. A twenty-point list of everything you would prefer reads as obstruction and gets traded away wholesale. A five-point list of things you cannot sign without gets taken seriously, and a scored software development contract checklist is what tells you which five those are.
Pass three: test it against a bad day
Walk the contract through a concrete scenario. The supplier goes into administration in month seven; what do you have, and how do you get it? Ask the same question about a relationship that simply stops working. Structured vendor management rests on exactly this kind of rehearsal, and it exposes clauses that read well and do nothing.
Then get it reviewed properly
None of this replaces advice from a solicitor who does technology contracts for a living. What a software development contract checklist does is make that advice much cheaper and much better targeted, because you arrive with specific questions instead of a document and a hope.
Frequently Asked Questions
Do we automatically own software we paid a supplier to build?
No. Under UK law the author owns copyright first, and payment alone does not transfer it. Ownership passes only through an express written assignment, which is why it is the first item on any software development contract checklist. Wording that grants you the right to “use” the software is a licence, and a licence can be limited, revoked on breach, or made worthless by the supplier’s insolvency.
Is source code escrow still worth paying for?
It depends entirely on where the code lives. If the repository is in your own organisation’s account and you hold the cloud tenancy, escrow adds little. If the supplier hosts everything and you have no continuous access, escrow is the only mechanism that gets you the code when the supplier fails — provided the deposit is verified and kept current. An unverified deposit is a receipt, not a remedy.
What is the single most overlooked clause?
Ownership of accounts and credentials. Domains, DNS, cloud tenancies and app store listings registered to the supplier will quietly become the hardest part of any exit, and this item appears on the software development contract checklist precisely because it costs nothing to fix at the start and a great deal to fix later.
How long should exit assistance last?
For most mid-market systems, 30 to 60 days of defined support with a stated number of person-days is workable. What matters more than the length is that it is measurable, applies on termination for any reason, and has an agreed rate so the obligation cannot be reopened as a commercial negotiation at the worst possible moment.
Can we insist on owning the supplier’s frameworks?
Realistically, no, and it is not the right fight. Ask instead for background IP to be listed explicitly and for a perpetual, irrevocable, transferable licence covering everything embedded in your system. That gives you every practical freedom you need. An unlisted carve-out is the problem, not the carve-out itself.
What if the supplier refuses to change their standard terms?
Prioritise. Take the three items you cannot live without — assignment on payment, continuous repository access, and specific exit assistance — and trade everything else. Small suppliers often refuse from unfamiliarity rather than strategy, and a short side letter amending three clauses is far easier to agree than a redrafted agreement.
Does this apply to a small fixed-price build?
Yes, and arguably more so. Small projects rarely get legal review, use the shortest templates, and are the most likely to be handed to a different supplier within two years. Running a software development contract checklist over a ten-page agreement takes under an hour and protects an asset the business will depend on for far longer than the build took.
