The Practical Guide to Software Development Contracts (UK)

Why software contracts deserve a closer look

Commissioning bespoke software is one of the largest technology investments most organisations make. The agreement that underpins it sets the rules for scope, money, ownership, risk, and exit. Yet many clients encounter these contracts for the first time during procurement itself, with little context for what the terms mean in practice or why certain provisions exist.

This guide draws on real experience of negotiating software development contracts. It walks through ten areas in the order they tend to matter, explains each in plain English, and sets out what to look for so both parties start the engagement on solid ground. Where a topic justifies a deeper treatment, there is a dedicated guide linked from the relevant section.

1. Capped investment, flexible scope

One of the most common misconceptions in bespoke development is that a fixed price means a fixed scope. In practice the two work very differently.

A capped investment model (sometimes called a Build Cap) sets a maximum price for the build phase. Within that cap, scope is flexible. Features are estimated during discovery and given individual budgets, but as detailed requirements are elaborated some features cost more than estimated and some cost less. The cap stays the same; the scope adjusts to fit.

This is not a reduction in what the client receives. It puts the client in control of priorities. If a high-value feature needs more effort than estimated, the client can defer a lower-priority item and redirect that budget. A programme contingency (typically around 20%) sits inside the cap to absorb natural variance, and unused budget is released as each feature completes rather than held back to the end. Deferrals and underspend are managed at regular Steering Committee meetings.

In a traditional fixed-price, fixed-scope contract, any change triggers a commercial negotiation, which creates friction and often means the client pays more or accepts a product that does not reflect what they need. The capped model removes that friction.

For a detailed treatment, including how feature budgets, contingency, deferrals, and underspend work in practice, see the deep-dive guide: capped investment versus fixed price.

What to look for: a clearly defined Build Cap as the maximum financial commitment; feature budgets with contingency included within the cap, not on top; a mechanism for deferrals and underspend agreed at Steering Committee; regular reporting on budget and contingency; and confirmation that scope adjustment within the cap does not trigger change control.

2. IP licensing and source code access

The key IP question is not usually whether the client owns the IP, but what rights the client has to use, modify, and maintain the software after delivery.

Most bespoke contracts use a licensing model rather than outright assignment. Under a licence, the development partner retains ownership but grants the client a broad, perpetual right to use, copy, modify, and maintain the software, including the right to engage third-party developers. A well-drafted licence gives the client everything they need to run and evolve the platform independently. Assignment is less common because it complicates pre-existing components, open-source libraries, and shared frameworks.

Source code handover is typically tied to payment. During the build the partner stores the code in their own repository; once all payments are made in full, including any IP licence fee, a complete copy is handed to the client in repositories of their choosing. This protects both parties: the code is the partner’s security during the payment period, and the client is guaranteed to receive it.

For licensing models, the SBOM, and how handover and hosting work, see the deep-dive guide: IP licensing and source code handover. For the related question of what you can legally replicate when replacing an existing product, see our guide on what you can and cannot legally copy when replacing SaaS.

What to look for: a perpetual, irrevocable licence to use, copy, modify, and maintain; the right to sublicense to third-party contractors; a clear trigger for full source code handover (typically payment in full); a software bill of materials (SBOM) listing third-party and open-source components; and no restrictions on how the client hosts the code after handover.

3. Liability caps and indemnities

Liability provisions determine how much financial risk each party carries if something goes wrong, and they are among the most heavily negotiated clauses in any software contract.

A liability cap sets a ceiling on the total one party can claim from the other, usually expressed as a multiple of the contract value or charges paid in a period. Caps exist because the consequences of a software failure (lost revenue, reputational damage, regulatory fines) can far exceed the value of the contract. An indemnity is a promise to compensate the other party for specific types of loss, most commonly IP infringement and data breaches. Indemnities can sit inside or outside the cap, and an uncapped indemnity is a significant risk allocation. Most contracts also exclude certain losses (loss of profits, anticipated savings, indirect or consequential losses), and where the line falls on reputational damage deserves particular attention.

For how caps are sized, the treatment of indemnities, excluded losses, and the carve-outs that cannot legally be limited, see the deep-dive guide: liability caps and indemnities.

What to look for: a cap proportionate to the contract value; clarity on whether indemnities sit inside or outside the cap; a list of excluded losses both parties accept; carve-outs for things that cannot legally be limited (fraud, personal injury); and mutual liability provisions, not just obligations on the development partner.

