Ten top tips for engaging a software developer

Share

It is absolutely essential, when engaging a software developer, to have mechanisms in place to ensure that the end product meets your needs. Will the software function in accordance with what you have asked for? Will your organisation own the software? If not, will your organisation be required to continue to pay annual licence fees for the software? What about software maintenance and upgrades? Must your organisation engage the same software developer to perform the work?

Negotiating and putting in place a suitable software development agreement will assist you in getting certainty on these issues. This article flags the questions you ought to ask and consider when engaging a software developer.

What are you commissioning for?

Tip 1 – Develop a clear scope of work

Clearly documenting the scope of work may sound simple but is often more complex than it looks. At the outset, your organisation may not have sufficiently developed a comprehensive document setting out each of your requirements in detail, in which case, the software developer may first undergo a “scoping” process to determine the extent of the work required. The software developer may charge a fee for performing the scoping process. It is important that your organisation owns the outcome of the scoping process so that you have a document that sets out your requirements and specifications, allowing the possibility for your organisation to take the document to another developer to complete the work.

Ideally, the scope of work will address technical, functional and aesthetic requirements of the software, delivery timeframes, fees and a payment schedule. Additionally, your software development agreement should also reference this document for the purposes of assessing acceptance and resolving warranty issues.

What if your requirements change?

Tip 2 – Define mechanisms for change of scope

As part the natural progression of many software development projects, changes to the scope of work or functionality of the software may be required. This is usually because a project may evolve in an unexpected way or further requirements are envisaged during the development process. It is therefore prudent to set out a clear process for requesting, approving and implementing any changes to the initial scope of work and this process should also be reflected in your software development agreement. The process would likely involve a party proposing a change followed by discussion of feasibility, augmented timeframe for delivery and any increase in the fees. The proposed changes should only be implemented when they are signed off by both parties, indicating clear agreement for all changed parameters. 

Does the end product actually function in accordance with your requirements?

Tip 3 – Consider acceptance testing

You will need to ensure that the software you procured will function in accordance with your expectations. Implementing appropriate acceptance testing at various junctures can assist in keeping a project on track and reduces the likelihood of ending up with an unworkable software product. Acceptance testing is best conducted as a staged process – adopt a regimen that will allow you to test the product in each developmental phase for functionality, operation and performance. Taking a staged approach will also allow you and the developer to address any issues throughout the development cycle and manage expectations, including identifying any changes required.

Have you considered how to protect your investment against competitors?

Commissioning a software to be developed, especially on a bespoke level, can be a significant investment in time, money and resources. It is important that you consider ways to prevent your competitors from spring-boarding on your efforts and financial resources. You can do this by including confidentiality and non-compete provisions in your software development agreement.

Tip 4 – Include confidentiality provisions

It is important that your software development agreement include provisions to restrict the disclosure and misuse of confidential information. Confidential information may be carefully defined in the agreement to include commercially sensitive information or material that is provided to the developer for the purposes developing the software (e.g. briefs, discussions, schemes and plans) as well as information generated by a developer for a client in the software development process (e.g. scope of work or algorithms). It is also prudent to require that the software developer implement suitable security measures to prevent the disclosure of any confidential information. The agreement should clearly specify that all confidential information may only be used for the development of the software for your organisation.

Tip 5 – Consider non-compete clauses

A non-compete or restraint of trade clause in a software agreement may help you retain your market advantage for a longer period of time. Non-compete (or restraint) clauses typically restricts a party from producing or selling products or services to parties who compete with you. These clauses further prevent the party who may have acquired knowledge, skill, contacts, goodwill and reputation during the performance of the agreement from unauthorised exploitation after the agreement has expired or terminated. However, since non-compete clauses typically restrict a party’s freedom to trade (and reduces competition), they may be held as unenforceable and against public policy, unless they are proved to be reasonable in the circumstances to protect the interests of the parties. Non-compete clauses should therefore be carefully considered in terms of duration, geographic region and acts covered by the restraint on a case by case basis.

