A contractor's software development agreement – the finer points

Having explored the broad aims of drawing up a software development agreement as a contractor, it is now fitting to take a closer look at the issues within, writes Sue Mann, commercial solicitor for Cousins Business Law.

Previously, I identified eight main issues that should be covered in a SDA. The following are the finer points that contract developers should consider in relation to those eight issues, as well as a few more for good measure.

Doubters of the importance of a SDA should remember that there is plenty of scope for misunderstanding between you, the contractor, and the client, as to what you (as the developer) are undertaking to provide and what the client thinks the development will achieve for its business.

As stated before, it really is worth making sure that you have a software development agreement in place to protect you, BEFORE you start on the development.

1. Specification – you will have discussed the business requirements that the client wants the software to meet, but the contract should clearly identify the technical specification that the software development is to achieve. By defining your responsibilities as software developer in a more objective way, the technical specification can play an important role in reducing potential areas for dispute and managing the client’s expectations.

2. Project plan –realistic timescales and deadlines for the software development project should be set out in the SDA. Any plan for implementing the project discussed during the proposal process should be carefully reviewed before being used for the legal contract.

3.  Client’s responsibilities – any matters for which the client is responsible should be set out, as your ability to perform your responsibilities as developer may be dependent on the client fulfilling certain tasks.

4.  Change control procedure – changes which happen during the course of the development need to be managed and documented to avoid costs and deadlines being exceeded. For this you should include a suitable change control procedure.

5.  Acceptance of the developed software – include a procedure for confirming that the development of the software is complete – typically achieved in conjunction with acceptance testing.

6. Pricing and payment – the basis of the charge for the software development - usually time and materials, fixed price or some combination of these methods. Timing of payments should be set out in the SDA too.

7. Warranties – assurances sought by the client as to the performance of the completed software will need to be carefully framed so as to satisfy the client sufficiently whilst being appropriate and not unduly risky for you as developer.

8. Limitation of liability - you as developer of the software will want to limit your liability so far as possible, but this will need to be balanced against what is acceptable to the client and what it is reasonable and permissible, legally.

9. Rights in the software – the client will need sufficient rights to be able to use the developed software as agreed, but you as developer also need to protect the rights you need to retain in your business for any ongoing services and future projects. If licences for any third party modules are needed that should also be specified.

10. Other services – consider whether the client may benefit from any additional services in relation to the software once developed, such as training, updating, maintenance, support etc. Specify if these are included or available at extra charge and set out relevant details.