4. Acceptance testing and UAT

User Acceptance Testing (UAT) is how the client confirms the software meets the agreed specification, and how it is handled contractually matters to both parties.

UAT is primarily the client’s responsibility: the client tests against the agreed requirements and either accepts the software or provides written feedback on where it does not conform. The development partner supports this by triaging defects, diagnosing issues, and delivering fixes. One of the most important distinctions is whether the partner’s obligation to fix defects is qualified by “reasonable endeavours” or is absolute. Reasonable endeavours is usually appropriate, because some defects depend on third parties (a payment provider, a CMS, a hosting service) and an absolute obligation with a fixed deadline could put the partner in breach for something outside their control.

For acceptance and rejection criteria, remediation timeframes, third-party exclusions, and escalation that includes dispute resolution before termination, see the deep-dive guide: acceptance testing and UAT clauses.

What to look for: a clear definition of acceptance and rejection; reasonable timeframes for both client review and partner remediation; reasonable endeavours on remediation rather than an absolute obligation; exclusions for defects caused by third parties or client-provided data; an escalation mechanism with a dispute resolution step before termination; and confirmation that UAT relates to conformance with the agreed specification, not subjective quality.

5. What is the Initiation exit right?

Many bespoke contracts include a break clause at the end of an Initiation phase, giving both parties a structured checkpoint before the main build commitment begins.

During Initiation, the development partner elaborates requirements, produces detailed estimates, and refines the delivery plan. At the end of the phase the partner presents the findings. If the estimates have changed significantly from discovery (a “Material Variance”), the client can walk away, pay only for the Initiation work, and keep a licence to use the Initiation outputs. The client therefore does not commit to the full build until they have seen detailed numbers.

The definition of Material Variance is one of the most important details. A common approach ties it to a percentage change in the Build Cap (for example, more than 10%). In a capped investment, flexible scope contract, the trigger should focus on situations where the overall investment or a major capability area is materially affected, not routine reprioritisation within feature areas. Good contracts also address what happens if there is a Material Variance but the client wants to continue: the parties agree a corresponding adjustment to the Build Cap and the project proceeds.

What to look for: a clearly defined Initiation phase with a structured review at the end; a Material Variance threshold that is specific and measurable; a clean exit (pay for Initiation, receive the outputs, no further obligations); a continuation mechanism if the client proceeds despite a Material Variance; and confirmation that routine scope adjustment within the Build Cap does not trigger the exit right.

6. When should support terms be agreed?

Ongoing support is essential for any bespoke platform, but how and when support terms are agreed can significantly affect both the negotiation timeline and the commercial relationship.

There is often pressure to include support terms in the main build contract, but support scope depends on how the platform is built, hosted, and operated, all of which are refined during the build. A more practical approach is to agree the build contract first and negotiate a separate Support Statement of Work (SOW) ahead of the support commencement date. Most structures accommodate this through a Master Services Agreement that allows multiple SOWs over time.

A well-scoped Support SOW typically covers a monthly ticket allowance, an annual maintenance allocation for proactive work such as security patches and dependency updates, response and resolution targets by severity, standard support hours and any out-of-hours provision, and day rates for work outside the included allowance. Where source code handover is tied to payment, there is a practical point: during the payment period the client does not have the source code and cannot engage a third-party support provider, so the minimum support period should align to the payment period rather than an arbitrary fixed term. For the build-versus-buy view of ongoing support, see our guide on managed support versus hiring.

What to look for: flexibility to agree support terms separately from the build; a clear trigger for when support commences (typically after hypercare); a ticket allowance, maintenance allocation, and day rates in the SOW; response and resolution targets by severity with reasonable caveats; a minimum support period that reflects the payment and handover timeline; and an annual price review mechanism.

7. How should data migration be handled?

Data migration is one of the highest-risk areas of any platform replacement. Moving data from a legacy system involves mapping, transformation, validation, and loading, all of which depend on the quality and structure of the source data.

There is a natural desire to agree migration formats upfront and include them as a contractual annex, but locking the format at the outset creates risk: new functionality agreed during the build may need fields that do not exist in the source data, and previously agreed fields may be removed. A more practical approach is to agree an initial data format as a reference point, with the contract explicitly stating it is subject to change as detailed requirements are elaborated. Both parties should also agree what “successful migration” looks like before migration begins: record count reconciliation, data integrity checks, validation rules for mandatory fields, and a sign-off process for each data set. For the technical delivery side, see our data migration service.

