| Area of Law | Information Technology |
| Article Name | Considerations Surrounding Tech Development Agreements |
| Proposed Publication period | March, 2019 |
| Authors | Shaun Paulian, Arsh Kaur and Nicole Lim |
I.T. Contracts – Food for thought for Developer’s and Clients alike
The Digital Revolution is coming to an end, as we move to the Fourth Industrial Revolution into robotics, artificial intelligence, nanotechnology, quantum computing and the like.
Tech development companies are everywhere, working in tandem with every individual or entity that has a new idea, and requires a website, app or software to launch or facilitate that idea.
As with most commercial dealings, there is a spectrum of issues, stumbling blocks and deal breakers when it comes to I.T. contracts and the work that ensues from those contracts. Such issues, if not clearly defined in the contract or not managed during the project could end up being vey costly for both parties (the tech development company and the client) and very easily lead to disputes and potential litigation.
Our considerations below are intended to provide dual legal perspectives and advisable safeguards to be taken by both the (1) tech developer and the (2) client alike, and are applicable to a gamut of I.T. contracts, including for:
- Technology development
- Software development
- Website development
- Data management
- Systems integration
- UI/UX Design
PROJECT STRUCTURE
Issues faced by Developers:
Developers often face unwarranted claims by clients of unsatisfactory performance, which often occurs at the conclusion of the tech dev project. This is often caused by a simple miscommunication or misunderstanding of the client’s requirements, but there are also frequent occasions where the client’s expectations may be unreasonable or even unachievable.
Issues faced by clients:
The end-product delivered by the developer is unsatisfactory or does not meet the client’s requirements or what was represented by the developer. The client would have little choice but to incur additional costs for variations and extensions of work.
The solution:
It is imperative that when a client engages a developer, both parties are as clear as they can possibly be on the:
- Concept
- Desired outcome of the concept
- Scope or parameters of the work to be performed
- Comprehensive development plan, with clear milestones for delivery from the developer to the client as well as according payment terms
This initial step would go a long way in creating and maintaining a realistic level of expectations as to the results that are achievable and can be delivered by the developer, within the delivery schedule.
Breaking down the project into stages also allows the client to:
- monitor the progress of the development of the software;
- gauge if the key deliverables have been fulfilled by the developer, and if not, to require more work to be done by the developer, without the need of variation orders or extra charges; and
- if necessary, steer the developer into making changes/variations at the earliest stage possible, which the Developer may then charge for.
TESTING & ACCEPTANCE
Issues faced by Developers:
Undue delay by the client on accepting ultimate delivery and sign-off (especially at the User Acceptance Testing or UAT phase of the project) even though the issues were minor bug fixes which could easily be remedied and does not have a substantial impact of the functionality of the tech.
Issues faced by clients:
The developer refusing to adequately assist or remedy the issues upon failed testing, or, undue delay by the developer in fixing the issues.
The solutions:
In order to ensure that the developer remains invested in resolving all problems/issues, the payments may be made conditional upon successful testing and acceptance after each stage of the project or each module / section or part developed, as opposed to doing a singular, all-encompassing UAT right at the end of the project.
A reasonable timeline should also be provided for the client to either sign-off on the development stage or report on bugs or errors which need to be fixed. Beyond that agreed timeline, the client should be deemed to have successfully accepted that development stage and the fees owed to the developer shall be due and payable forthwith. The developer should also be given a reasonable timeline to successfully fix the bugs/errors.
FEE STRUCTURE
Issues faced by Developers:
The client defaults on making payment halfway through the development project.
Issues faced by clients:
The developer charges based on time costs and takes advantage of such payment schemes by prolonging the project.
The solutions:
The payment schedule should correspond to with the development plan and the delivery schedule., with prompt payment being made by the client upon successful testing and signing off on each stage, and if the client defaults in making payment at any one of the stages, the developer entitled to cease further performance and development works, and having rights to retain parts of the source code which relate to unpaid milestones or deliverables.
FEE FOR VARIATION / FURTHER WORKS
Issues faced by developers:
The client constantly revises and deviates from the planned Statement of Work and/or requests for changes or variations to be done to the project without wanting to pay additional costs.
Issues faced by clients:
The client is faced with inflated rates for variation works due to their increased dependence on the developer.
The solutions:
Variations are part and parcel of all development projects, it is almost impossible for every single consideration to be accounted for by either party at the outset of the project. Fees charged for variation works, should (as far as possible) be foreseen and/or calculated by the developer at the outset, and provide the client with a clear schedule annexed to the contract for:
- the type of variation work that may arise, and what such work would entail
- a ranged estimate of number of days involved to conduct the variation work
- a qualification that such variation work may have a direct impact on the delivery schedule by a certain number of days
- the cost of conducting such variation works
Once parties have agreed to this at the outset, it would potentially limit the amount of disputes that could ensue as a result of such variation orders.
SUPPORT & MAINTENANCE
Issues faced by developers:
The client demands for constant support, maintenance and/or training, without wanting to enter into a separate agreement for the same.
Problems faced by clients:
The developer “disappears” once the project has been completed, or delays in responding to issues with the tach, causing the client to face downtime which in turn disrupts the client’s business
The solutions:
The client should ensure that the developer will be providing an adequate level of support to the client in case of errors/issues as reported by the client and that it is either reflected in the main development agreement or in a separate support and maintenance agreement.
On top of user manuals, guidelines and other comprehensive documentation which may be provided upon delivery/installation of the product, adequate training should also be given to the client on how to use and operate the product for its intended purpose.
Parties should agree on the details and scope of the specific support services that will be provided and the duration of such support arrangement. Fixing clear timelines for the developer’s response time should always be a main consideration so that the client’s business is less likely to be disrupted.
WARRANTY
Faced by Developers:
The client claims that the product does not work in the manner that has been reasonably contemplated by the parties.
Faced by clients:
Bugs or errors only begin to surface or are detected after a period of usage of the tech.
The solutions:
The developer should carefully consider the extent of warranty that it is prepared to provide for the tech.
On the converse, the client should ensure that, at minimum, the developer shall remedy any reproducible programming errors at no additional costs.
Adequate time should be given for the client to detect bugs/issues/errors which might only begin to surface after usage of the product over a period of time. Accordingly, the developer should also be given adequate time to resolve those bugs/issues/errors.
The duration of the warranty should be expressly provided for within the contract.
Further, the developer should also consider any suitable exclusions from warranties such as when errors are caused by third-party issues, or when the issues are caused by the misuse or unauthorised modifications of the product by the client.
CONFIDENTIALITY
Issues faced by developers:
The client reveals/discloses to third-parties’ documentations and/or the discussions that were held that would reveal the developer’s trade secrets, etc.
Problems faced by clients:
The developer reveals/discloses to third parties the documentations and/or the discussions that were held that would reveal the client’s trade secrets, etc.
The solutions:
The confidentiality obligation should be extended to all staff of the developer and the client, and the obligation should survive the completion or termination of the agreement.
INTELLECTUAL PROPERTY (“IP”)
Issues faced by Developers:
Claims by the client that the ownership over the copyrightable source code of the tech has shifted to the client.
Issues faced by clients:
Claims by the developer that the ownership over copyrightable source code of the tech remains with the developer, in light of outstanding payments.
The solutions:
It is prudent that parties agree on how source code of the tech is going to be delivered from the developer to the client, this is usually referred to as delivery by way of sprints.
If the agreement spells out that source code is delivered in sprints and is contingent upon satisfaction of payment milestones, IP ownership of specific source code can clearly be demarked at the start, thereby limiting grounds in which either party is able to raise tenable arguments on ownership after that.
TERMINATION
Issues faced by developers:
The Developer faces difficulty in collecting payment for work that has already been done.
Issues faced by clients:
The client is left with a half-finished product and has difficulty appointing another developer to complete the product as there might be an infringement of the rights and licenses of the tech.
The solutions:
If the non-defaulting party is the developer, the developer should be allowed to make a reasonable claim for the costs of work that has already been done. On the converse, if the non-defaulting party is the client, the client should be allowed to make a reasonable claim for refund of monies paid in excess of work done.
Parties should ensure that notwithstanding the agreed ownership of source code arrangement as discussed above, the agreement should include a clause to provide that the non-defaulting party would get to retain ownership of the rights and licenses to the product, which has been developed and delivered to the client. This would allow the client to appoint a new developer to complete the project.
As can be seen from the discussions above, the considerations involved in I.T. Contracts are extensive and sometimes very technical. It is crucial that the lawyers engaged to prepare such agreements understand their clients’ business and needs in order to protect and hopefully prevent such pitfalls from arising.
-By Shaun Paulian, Arsh Kaur and Nicole Lim
Shaun’s core area of specialisation is within the tech and fintech industries, having worked with a myriad of clients on both the developer and the client side of such tech development projects. Contact Shaun to find out more.