Software Development Agreements

What is a Software Development Agreement?

Software development agreements are put in place to deal with the commercial relationship where one entity provides software (which is often bespoke) to a customer. As these developments become more bespoke and technical in their nature so do the legal issues surrounding these agreements.

Agreements are often entered into at the outset when the relationship begins but needs to take into account changes along the way as technical specifications change, making the software development agreement one of the most critical agreements seen in this area of commercial enterprise.   

Key Provisions in a Software Development Agreement

Essentially the software development agreement manages the entire relationship from concept through to after installation services such as warranties and staff training. The first issue that needs to be considered is the type of service that is being offered. For example whether bespoke software is being developed or whether these are actually off the shelf items that are being sold onwards.

Typical clauses deal with the scoping process which is identifying the exact needs of the client, testing that needs to be done both before installation and post installation as well as the way in which changes can be dealt with as the project progresses.

Scoping and Revising Estimates

One of the most substantial areas of drafting that need to be undertaken in any software development arrangement is dealing with the initial estimate and how this should be amended once the full scoping has been undertaken. When the document is formed originally it is unlikely that the full details of the project will be understood. Further scoping will be necessary to develop the full technical specification. With this in mind a clause is needed to deal with the situation that the scoping work requires the estimate to be revised. This will normally allow the supplier to alter the estimate if they feel more work will be necessary but there should also be a get out clause allowing the customer to terminate the contract or to reduce the scope if they cannot meet the added financial burden. Consideration needs to be given as to whether or not the customer should pay a termination fee if they decide to terminate at this point, whilst this may offer some security to the supplier that they will not lose time but will result in the customer owning all documentation produced at this point leaving them free to take the work elsewhere.

Testing and Acceptance Processes

All software regardless of how bespoke it is will need to be tested at various different stages in the process to ensure that it meets with the business requirements of the customer. In most cases this will involve ensuring that the individual components of the software package work prior to installation as well as further testing when it has been installed so that it can be signed off as working in line with the expectations of the customer. One possible way of achieving this is to establish a set of acceptance criteria for the software at the outset and these criterions have to be met before the software is deemed to be accepted.

Provisions should be included dealing with the situation whereby the software fails at any of these stages including the decision as to whether a termination fee should be charged.

Other Points for the Agreement

Payment Schedules  

In many cases the process of establishing a fully working software package can take months if not years, there may be several stages all of which are likely to have a testing or acceptance process attached. With this in mind it is common practise to have a schedule as part of the agreement which lies out the payments that are due and at which point in the process. This assists with cash flow for the supplier whilst also offering protection to the customer in terms of accepting every stage of the project before making payments.

Staff Training

A common yet non essential element of the agreement is seen with the training and staff familiarisation of the new software. This can either be provided as a distinct service or can be provided as a way of integration as part of the acceptance process. Where it is being offered as a distinct service this should be carefully delineated in the schedule and any limitations to this training in terms of timing or extent. Where this is likely it is wise to include a charging procedure so that additional charges can be levied for further training if required.

Other Commercial Considerations:

  • Consider the way in which the software will ultimately work and the likely documentation that will need to pass
  • Issues such as the specification requirements should be contained in the schedule so that they can be bespoke for every customer
  • Make sure that the customer has the right to use any third party software that is being used for example any open source software
  • Deal with issues of intellectual property and how it passes, pay particular consideration to how it passes in the event of default from either party