Software Development Agreements: 5 Key Areas to Consider

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.

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.  

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.