After conceiving your great idea, perhaps the next TripAdvisor or Uber, 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 ‘watch-outs’ to consider when negotiating with your developer. It is important to take a closer look at the terms and include some safeguards, before putting pen to paper.
Quotations are estimates only
The reality is, we are all working on a budget. If a developer tells you the project will cost R80,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 increases and requiring that any increases in fees be effective only with your approval.
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.
Developer retains all intellectual property
This is a very important point to be aware of. 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, front-end code, back-end 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.
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.
A 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.
To minimise the risks associated with the development of your next App, please feel free to contact our IT&IP Department.
This article is for general information purposes and should not be used or relied on as legal or other professional advice. No liability can be accepted for any errors or omissions nor for any loss or damage arising from reliance upon any information herein. Always contact us At DKVG Attorneys for specific and detailed advice.
For more information, contact our IT&IP Law specialist department.
© DotNews, 2005-2020. This article is a general information sheet and should not be used or relied on as legal or other professional advice. No liability can be accepted for any errors or omissions nor for any loss or damage arising from reliance upon any information herein. Always contact your legal adviser for specific and detailed advice. Errors and omissions excepted (E&OE)