How-to guide: What to consider when reviewing or drafting a software development agreement – B2B (UK)

Introduction

This guide outlines the key considerations when reviewing a business-to-business software development agreement. It is designed to provide practical insights from both the developer’s and the customer’s perspectives. It covers key terms including project scope, allocation of responsibilities, management of testing and acceptance procedures, intellectual property rights and change control mechanisms. The guide is useful both for in-house counsel and private practitioners, whether drafting bespoke agreements or when reviewing an agreement provided by the other party.

This guide covers:

1. Comparing software licensing and software development
2. Key considerations in a software development agreement
3. Boilerplate terms

This guide can be used in conjunction with the following How-to guides: How to negotiate and draft governing law jurisdiction clauses in a commercial agreement and Checklists: What to consider when reviewing terms and conditions for the purchase of goods and services (buyer’s perspective) – B2B, Ensuring a contract is valid and What to consider when terminating a contract.

Section 1 – Comparing software licensing and software development

This section explores the distinction between software licensing and software development. It examines why a customer might choose a third party to develop bespoke software on its behalf rather than simply entering into a licensing agreement for existing software.

1.1 Software licensing

Customers often obtain software through licensing arrangements with suppliers. In such cases, the software has already been developed by the supplier, typically as ‘off-the-shelf’ software – software that is provided ‘as is’ and often intended for mass use by multiple customers. A classic example of this would be Microsoft Office. These solutions do not generally include bespoke aspects developed for individual customer needs. Off-the-shelf software may be delivered as on-premise software that is installed directly on the customer’s systems and equipment, or Software as a Service (SaaS) where the software is accessed remotely via the cloud. See Checklist: What to consider when reviewing or drafting a software licence agreement – B2B and Practical considerations when reviewing and negotiating a Software as a Service (SaaS) agreement from the customer’s perspective.

1.2 Software development

While off-the-shelf software can sometimes have bolt-on modules for added functionality, it may not always fully meet customers’ specific requirements. As a result, many customers often engage third-party developers to have software developed for them. An example might be where the customer uses financial accounting software but needs something more bespoke to consider specific trading periods, or financial year-end processes or, in the case of educational institutions, term times. Given the potential cost of outsourcing, particularly for custom builds, customers should research the market thoroughly. This could include comparing developers’ proposals and perhaps inviting all potential developers to submit a request for quotation (RFP) or alternatively exploring whether hiring an in-house developer may be more cost-effective.

From the developer’s perspective, they need to consider whether they can develop the software to meet the customer’s needs. There can be a lot of unknowns when it comes to starting the development work and the customer may change its mind during development as to what it needs from the software. This may be due to various factors, such as internal organisational changes, updates in legal requirements or simply changes based on the results and capabilities following intermittent testing of the software. To manage these unknowns, it is therefore crucial for both parties to clearly detail the scope of the work at the outset and establish a clear process for dealing with any change requests (including clarity on which party will bear any associated costs) – see Section 2.6. There are two types of software development agreement, ‘waterfall’ and ‘agile’ and these are considered below.

1.2.1 Waterfall software development

Traditional software development known as ‘waterfall software development’ follows a structured, sequential process with distinct stages for the development where one stage completes before the next one begins. Typical stages include defining the requirements, initial design, testing, acceptance and implementation. One key advantage of this approach for both developers and customers is its predictability and ease of planning. The final software product is usually delivered at the end of the development cycle. Often the fees are determined upfront making them more fixed in nature.

1.2.2 Agile software development

Agile software development has been recently adopted by organisations seeking greater flexibility particularly when the customer’s requirements are not fully defined at the outset. This approach allows the development process to evolve as the requirements become clearer. Fees are typically based on time and materials or linked to the completion of specific milestones, rather than being fixed upfront. Development and delivery of the software is normally done in increments, enabling the customer to receive usable software throughout the project rather than waiting on a finished product at the end. Flexibility is key and the agreement should sufficiently detail how changes and any associated costs will be agreed. Regular communication is also likely to be important given the constantly evolving nature of agile software development so governance, status reports and dispute escalation will need to be clearly set out in the agreement.

1.2.3 Factors to consider

