Software Development Agreements: 5 Key Areas to Consider

Carla Murray's profile picture

Carla Murray - Partner

Published
5 minutes reading time

What is a software development agreement? 

A software development agreement is essentially a services agreement whereby one party (the developer) agrees to develop a software application for another party (the customer).

Such agreements serve as a roadmap for both parties to clearly establish their expectations regarding the scope and timeline for the development project, what is to be delivered as part of the project, how deliverables are to be measured (including acceptance testing), the fees payable and payment milestones the delivery and implementation process and who owns the intellectual property rights in the software.

Whilst the design and development processes can vary depending on the nature and complexity of the project, there are a number of key points that should be considered when entering into such contacts, and our Technology Solicitors explore these in more detail below.

Contact Our Technology Lawyers

What is a Software Development Agreement

5 key points to consider for software development agreements

1. What development methodology will be used in the project? 

The two common methods for software development play an important part in how your development contract should be approached. 

  • Waterfall

     This approach is considered to be a traditional software development agreement and generally requires an initial detailed scope and specification for the project, setting out distinct stages, each of which needs to be completed before the next stage can begin. This methodology generally requires the development agreement to contain specific details on the roles of key individuals, deliverables, timelines, acceptance tests, and criteria.  
  • Agile

     As with an agile software development methodology, the development agreement is more flexible and collaborative in nature. Agile software development agreements are considered the more modern approach to software development as they don't generally require an initial detailed scope and specification. There may be initial workshops to identify key requirements for the software and roadmap priorities, but the development plan can remain fluid enabling the parties to amend priorities and functionality to be delivered as the project progresses. This approach relies on the parties collaborating together and holding regular meetings and feedback sessions to ensure the development process progresses and the necessary adjustments and changes can be made throughout the cycle of the project.  

Get In Touch With Myerson Solicitors

5 Key Points to Consider v2

2. Charging Structure

Although the charging structure will largely depend upon the type of agreement being used, there are several charging structures which can be utilised:

  • Fixed Cost

    If the costs for the development are to be fixed, this will generally require a detailed and lengthy scoping document (which includes a timeline) and is, therefore, likely to be suitable where a waterfall agreement is being utilised. The parties should consider how out-of-scope work will be catered for, what process will be followed where additional or out-of-scope work is required, and how any impact such changes may have on the cost will be dealt with. When agreeing on a fixed cost, the parties should be clear on whether it is genuinely a fixed cost to cover the entire build (irrespective of such changes) or whether there needs to be movement on costs and an ability for the developer to increase or amend costs. Customers, however, will want the reassurance that any changes to the fixed cost have strict parameters around them.
  • Time and Materials

    Under this structure, the customer will pay the developer based on the number of hours they have worked on the project, and it is generally used where there is no detailed scoping document. It is, therefore, more suitable where an agile agreement is being utilised. This can cause some uncertainty as to the overall cost of the project, and therefore, having some form of delivery milestones and budgets can help mitigate the risk of spiralling costs. As with out-of-scope work on a fixed-cost project, the customer should ensure that it has some method of controlling and agreeing on any changes to the estimated number of hours and timescales.

As with any project, parties should expect the unexpected, and we would always recommend development contracts have a clear and agreed process for change control, which allows the parties to agree on changes and consider and agree on what other impact such changes may have on the contract, including the fees, time scales and deliverables.  

Speak With Our IT Lawyers

2. Charging Structure

3. Acceptance Testing

