08 October 2019
After conceiving your great idea, perhaps the next Uber or Citymapper, you turn to a software developer to create that magic sitting behind a little icon that will shine brightly on millions of devices. They provide you with a relatively innocent looking set of terms and conditions and you just need to sign them to get the work started and meet your deadline to market.
We outline five ‘watchouts’ to consider when negotiating with your developer. It is important to take a closer look at the terms and build in some protections, before putting pen to paper.
1. Quotations are estimates only
The reality is, we are all working to a budget. If a developer tells you the project will cost $70,000 that may be the extent of your budget. If the provider then charges actual amounts that are substantially more, it may not be a matter of just finding the extra cash, but that you would not have proceeded if you were aware of the cost in the first place. We have seen terms giving the provider great flexibility to amend costs, providing that "quotations are estimates only based on anticipated requirements". We recommend you ideally seek to cap costs based on core functionality being achieved, or otherwise building in a change management process to manage any unanticipated increase, and requiring that any increase in fees be effective only with your approval.
2. Project timelines are not enforceable
It is likely that time will also be of key importance when making your decision about the right provider. You may have internal or external commitments to meet, that rely on the software being developed within the timeframes you provide. Beware of the fine print and terms that, despite what might be listed in the schedule as the timeline for delivery, say that these timeframes are not enforceable or can be varied at the sole discretion of the provider. Again, it may be unrealistic to contemplate no changes, but building in a process that requires your approval helps you control costs and delivery dates before they blow out.
3. Developer retains all intellectual property
Owning or having rights to use the intellectual property in your app will be key to the valuation of the product and any investor will want you to establish when investing in your company. Commonly, it is thought that if you are paying for something, you will receive the intellectual property rights in the materials. In fact, these rights need to be assigned in writing. Do not assume that terms drafted by your software provider will leave you owning the intellectual property in the product delivered. Instead, terms we have reviewed leave the developer owning the intellectual property rights, including the source code, frontend code, backend code, wireframe designs, database designs, and content workflow systems, flash files and animation. Be on top of the effect of anything you sign and if it differs to your expectations, negotiate the outcome you need before signing it.
4. Client bears all risk
The developer is the provider of the services and should be bearing the greater portion of the risk. But accepting a provider’s standard terms will often see you signing up to the reverse scenario, with the terms instead requiring you to indemnify the provider for all claims and loss arising from (for example) your use of the app. When the provider is developing the intellectual property behind the app, it is standard practice for the provider to give this indemnity and warrant that the use of the app, for the agreed purpose, will not infringe third party rights.
5. Developer can cancel without reason
Ideally, you will have the ability to terminate a development agreement without needing to prove the provider is in breach of the terms. But you may find that in standard development terms, the provider instead only gives itself this ability. This might mean that if the provider gets a better deal or finds your project is more than it can manage, the provider can say “see you later” with not much notice, leaving your project stranded and timelines thrown out. Instead, we would recommend the provider is locked in until the completion of the project to your initial specifications and satisfaction.
Author: Emily Booth
The information in this publication is of a general nature and is not intended to address the circumstances of any particular individual or entity. Although we endeavour to provide accurate and timely information, we do not guarantee that the information in this newsletter is accurate at the date it is received or that it will continue to be accurate in the future.