The choice of software development agreement will depend on several factors. These include the customer’s requirements, the developer’s capabilities, and how much involvement the customer wishes to have in the development process. If the customer prefers to be closely involved and expects requirements to evolve over time, an agile approach may be more suitable. Conversely, if the requirements are well-defined from the outset and minimal customer input is expected during development, a waterfall agreement may be preferred. The availability of resources, particularly personnel on both sides, will also determine which approach is most suitable.

The table below provides a brief comparison between the main features of the two types of software development agreement:

Section 2 – Key considerations in a software development agreement

This section outlines key considerations when a customer engages a third-party developer for software development. Developers often provide their own agreement templates, but these should always be carefully reviewed to ensure that they meet the customer’s specific needs. If the customer supplies the agreement template, they should consider whether the developer’s policies and procedures need to be factored into the agreement, particularly if relevant to the development process. A balanced agreement helps to prevent disputes. It is advisable for both parties to carefully consider and negotiate the terms, addressing any practical concerns (from either party) around compliance.

2.1 Scope of work

The scope of work (or statement of work or SOW) is typically separate from the main software development agreement but ideally is referenced or attached. It outlines the planned software development in detail. It should identify the customer’s needs, the developer’s qualifications to meet this need and proposed solutions.

The SOW usually includes assumptions made by each party which will influence proposed fees and timelines (based on those assumptions), with anything falling outside of those assumptions then potentially resulting in increased fees or longer timelines.

The SOW also specifies deliverables (what the developer is expected to provide to the customer, how and in what format), milestones (dates by which those deliverables are to be completed) and a project plan (a schedule setting out a day-by-day or week-by-week breakdown of project timings for the duration of the development cycle).

Although primarily a commercial and technical document, the SOW should be reviewed by the legal team alongside the main software development agreement to ensure there are no conflicting or contradictory terms, particularly regarding payment schedules. Where multiple documents exist, the software development agreement should clarify which takes precedence in the event of any conflict. Typically, the agreement, but on occasion the SOW, may prevail if is it more favourable to that party. An example could be if there is an increased liability cap or enhanced warranties in the SOW; in this case, the party that most benefits from the cap or enhanced warranties will want to ensure that the SOW prevails over the underlying agreement.

2.1.1 Scope creep

Each party needs to be mindful of ‘scope creep’. This is where the scope of work is vague and open-ended, allowing for either party to potentially expand the scope of the project beyond that which was originally intended, but without proper consideration of any financial or other impact on the other party, and without discussion/approval with the other party. This can lead to delays, budgets being exceeded and lack of adequate resourcing to deal with the unplanned expansion of the scope.

Practical tips for avoiding the risk of scope creep include:

• careful consideration of the scope of work (and clearly defined wording within the agreement);
• a well thought through and documented governance process – day-to-day contacts, escalation contacts, regular progress meetings, check-ins and reports; and
• a clear and reasonable change management process so that both sides are clear as to what needs to be formally approved (major changes perhaps or those that affect any milestones or budgets), and those that can be more informally agreed (minor changes that do not impact any deadlines or fees).

2.2 Roles and responsibilities

While the developer’s role to develop the software, and the customer’s role in funding and benefiting from it may seem obvious, it is recommended to expressly detail each party’s roles and responsibilities in the agreement to avoid confusion (especially where roles may overlap).

Appointing project leads and possibly a steering committee to meet regularly can help manage progress of the development work. This can also be useful to ensure there is no blurring of lines in each party’s role and responsibility under the agreement. For agile software development, regular contact and updates between the parties is essential due to its fluid nature – see Section 1.2.2.

To reinforce the importance of each party fulfilling their obligations, the agreement may include provisions addressing situations where a party’s failure to perform their tasks could adversely impact the development work. These provisions could include making a breach of a relevant obligation a material breach (allowing the other party the option to terminate) or expressing the obligations as warranties or subject indemnities. See Section 3.3.

2.3 Testing and acceptance

2.3.1 Testing

Software development will usually involve testing, by both the developer and the customer, with the latter conducting ‘user acceptance testing’ (UAT). The agreement should clearly define the testing process, including responsibilities, scope and conditions.

Testing usually begins in a non-production environment (meaning it is not live or available to other parties) using test data, progressing to live testing with real data once initial tests are passed. Live testing carries greater risk, so introducing safeguards to limit exposures to real clients is important. This could involve limiting live testing to a small number of named clients who have expressly consented to participate. It is essential to ensure 24/7 support from the developer during any initial live testing (if appropriate to the customer’s business). It is also crucial to consider any data protection issues that may arise from the use of live data, whether during testing or after acceptance of the software. See Section 3.2.2.