Provisions should be included within the agreement, which clearly defines:

  • What is to be tested? Will individual elements or modules be tested, and will further developments necessitate repeat acceptance testing? 
  • Who will undertake the tests and how? Will the developer, the customer or both parties test the deliverable?  How will the deliverable be tested, and who will be present during testing?  Will the customer need access to a test environment, or do the tests need to be carried out in a live environment or on live data?  
  • What happens if the tests fail and acceptance is not achieved? You should consider what will happen if acceptance cannot be achieved.  The consequences of failing to pass the acceptance tests will need to be considered at the outset, including:  
    • Will repeat acceptance tests be undertaken, and at what cost?  
    • How many opportunities and how long will the developer have to rectify the issues?  
    • Will there be any tolerances which, if the software operates within, will still be deemed to have passed the acceptance test? 
    • Will any development fees be refunded, and in what circumstances?  
    • Are there any circumstances where the customer will be deemed to have accepted the software and the acceptance tests will be deemed to have been satisfactorily completed? 
  • Having a well-thought-out and robust acceptance process can avoid a headache later down the line.

Contact Our Technology Experts

3. Acceptance Testing

4. Intellectual Property Rights

The agreement should clearly cater for intellectual property rights within the software.  

  • Ownership of IP 

    The parties should agree at the outset which party is to own the intellectual property rights being developed. Customers often believe that as they are paying for the development of the software, they will own the intellectual property rights within the software. This is not the case where you are engaging with an independent software developer, as unless the agreement states otherwise, the rights in the software will vest in the developer. They have to be formally assigned to the customer for the customer to take ownership of the same.  
  • Pre-existing software 

    Will any pre-existing coding be used as part of the development? A developer may utilise its pre-existing code as part of the agreed cost and budget for the project (to mitigate the increased costs associated with developing new code for only one customer). Where the developer is utilising pre-existing code that forms part of other software products licenced to its other customers or the developer intends to use the code to be developed with other customers, and as part of its business more generally, they develop would not in such circumstances assign the intellectual property rights in such code to the customer as its will need to own these rights in order to continue licencing them to its customers and use the same within its business. Therefore, the most the customer may get is a licence to use the same for the particular purpose that software is being developed for and possibly a period of exclusivity to use the same.
  • Third-Party and Open Source Software

    The parties should also be clear on whether any third-party software, including open-source software (or coding), can be used as part of the development. If the development involves utilising third-party or open-source software, then the parameters and licensing terms for such software must be considered by both the developer and the customer. Customers should note that some open source software licence terms require any software that the open source is integrated with to also be open source. The parties should ensure that the licence terms attached to such third-party or open-source software allow the developed software to be used and licenced in the manner that the customer intends to use and license its product.   

4. Intellectual Property Rights

Get In Touch With Myerson Today

5. Confidentiality

Maintaining the confidentiality of the information provided to the developer as part of the development process and the confidential information in the software, designs, functionality, and any trade secrets or sensitive information, etc. will be paramount for the customer.

The agreement should, therefore, stipulate what information is considered to be confidential information, the obligations of confidentiality and what remedies will be available to the customer for any breach of confidentiality by the developer.

Equally, if the developer is to be sharing its confidential information, then it will require mutual confidentiality obligations to be provided by the customer. 

6. Other Areas

Other areas to consider are the parties' termination rights, the consequences of termination, liability and any limitations on the same, data protection (if the developer will be processing personal data of the customer, its employees, or clients), and dispute resolution.

Whilst this article only touches on some of the key areas to consider, a well-drafted and legally enforceable agreement is more likely to provide an adequate level of protection for both parties and ultimately lead to a successful software development project.

Speak With Our Technology Solicitors

5. Confidentiality

Contact Our Technology Solicitors

Myerson's Technology Solicitors have extensive experience of advising on, drafting and negotiating software development agreements and can assist you by advising on the key areas throughout the development process whether you are in the business of developing bespoke software solutionsor looking to instruct a software house to develop a new software solution within your business.

If you have any questions or would like more information regarding software development agreements, please contact our Technology Solicitors, who will be happy to assist you.

01619414000

Carla Murray's profile picture

Carla Murray

Partner

Carla has over 18 years of experience acting as a Commercial solicitor. Carla is the Head of Myerson’s Technology Sector. She has handled various matters relating to commercial agreements, technology contracts, and data protection.

About Carla Murray >