What to look for: an agreed data format that is explicitly subject to change during the build; clear responsibilities for who provides, maps, and loads the data; acceptance criteria for a successful migration; a dependency on the client providing clean, validated data in the agreed format; and recognition that new requirements during the build may change the migration scope.

8. What do AI-assisted delivery clauses mean?

AI is increasingly used as an internal tool in software development, and contracts are beginning to include specific provisions around it. Development partners who use AI tools can often deliver faster and at lower cost, and the pricing may reflect that efficiency. If access to AI tools were disrupted, the partner’s cost base could rise and timelines could be affected, which is what AI clauses address.

A well-drafted AI clause typically addresses two scenarios. The first is a temporary disruption, where the partner takes reasonable steps to mitigate and continues delivery with revised timelines if needed. The second is a fundamental, lasting disruption (sometimes called a “National AI Event”) where continuing without AI tools would make the contract commercially unviable, in which case the clause may allow renegotiation of charges or, as a last resort, termination with notice. From the client’s perspective, the key protection is that the partner cannot use an AI disruption as a pretext for termination if it can still deliver the services at the agreed price. Clients should also expect transparency: AI is a tool, not a replacement for professional judgment, and AI-assisted code should be reviewed, tested, and maintained to the same standards as any other code. See our AI approach for how we use these tools.

What to look for: a clear definition of an AI disruption event; a mitigation period before any termination right is triggered; protection that there is no termination if services can still be delivered at the agreed price; transparency about how AI tools are used; and confirmation that all deliverables meet the same quality standards regardless of how they were produced.

9. What duty of care standard should apply?

Every professional services contract includes a duty of care describing the standard to which the development partner must perform, and the specific wording matters more than most clients realise because it sets the threshold for a breach claim.

The most common standard is “reasonable skill and care”: the partner must perform to the standard a reasonably competent provider of similar services would achieve. It is an objective test measured against what the industry considers acceptable, and it does not require perfection. Some clients push for higher standards such as “the degree of skill and care expected from a leading company in the industry”. That is a significantly higher bar, “leading” implies best-in-class rather than competent, and it is unusual in software contracts because what counts as “leading” is subjective and hard to measure. The higher the standard, the greater the risk of breach claims, which in turn affects the pricing and liability caps the partner is willing to offer.

What to look for: a duty of care based on “reasonable skill and care” (the industry standard); consistency between the duty of care and the liability provisions; avoidance of subjective standards like “leading” or “best in class” unless specifically justified; and confirmation that the duty applies to the services as a whole, not individual outputs.

10. What protects your long-term investment?

Beyond the core commercial terms, several provisions protect the client’s long-term investment. They are often found in different parts of the contract but together they form an important safety net.

A competitor restriction can stop the partner licensing the same bespoke work to a named direct competitor; a well-drafted version names specific competitors and applies only to the bespoke elements, not generic frameworks or reusable components. A change of control clause addresses what happens if either party is acquired, reassuring the client that the partner cannot simply walk away on a change of ownership while reassuring the partner that the platform will not end up with a competitor through acquisition. Exit assistance and documentation provisions cover the end of the relationship: returning client materials, sharing the technical documentation needed to operate the platform, and assisting transition to a new support provider, ideally not contingent on the client requesting them. Finally, most contracts include a non-solicitation clause preventing the client from directly hiring the partner’s team during and for a period (typically 12 months) after the engagement.

What to look for: competitor restrictions that are specific and proportionate (named competitors, bespoke elements only); change of control provisions fair to both parties; mandatory return of client materials and documentation on termination; exit assistance obligations that are not contingent on a separate request; a reasonable non-solicitation period (typically 12 months); and full source code handover on completion of all payments.

Where to go from here

This guide is the overview. Four of the ten areas have dedicated deep-dive guides:

• Capped investment versus fixed price
• IP licensing and source code handover
• Liability caps and indemnities
• Acceptance testing and UAT clauses

We believe transparent, well-structured contracts are the foundation of a successful engagement. If you are navigating a software development contract and would like to discuss any of these topics, book a consultation.

This guide explains how common software development contract terms work in plain English. It is not legal advice. For advice specific to your circumstances, consult a solicitor qualified in technology and commercial contracts. It reflects common UK market practice as at June 2026.