2.3.2 Acceptance

The agreement should set out the criteria by which the testing is deemed to meet the customer’s requirements or specification. It should also outline a clear process for how and when subsequent acceptance of the software will be completed.

The developer will often want to specify that the software is deemed accepted based on whichever of the following events happens first – acceptance, delivery to the customer or use by the customer in a production environment. This is because a large portion of the development fee payable by the customer is often linked to acceptance and the developer will not want to risk delay in payment simply because of a lack of express notification from the customer. The customer will usually want to provide express acceptance of the software in writing rather than the developer relying on deemed acceptance such as on delivery of the software.

For both parties, it is important that each party is clear as to the point of acceptance of the software, not just in respect of payments but also because the date of acceptance will often trigger the start of warranty periods, support and maintenance periods, etc. Following acceptance, the customer generally has no ability to seek a refund of any fees paid for the software so it is important that thorough testing has been completed for the customer prior to communicating any acceptance.

2.4 Fees and payment terms

2.4.1 Different fee types for software development

The table below provides a summary of the different fee types typically involved in software development, together with points to consider when drafting or reviewing the related clauses in the agreement itself:

2.4.2 Expenses

The agreement should clarify whether the fees are inclusive of all the developer’s costs (such as resources, travel, etc) or, if not, set out what is excluded and ideally, for the customer’s benefit, include a rate card to show the additional costs it may need to pay. For example, if the expertise of one of the developer’s consultants is needed to try and solve a customer requirement, is an hourly or daily rate applicable and the customer may want to negotiate a cap to control costs.

The customer should also seek documentary evidence of any additional costs incurred by the developer, such as receipts or time sheets. Ideally, the customer will want any additional costs to be approved by it in advance, but this is not always practical. Ideally the developer should be required to notify the customer of the additional costs as soon as possible to enable the customer to manage its costs.

2.4.3 Payment terms

Software development projects involve multiple milestones, and it is standard practice for the developer’s fees to be paid in phases rather than one upfront payment. This enables the customer to budget accordingly over its financial year.

For waterfall software development, the payment schedule might include:

• 10 -25 per cent of the total fee payable upfront as a deposit;
• 25 per cent payable on commencement of the development;
• 25 per cent payable upon delivery of the software; and
• final balance payable following successful testing and acceptance of the software by the customer.

The initial upfront payment may be payable by way of a non-refundable deposit to enable the developer to commit to paying for any of its own upfront costs, such as the cost of recruiting any personnel, equipment or materials that it needs to start the work, but without running the financial risk if the customer decides not to proceed. If acting for the customer, it is advisable to withhold a certain amount from the total fee payable until the software has been tested and accepted by the customer. This provides the developer with the incentive to complete the work within the timeframe as planned and not to delay in completion.

Payment of fees for agile software development is slightly different, as set out at Section 1.2.2, and is not normally based on set amounts.

2.5 Intellectual property rights

2.5.1 Consideration of ownership options

The software development agreement must clearly specify who owns the IP rights in and to the developed software and related materials, such as user guides. The following table sets out some of the different options and related issues to be considered regarding ownership:

2.5.2 Background IP rights

In addition to any new rights being created as a result of the software development, there will usually be underlying rights that each party has in material, documents or other information (‘background IP’) that is utilised in the development of the software or incorporated in the new software, such as the use of pre-existing code written by the developer, or text and images supplied by the customer for incorporation in the software. Each party will want to ensure it retains all ownership in and to such rights. The agreement should clearly define what each party’s background IP is and, to the extent the other party needs a licence to use the other party’s background IP, the scope and extent of any licence (in terms of purpose, term, territory, and whether the licence is sub-licensable).

2.6 Change control process

The evolving nature of software development means that a degree of flexibility is likely to be required on both sides, especially in agile software development projects.

The agreement should include a clear change control mechanism that details who can submit a change request, how the request should be submitted, and how the request is then processed and managed between the parties. For example, will certain (perhaps minor) changes be automatically accepted and agreed if they do not have any impact on the costs/timelines, or will all changes have to go through a formal approval process?