Will your organisation own the end-product?

Tip 6– Consider intellectual property ownership

When it comes to software development, it is important to consider the issue of intellectual property ownership. In Australia, software or computer programs are typically protected as copyright but there may also be some limited instances where software can be protected by a patent. Generally speaking, a software developer owns the intellectual property rights in a developed software as well as any accompanying original material that was created or developed (e.g. manuals, user guides, graphics and text), unless a contract provides otherwise. Very often, software developers will seek to retain intellectual property ownership in the software and accompanying materials – this essentially enables them to use the same software for other clients. Where the software developer retains the intellectual property ownership in the software, they provide a licence for the client to use the software for the agreed purpose, in which case, you should ensure that the licence is broad enough for your needs.

If you engage a software developer to create bespoke or custom software for your organisation, the better position is for the software developer to assign (or alternatively, to exclusively licence) the intellectual property rights that subsist in the software and any accompanying material to you. One advantage of this is to prevent the developer from providing the same software to competitors or other businesses in the market. It is however important to keep in mind that the developer’s fee in circumstances where intellectual property is assigned or exclusively licensed would usually be considerably higher.

Tip 7– Consider any use of open source or third party software

Software developers may incorporate open source or third party software in the software they develop for efficiency or other purposes. If these are incorporated, your organisation will not be able to own the intellectual property rights in the end product. In addition, you may be required to also make your software open source or seek a licence from the third party in order to use the third party software that is incorporated into your software.

Open source software is free software that is publicly available for users to use, study, redistribute and modify under relatively broad licences. Open source software is usually developed through a collaboration of multiple authors contributing to the same open source project, and licensing arrangements differ between different types of open source software products. Although free, use of open source software sometimes include restrictions on the end product, such as requirements to display permission notices or for the end product to be made available on an open source basis. If your software developer proposes to incorporate open source software in your product, it would be critical to check the licence terms for such open source software.

Third party software is software which a developer has licensed from another party (i.e. software which is not created by the developer). Again, if third party software is incorporated in your final software product or service, you may be required to pay licence fees to the third party for the ongoing use or commercialisation of the software.

It is often recommended that a software development agreement prohibits the incorporation of open source or third party software, unless with your prior written permission when the related issues have been thoroughly discussed and considered.

Tip 8 – Include intellectual property warranties

Warranties are written promises in a contract. It is prudent to manage your risks with intellectual property warranties. Some intellectual property warranties state(?) that the software is the original work of the software developer and does not infringe the intellectual property rights of any third party. Another example may be, where applicable, that the software developer will not use third party or open source software.

How will your organisation maintain the software?

Tip 9 – Product warranty

Product warranty is a guarantee as to the quality of the goods or services provided. As a general principle, your organisation should ask for a warranty that the software will meet the specifications agreed to and that any defects will be fixed within an agreed upon period.

Tip 10 – Access to source code

Source code of a computer program is a set of instructions in human readable form. To maintain, modify, improve or further develop any software, you will need access to the source code. Access to source code is often overlooked but can become(?) a contentious issue when negotiating a software development agreement. In most cases, software developers do not prefer to grant access of the source code to their clients, whereby the client may engage a different developer to maintain the software. It is recommended that your organisation reach an agreement with respect to access to the source code to manage risks for the project, such as when the developer goes out of business or you wish to terminate the agreement at some stage (e.g. as a result of the developer not meeting obligations or your organisation wanting to engage a different developer). One way to deal with this is for the source code to be held by a third party agent in escrow until certain pre-defined conditions or events for release are triggered (e.g. completion of the project and payment in full).

***

Taking a proactive approach in negotiating an appropriate software development agreement at the outset will help your project run more smoothly and minimise your risk in the long term. Make sure you have considered and addressed these ten tips when engaging your software developer.

Please do not hesitate to contact us if you have any questions regarding this article.

This article was written by Taryn Francis, Lawyer, and Sylvie Tso, Principal.

Share
Back to Articles

Contact our Expert Team

Contact Us