Introduction
Commissioning custom software without a properly structured agreement is one of the most expensive mistakes a UK business can make. Vague scopes lead to cost overruns. Missing IP assignment clauses mean you pay to build software you don't legally own. Absent acceptance criteria turn delivery disputes into drawn-out negotiations.
Those consequences aren't hypothetical. UK government digital programmes reviewed in 2022–23 showed just 13% rated green — with 71% amber and 16% red across 31 programmes. Weak contractual foundations drive many of those failures. Private sector projects carry the same structural risk.
This guide covers what a custom software development agreement must include and how to structure one using an MSA and SOW framework. It focuses on the clauses UK businesses — especially those in regulated sectors — must get right before a single line of code is written.
Key Takeaways
- Without a written IP assignment clause, the developer retains ownership of the code by default
- MSAs govern the relationship; SOWs govern each project
- Payment should be tied to milestone acceptance, not calendar dates
- UK GDPR requires a Data Processing Agreement if the developer accesses personal data
- Liability caps must carve out IP infringement, data breaches, and gross negligence
What Is a Custom Software Development Agreement?
A custom software development agreement is a legally binding contract that sets out the scope of work, deliverables, payment terms, IP ownership, and obligations of both parties. Unlike a software licence, the risk of design, development, and product-market fit sits with the client — because you're commissioning something that doesn't yet exist.
Commissioning a bespoke build — rather than buying a finished product — makes these agreements complex in a specific way. Both parties are collaborating on something that evolves. The contract must be flexible enough to accommodate change while precise enough to prevent disputes over scope, ownership, or non-delivery.
Why Getting This Right Matters
Consider the scale of what goes wrong when agreements are weak. Five major UK digital change programmes resulted in at least £3 billion in increased reset and extended legacy-system costs, with individual programmes like Universal Credit running £912 million over budget and six years late.
Private sector projects don't make headlines, but they face the same root causes: undefined scope, no acceptance criteria, and agreements that don't allocate risk clearly between client and developer.
MSA vs Statement of Work: The Two-Layer Structure
Most well-structured software development engagements use two documents rather than one.
The Master Service Agreement (MSA)
The MSA is the overarching legal document that governs the entire relationship. It covers:
- Payment terms and invoicing procedures
- Confidentiality obligations
- IP assignment and ownership
- Liability caps and exclusions
- Warranties and representations
- Dispute resolution mechanisms
- Governing law
An MSA typically runs for multiple years or indefinitely. Once signed, it doesn't need renegotiating for every new project, which matters when you're running multiple builds or sprint phases with the same development partner.
The Statement of Work (SOW)
The SOW is the project-specific document attached to the MSA. Each SOW defines:
- Scope and deliverable descriptions
- Team composition
- Milestone dates and acceptance criteria
- Estimated budget and fee structure
- Change request procedures
Thomson Reuters describes the MSA as the foundational relationship contract and the SOW as the narrower project document covering scope, timeline, and cost. In practice, this means executing a new project requires only a new SOW — the legal framework stays in place and doesn't need revisiting each time.
Key Sections of a Custom Software Development Agreement
Scope of Work and Functional Specification
This is the highest-risk section in any software development agreement. Vague scope is the primary cause of cost overruns and disputes — and "the software will do X" without measurable criteria is not a scope definition.
A properly drafted scope section should include:
- Project description — what the software is and what business problem it solves
- Functional Specification — what the software will do, feature by feature
- Technical Specification — the architecture, tech stack, and integration requirements
- Out-of-scope statement — explicitly listing what is not being built
- Change request procedure — requiring written sign-off from both parties before any scope change takes effect
Capital Compute structures this through a discovery phase, where GDPR-compliant data architecture and compliance obligations are scoped before development begins — not retrofitted after go-live.
Milestones, Deliverables, and Acceptance Criteria
Each milestone should have four elements:
- A defined deliverable description
- A due date
- An acceptance testing period with a clear start and end
- Explicit criteria defining what "passing" looks like
The contract must also specify what happens on failure — re-delivery windows, permitted revision cycles, fee adjustments, or termination rights. Without this, a developer can deliver non-functional software and claim they've met the milestone.
Capital Compute conducts fortnightly sprint reviews with client approval gates at every milestone, meaning acceptance is formally confirmed before the next phase begins.
Payment Terms and Fee Structure
Three common models exist:
| Model | Description | Best For |
|---|---|---|
| Fixed price | Agreed total fee for defined scope | Clearly scoped projects |
| Time and materials | Billing at hourly/daily rates | Exploratory or evolving builds |
| Dedicated team | Monthly fee for a named engineering team | Long-term product development |
Regardless of model, the contract must state:
- How and when invoices are issued
- What triggers payment (milestone acceptance, not just delivery)
- How invoice disputes are handled without the developer pausing work
Milestone-based payment is the most client-protective structure. A typical split might be: 25% on signing, 25% on beta delivery, 50% on final acceptance — with each tranche tied to accepted deliverables, not calendar dates.
Intellectual Property Ownership and Assignment
This is the clause UK businesses most frequently get wrong.
Under the Copyright, Designs and Patents Act 1988, the creator of the work is the first copyright owner (sections 9 and 11). An independent contractor — unlike an employee — does not automatically assign copyright to the commissioning client just because they were paid. Section 90(3) makes this explicit: a copyright assignment is only effective if it is in writing and signed by the assignor.
The consequences of silence are severe. In Clearsprings Management Ltd v Businesslinx Ltd [2005], a client commissioned a web-based database under a contract that didn't address copyright ownership. The court refused to imply either an assignment or an exclusive licence — the client received only a non-exclusive, royalty-free licence to use the software for its own business.
A properly drafted IP clause should:
- Designate all custom deliverables as works created under this agreement
- Assign all IP to the client upon full payment
- Require the developer to disclose all pre-existing and open-source components in a written inventory
- Grant the client a perpetual licence to any developer background technology incorporated into the deliverables
Capital Compute positions code ownership as a client right from day one, with documented APIs that clients can extend independently or hand to a different partner.
Confidentiality and Data Protection
The agreement should define:
- What constitutes confidential information
- Each party's obligations to protect it
- How long those obligations survive termination
- Whether a Data Processing Agreement (DPA) is required
On UK GDPR specifically: if the development partner will access, store, or process personal data during the project — even for testing — the agreement must include or attach a DPA. The ICO specifies eight compulsory areas that controller-processor contracts must cover:
- Documented processing instructions
- Security obligations
- Sub-processor controls
- Data subject rights assistance
- Deletion requirements on termination
The ICO issued two UK GDPR penalty notices totalling £3,826,320 in 2024/25 — including a £3,076,320 penalty against Advanced Computer Software Group for infringement of Article 32(1). Failure to attach a DPA exposes both parties to direct ICO enforcement action.
Termination and Post-Termination Obligations
Every agreement should address how it ends — whether on good terms or not. The contract must cover three scenarios:
- Termination for convenience — with defined notice periods (typically 30–90 days)
- Termination for cause — triggered by material breach, insolvency, or persistent non-delivery
- Post-termination obligations — delivery of all work product, return or deletion of confidential data, IP transfer on receipt of outstanding payment, and transition assistance
Custom Software Development Agreement Template: Section-by-Section Walkthrough
This template covers the nine clauses that appear in most custom software agreements — from scope and payment through IP ownership, liability, and termination. Use it as a working draft, not a finished document. Each clause includes bracketed placeholders where your specific terms go. Review the completed agreement with a solicitor before signing, especially if you operate in a regulated sector.
1. Parties and Effective Date
[Client legal name, registered address, company number] and [Developer legal name, registered address, company number]. Effective date: [DD/MM/YYYY].
2. Scope of Work
Project description: [describe the software and its purpose]
Deliverables:
- [Deliverable 1 — description and format]
- [Deliverable 2 — description and format]
Acceptance criteria: [define measurable pass/fail criteria for each deliverable]
Milestone schedule:
- Milestone 1: [description] — due [date]
- Milestone 2: [description] — due [date]
Change request procedure: Any change to scope, timeline, or budget must be submitted in writing using the agreed Change Request Form, signed by authorised representatives of both parties, and accompanied by a revised fee before work commences.
3. Payment Terms and Schedule
Milestone-based default structure:
- 25% on signing
- 25% on acceptance of beta milestone
- 50% on final acceptance
Payment is triggered by written acceptance of the relevant milestone deliverable, not by delivery date alone. Invoice disputes must be raised in writing within [X] business days of receipt; the developer may not suspend work during a good-faith dispute resolution process.
4. Intellectual Property Assignment
This is one of the most negotiated clauses in any software agreement. Confirm IP transfers on full payment, not delivery — and ensure all third-party libraries are declared upfront.
(a) All custom code, documentation, and deliverables created under this agreement constitute works made for hire and are assigned to the Client upon receipt of full payment.
(b) The Developer warrants that it has disclosed, in a written inventory attached as Schedule [X], all pre-existing IP, third-party libraries, and open-source components incorporated into the deliverables, together with their applicable licence terms.
(c) The Client is granted a perpetual, royalty-free, irrevocable licence to any Developer background technology incorporated into the deliverables.
(d) The Developer will execute any additional documents reasonably required to give effect to this assignment.
5. Confidentiality
Each party agrees to hold the other's confidential information in strict confidence for [duration] years following termination. Confidential information excludes anything in the public domain or independently developed. A Data Processing Agreement is attached as Schedule [Y] where the Developer processes personal data.
6. Warranties and Acceptance
The Developer warrants that deliverables will materially conform to the agreed specification. Acceptance testing will run for [X] business days per milestone. If a deliverable fails testing, the Developer has [X] business days to remedy. After [X] failed remedy attempts, the Client may terminate and recover fees paid for unaccepted milestones.
7. Limitation of Liability
The cap protects both parties — but certain categories cannot be limited by law. Make sure your solicitor reviews these carve-outs against your sector's specific regulatory exposure.
Each party's aggregate liability is capped at the total fees paid or payable under the relevant SOW. Excluded from this cap (uncapped):
- IP infringement
- Confidentiality breaches
- Gross negligence or wilful misconduct
- Death or personal injury caused by negligence (non-excludable under the Unfair Contract Terms Act 1977)
8. Termination
Either party may terminate for convenience with [30/60/90] days' written notice. Either party may terminate immediately for material breach unremedied within [14/30] days of written notice. On termination, the Developer will deliver all work product, delete or return confidential data, and transfer IP on receipt of any outstanding payment.
9. Governing Law and Signatures
This agreement is governed by the laws of England and Wales. Disputes will first be referred to senior management negotiation, then to mediation, then to the courts of England and Wales.
Signed for and on behalf of [Client]: ___________ Signed for and on behalf of [Developer]: ___________
Important: This template is for reference only and should be reviewed by a qualified solicitor before use — particularly for clients in legal, finance, healthcare, or other regulated sectors where additional data handling and compliance obligations apply.
Critical Clauses UK Businesses Must Get Right
GDPR and Data Processing Obligations
If the developer will access personal data at any point — including using real data in testing environments — the agreement must include a compliant DPA. This applies regardless of where the developer is located. ICO guidance confirms that a UK controller remains responsible for ensuring an overseas processor meets Article 28 standards contractually.
The DPA must specify:
- Lawful basis for processing
- Categories of data and data subjects
- Processor security obligations
- Breach notification timelines (72 hours under UK GDPR)
- Deletion or return of data at contract end
Subcontracting Restrictions
Clients should require written consent before the developer engages any subcontractor, with the prime contractor remaining fully liable for any subcontractor's acts, omissions, and IP assignments.
When work passes through freelancer networks, IP ownership can become fragmented. Multiple contributors may have claims over code they wrote, creating chain-of-title disputes that surface after project close. Choosing a partner who uses only an internal engineering team — such as Capital Compute — removes this risk category entirely and keeps chain-of-title clean from first commit to handover.
Liability Caps and Exclusions
The standard approach in technology contracts is to cap aggregate liability at the total fees paid or payable under the relevant SOW. However, Norton Rose Fulbright's technology contract guidance notes that data and security-related caps are often negotiated at 100–500% of fees, given the outsized downstream exposure these incidents carry.
UK businesses should watch for developer contracts that exclude all indirect and consequential losses. If a delivery failure disrupts your revenue-generating operations, those losses are typically indirect — meaning you'd have no recovery without a carve-out.
Source Code Escrow and Handover Provisions
The contract must require delivery of:
- Full source code (not just compiled binaries)
- Technical documentation
- API specifications
- Versioned repository access
This ensures you can maintain or enhance the software through your own team or a different partner after project close. Partners who deliver documented, versioned APIs as a standard output — rather than on request — make this transition significantly easier for client teams or incoming developers.
Common Mistakes to Avoid
Three contract errors account for the majority of UK software development disputes. Recognising them before you sign is far cheaper than litigating them afterward.
1. Vague Scope and Missing Acceptance Criteria
"The software will do X" is not an acceptance criterion. A watertight clause defines what passing looks like, who conducts testing, the length of the testing period, and how many revision cycles are permitted before fees are adjusted or the contract may be terminated.
2. Assuming Payment Automatically Transfers IP
It doesn't. Under UK law, the developer owns the code until it is explicitly assigned in writing. Many UK businesses discover post-delivery that they hold a licence — not ownership — of software they paid to build. Clearsprings v Businesslinx is the cautionary precedent here.
3. No Change Control Process
Verbal scope changes during development are unenforceable. Every change must follow a written change request process, signed by authorised representatives on both sides, with a revised fee agreed before work begins. Capital Compute, for example, scopes and agrees each sprint in writing before work starts, invoicing only on successful delivery of that agreed scope.
Frequently Asked Questions
What is the difference between an MSA and a Statement of Work in a software development agreement?
The MSA is the overarching legal framework covering IP, liability, confidentiality, and dispute resolution for the entire relationship. The SOW is the project-specific document defining scope, deliverables, milestones, and fees. New projects are executed by issuing a new SOW under the existing MSA — without renegotiating the legal framework each time.
Who owns the intellectual property created under a custom software development agreement?
Under UK law (CDPA 1988, sections 9 and 11), IP is owned by the creator unless explicitly assigned in writing. UK businesses must ensure the contract includes a signed, written assignment of all custom code to the client upon payment. Background technology and open-source components must be addressed through separate licence provisions within the same agreement.
What GDPR obligations must a software development agreement address for UK businesses?
If the developer accesses personal data, the agreement must include a Data Processing Agreement specifying processor obligations, security measures, breach notification timelines, and data deletion. UK GDPR applies regardless of where the development partner is based — the UK controller remains responsible for ensuring compliance.
What is a reasonable payment structure for a custom software development contract?
Milestone-based payment is the most client-protective model: a deposit on signing, staged payments on milestone acceptance, and a final payment on go-live. Payment should be tied to accepted deliverables, not dates — this gives clients leverage if a milestone fails testing.
How can a UK business protect itself if a software developer misses agreed deadlines?
The contract should define milestone dates as binding and include a notice and cure period for delays (typically 14–30 days). If the developer fails to remedy within that window, the client should have the right to terminate and recover fees paid for unaccepted milestones.
Can a custom software development agreement be terminated early, and what happens to the code?
Yes — either party can typically terminate with written notice per the contract terms. On termination, the developer must deliver all work product (completed and in-progress), delete or return confidential data, and transfer IP to the client on receipt of any outstanding payment.