If the parties cannot agree on a change, the agreement should address the next steps such as termination rights, fee implications, and the customer’s ability to use or transfer the partially developed software.

2.7 Term and termination

2.7.1 Term

The term of a software development agreement will usually be tied to how long the development work will take, so it is important to specify the start date and the expected duration of the work. It is sensible to build in a degree of flexibility in case of delays and to address any last-minute issues. This will normally be subject to any change control process so that any extension must be mutually agreed and not unilaterally imposed by one party – see Section 2.6. It should also cover any pre-development work to be done, such as meetings to discuss scope, resource recruitment, etc. Additionally, the parties should avoid sharing sensitive or confidential information with each other before the agreement takes effect to prevent risk of misuse of disclosure. If it is necessary for the parties to share confidential information before the agreement takes effect, they should enter a separate non-disclosure agreement covering this period. See How-to guide: How to draft a confidentiality agreement and Checklist: What to consider when reviewing a confidentiality agreement.

2.7.2 Termination

Whether the software development agreement is waterfall or agile, the parties should consider what termination rights may be appropriate. This could include a right for the customer to be able to terminate the agreement if the developed software is found to infringe a third party’s rights and the developer is unable to either amend or replace the software.

Careful thought needs to be given as to what happens if the agreement is terminated early, as it could leave one or both parties out of pocket or (in the customer’s case) with only a partly developed solution or none at all.

Software development agreements often include a specific right for the developer to terminate if the customer does not pay or is late in paying fees. While helpful to the developer, it is unlikely to be its preferred course of action (unless the customer has been repeatedly late in making payment). This is because the developer will normally want to be able to see the development through to completion, both in terms of reputation, as well as continuing to develop and broaden its skills and expertise.

Customers are likely to resist the inclusion of a termination clause for non- or late payment and will likely seek to build in protections around this, including payment reminder notices or allowing time for good faith discussions (particularly where the delays are due to valid concerns or cashflow issues). To protect the developer, the agreement may also include a late payment interest clause.

If the agreement is silent, the Late Payment of Commercial Debts (Interest) Act 1998 (LPCDA) allows the developer to charge the customer late payment interest at 8 per cent above base rate. This works in the developer’s favour, so the customer is likely to want to make express provision in the contract to vary the statutory position so that the interest rate is lower. A common percentage rate to use is 2–4 per cent above base rate.

2.8 Other considerations

2.8.1 Third-parties

Third-party software

The developer should make it clear whether:

1. any third-party software is either included in the developed software; and/or
2. if third party software needs to be licensed by the customer from the third party so that the customer can use the developed software.

In the case of scenario (a), the developer will need to be able to provide assurance to the customer that it has the appropriate licences from the third party and inform the customer of usage rights, including for commercial use or sub-licensing to third parties (where applicable). This could be expressed in the form of a warranty or an indemnity.

If any third-party software is subject to licence terms that apply to the customer, the developer should notify the customer as soon as possible. This allows the customer to consider whether the terms are compatible with existing policies and processes.

In the case of scenario (b), if the customer is obliged to obtain third-party software to use the developed software, this should be identified early in the development process. This allows the customer to factor any additional licensing costs into its overall project budget.

Third-party subcontractors

If either party will need to use third parties for the development work, this should be made clear in the agreement. For example, the developer may need to use third-party software coders, and the customer may need to involve its external IT support in the testing and implementation of the software. Whichever party is using third parties, that party should be required to ensure compliance by that third party with all applicable terms of the agreement, in particular, any confidentiality and data protection obligations, and ensure the transfer of any IP rights in or to code or other materials produced by the third party to the developer or the customer. The party engaging the third party should also be expressed to be directly liable for any act or omission of that third party (as the other party will not usually have any direct contractual relationship with that third party).

2.8.2 Artificial Intelligence

Increasingly, companies are incorporating artificial intelligence (‘AI’) into their software development processes. While this can accelerate development and potentially reduce costs (both for the developer and for the customer), it also raises important questions, particularly around the ownership of intellectual property rights in software created with the assistance of AI.

To address these concerns, the customer should proactively confirm with the developer whether AI has been, or will be, used in the development of the software. This should be clearly documented in the software development agreement, with specific provisions addressing the use of AI. These may include:

• a representation that AI has not been used in the development of the software,
• a commitment that AI will not be used without the customer’s consent,
• a restriction that AI may only be used for clearly defined and agreed-upon aspects of the software development process.

Where AI is to be used, the customer should seek robust indemnities from the developer to protect against any third-party claims alleging infringement of intellectual property rights arising from the use of AI. Additionally, the agreement should confirm that all output generated through use of the software, including any AI-assisted elements, are owned exclusively by the customer.

2.8.3 Press and publicity

As software development is normally such a significant step (both for the developer and the customer), the parties will often want to be able to publicise the work that has been completed, to be able to attract new customers/clients, to be first to market, etc. This can sometimes be done in the form of a jointly made statement which the parties produce in collaboration. However, sometimes one of the parties will want to make its own statement and/or announcement on its website. Where the parties are happy for the other to make their own statement, it is still sensible for the parties to mutually agree to any press statement/publicity prior to publication so that they can each be sure the relevant messaging is accurate, and relevant and appropriate to their respective organisation’s aims and objectives. Additionally, any brand guidelines of the relevant parties will need to be considered, such as how a party’s trademark, name or logo should appear and if any copyright notices need to be included.

From the developer’s perspective, it will normally be keen for the customer to provide a testimonial about the performance of the software and the developer’s work in developing the software. This can often be of more value to the developer than payment of fees as it means the possibility of attracting more customers. The developer may often allow the customer a discount on fees and/or lower priced ongoing licences and/or a certain number of free or discounted consulting hours in return for the customer testimonial.

The customer will want to be clear on how and where the testimonial may be used by the developer (eg, can it be publicised widely on the developer’s website, or is it something that may only be shared with other parties subject to confidentiality obligations). This may often be the case where the customer is in a particularly competitive market and does not wish to advertise the fact of its engagement of the developer to a wide audience.

Section 3 – Boilerplate terms

The following sections sets out some of the key boilerplate terms that the parties may wish to consider including in the software development agreement. See also boilerplate provisions in the following Checklist: What to consider when reviewing or drafting a software licence agreement – B2B (UK).

3.1 Dispute resolution

Due to the constant evolving nature of software development, establishing a dispute resolution process can be extremely useful for both parties. Termination or court action is likely to be the last resort that either party will want to pursue. It is likely the parties will first want to have sensible good faith discussions to resolve any problems and consider how to remedy them.

Typically, an internal dispute escalation process may be included in the agreement. This enables tiers of escalation and the recommended personnel:

• first escalation to the project managers on each side;
• second escalation to more senior managers; and
• final escalation to the board/COO/CEO of each company.

The process may or may not also allow other remedies to be pursued at the same time, such as the commencement of court proceedings, or notice of intent to terminate provided, to keep up momentum to resolve the matter.

It can also be helpful to include an alternative dispute resolution process, such as mediation. This could allow for specific personnel who have technical expertise in the relevant software/customer’s industry, to be able to assist in resolving the matter without it necessarily resulting in the contract being terminated, or court action progressing.

3.2 Confidentiality, Data Protection and Security

3.2.1 Confidentiality

During the development cycle, both parties are likely to share sensitive and confidential information with each other. The agreement should include mutual confidentiality provisions that clearly define how the information can be used, whether it can be shared with third parties (eg, subcontractors) and the duration of confidentiality obligations. For highly sensitive information such as a software code, a longer or indefinite confidentiality period may be appropriate. In addition, the customer will want to ensure that its confidential information is not used by the developer in work for other clients/competitors and appropriate restrictions should be included.

3.2.2 Data protection

If software development involves processing personal data, both parties must comply with data protection laws. During testing, it is advisable to use test or anonymous data rather than actual personal data to avoid the risk of data breaches (see Section 2.3.1). Where personal data forms a significant part of the software, the agreement could set out a data processing schedule to detail each party’s obligations concerning data breach notifications and data handling processes. See How-to guide: How to comply with data processing principles under the GDPR and Checklist: Processor due diligence (data protection and cybersecurity).

3.2.3 Security

Software is potentially vulnerable to attacks by third parties. Appropriate security measures should be put in place to protect against such attacks and clear escalation and remediation plans are essential. Beyond contractual considerations, both parties should assess each other’s cybersecurity operations and processes and consider conducting a cybersecurity risk assessment prior to any access being granted to the other party to any systems, equipment or facilities.

3.3 Warranties and liability

3.3.1 Warranties

Standard warranties are relevant for a software development agreement, such as a warranty from each party that they have the authority to enter into the agreement and all licences or consents necessary to perform their respective obligations. Additional warranties may also include a warranty from the developer that the software is original, that it does not contain any viruses or malware and that its use will not infringe any third party’s IP rights.

Where a specification exists, the developer may warrant that the software will perform in accordance with any specification – often requested by the developer to be limited to performance ‘in all material respects’ and for a defined period (often 90 days). Both parties will need to assess what time limit is appropriate.

Where any time limit is specified for any of the warranties, both parties should consider whether the specified time limit is sufficient for their needs. For example, if the developer’s warranty about performance of the software in accordance with the specification is limited to 90 days, is this enough time for the customer to use the software and for any initial bugs to arise and to have been fixed by the developer? For the developer, it will want to ensure that any warranty period is limited in time so that it is better able to assess its potential risk exposure over a given period, and ensure it has appropriate insurance in place to cover such risks (to the extent the risk is capable of being insured against).

Responsibility for software output should also be addressed, especially where the customer provides input data; the developer may warrant output accuracy but exclude liability for errors in the customer data. Careful consideration needs to be given to ensure an appropriate balance is struck depending on the level of input of each party.

3.3.2 Liability

Liability clauses are often heavily negotiated. Developers seek to exclude or restrict liability, but such exclusions will need to comply with the Unfair Contract Terms Act 1977 (UCTA). Customers are likely to want any liability of the developer to be uncapped and not subject to any exclusions.

Indirect or consequential losses such as costs incurred from switching developers are commonly excluded. For example, if the developer is unable to complete the development work and the customer has to go elsewhere to have the work completed, the customer may want to seek compensation from the developer for the additional costs it has incurred. This is potentially an indirect loss which is often excluded from the liability of the developer. The extent to which it is reasonable for the customer to seek such liability from the developer will depend on several factors, such as the bargaining power of each party, the ability of the customer to be able to go elsewhere to have the work completed and any mitigating steps that either party could take to minimise the risk. Both parties should ensure the liability clause reflects a fair allocation of risk, aligns with internal policies and is supported by insurance (particularly for data protection breaches where the risks of potential fines are extremely high).

Additional resources

Supply of Goods and Services Act 1982 (SGSA) (where goods and services or just services are being provided)
Sale of Goods Act 1979 (SGA) (where only goods are being provided)
Unfair Contract Terms Act 1977 (UCTA) (business-to-business)
Late Payment of Commercial Debts (Interest) Act 1998 (LPCDA)
Transfer of Undertakings (Protection of Employment) Regulations 2006 (TUPE)
Contracts (Rights of Third Parties) Act 1999 (C(RTP)A)
Modern Slavery Act 2015 (MSA)
Bribery Act 2010 (BA)
Corporate Insolvency and Governance Act 2020 (CIGA)
Data Protection Act 2018 (DPA)
Data (Use and Access) Act 2025
UK General Data Protection Regulation 2016 (UK GDPR)

Related Lexology Pro content

How-to guides:

How to draft a business continuity plan
How to draft a confidentiality agreement
How to identify and assess bribery and corruption risk
How to negotiate and draft governing law and jurisdiction clauses in a commercial agreement

Checklists:

Lawful processing of personal data under the GDPR
UK Modern Slavery Act reporting requirements: Section 54
Supplier contracts and unforeseen events
What to consider when reviewing a confidentiality agreement
Anti-bribery and corruption risk assessment
What to consider when reviewing terms and conditions for the purchase of goods and services (buyer’s perspective) – B2B
What to consider when terminating a contract
Ensuring a contract is valid

Quickview:

Force majeure

Reliance on information posted:

While we use reasonable endeavours to provide up to date and relevant materials, the materials posted on our site are not intended to amount to advice on which reliance should be placed. They may not reflect recent changes in the law and are not intended to constitute a definitive or complete statement of the law. You may use them to stay up to date with legal developments but you should not use them for transactions or legal advice and you should carry out your own research. We therefore disclaim all liability and responsibility arising from any reliance placed on such materials by any visitor to our site, or by anyone who may be informed of any of its contents.