Warranties, Indemnifications, and Liability Custom software services contracts should call out the promises you and your partner make to each other. The contract should also define who will be responsible, and to what degree, if certain issues arise.
Warranties Warranties are promises between you and your partner related to the services being performed.
WARRANTIES FROM YOUR PARTNER It’s reasonable to expect some guarantees from your custom software partner.
In general, you should expect your partner’s services to be performed:
In a professional and workmanlike manner
Following the terms of your contract and applicable statements of work
In accordance with the law
I believe the points above adequately convey what you should generally expect your partner to guarantee. However, you may want to call out other expectations you have.
In my experience, I’ve seen additional warranty expectations include:
Providing an inventory of all third-party code included in deliverables and a guarantee to not include any undocumented third-party code
Guaranteeing that the deliverables don’t include any disabling devices or “backdoor” access
Complying with your company policies
WARRANTIES NOT PROVIDED BY YOUR PARTNER When it comes to warranties, it’s important to remember that purchasing custom software development services is much different from buying a pre-existing software package.
Your partner will be collaboratively and iteratively working with you to define a specification for the solution. The Agile design and development process allows for specification definition, implementation, and refinement throughout an engagement. You can expect to discover and fix minor defects and bugs during custom software projects.
Agile methodology is essentially like going through a research and development process that results in a high-quality solution you can commercialize. It’s a world apart from buying a mostly pre-developed solution to use or resell with minor modifications.
Once the software is delivered, your partner likely has no control over:
How you sell the solution to your customers and the promises you make to your customers related to the solution
How and where you choose to host the solution
Modifications you might make to the solution
How you maintain (or don’t maintain) the solution with recommended updates, security patches, etc.
Changes to the hosting environment or integration with third-party services
Due to the points above, your partner will likely provide the solutions “as is.” They will not explicitly or implicitly guarantee that the created solution:
Is free from infringement claims
Is fit for a particular purpose
Has any warranty of merchantability
Is compliant with law (You own risks related to things like ADA or GDPR compliance.)
Will work in an uninterrupted fashion or be free from minor defects that don’t substantially affect the overall performance of the solution
Indemnifications Indemnifications are guarantees between you and your partner to hold one another harmless and assume costs related to defined events.
INDEMNIFICATIONS FROM YOUR PARTNER It’s important to remember that you are taking on the risk of developing and commercializing a custom software product. You can expect your partner to provide warranties related to the things they can control, but it’s not common for a development partner to protect you or compensate you for any other harm or loss in your efforts.
Your partner can control that their custom work for you is original and not copied or taken from another source. You should expect them to indemnify you against copyright, trademark, and trade secret infringement related to their original works.
It’s also unlikely that your partner will indemnify you from any other risks of commercializing the software solution or running your software-related business. Any other promises you want from your partner can be defined as warranties.
INDEMNIFICATIONS FROM YOU It might seem odd at first, but your partner will probably ask for you to indemnify them from certain risks. Because you will likely be running a software business with the collaboratively created solution as a core offering, your partner will want to be protected from the risks you take on in reward for growing your customer base. Once delivered to you, your partner has no control over how you use the solution or what promises you make to your customers about the solution.
Your partner will likely ask you to protect them from harm or loss resulting from:
Your use of the delivered solution
Their creation of a solution in accordance with your instructions
Their use, possession, or incorporation of any third-party materials in the solutio
Liability LIABILITY ASSUMED BY YOUR PARTNER Your partner should agree to some level of liability that is related to the warranties and indemnifications in your agreement.
It’s important to remember that your partner is essentially selling their time to collaboratively create a software solution with you. They will have a limited, maximum return for the services they provide. Accordingly, they will want a limited, cumulative level of liability. Liability can be limited based on dollars and the time frame when a liability obligation occurs.
In my experience, I’ve set liability caps based on:
A fixed dollar amount set at the level of expected business volume
Fees paid to partner under an applicable statement of work bounded by some amount of time in trailing months (e.g. in the previous 12 months)
LIABILITY NOT ASSUMED BY YOUR PARTNER You can expect your partner to assume liability for the things they can control and offer as warranties and indemnifications. Your partner will have no control over how you sell or use the software solution you have collaboratively created. Your partner also has no control over the value or risks related to how your customers use your software solution.
Therefore, your partner will probably not explicitly assume any liability to you or any third party for any other loss, additional expense, or damages that might arise from the sale and use of the software solution.
Breaches and Termination Sometimes, an engagement doesn’t go according to plan, and it’s a good idea to agree on what to expect if this occurs. Custom software contracts commonly define how to fix a situation if expectations aren’t being met, and they may also define rights for terminating an engagement.
Breaches Contract breaches occur when one partner doesn’t fulfill a promise made in the contract or in a specific statement of work. You can define specific actions and time periods for fixing a breach in the warranties section of your contract. Fixing a breach is commonly called a cure.
Some contracts specify a review and acceptance process and period for deliverables, allowing you to reserve the right to review deliverables and make sure they meet your expectations. A common pattern I see is:
All deliverables are subject to review and written acceptance.
The review period is defined as some number of weeks, let’s say two.
If the deliverables don’t meet the terms of the contract, or specifications outlined in a statement of work, they won’t be accepted.
Your partner then has some period of time, like 30 days, to replace the deliverables and cure the breach.
If your partner doesn’t cure the acceptance breach, you can take actions to cure the breach at your partner’s expense or escalate the breach to terminate the project or entire contract.
Sometimes, the process above gets even more complicated, allowing multiple attempts and different time periods to replace the deliverables, affect payment, etc.
I dislike defining an overly specific process for curing a breach. I believe terms like the ones above are holdovers from contracts for parts suppliers (e.g. the bolts you delivered are out of spec, and we want you to deliver new bolts within 30 days because that’s when our inventory will run out and cause production issues).
Agile software development already has a built-in process for continuous delivery and review. Detailed acceptance criteria are commonly defined during the project and validated through automated testing practices. Minor defects or bugs are part of the development process, identified during regular reviews, and fixed in the next sprint of work.
Instead of including all of the specifics of an Agile development process in a software development contract, I believe it’s better to:
Conduct appropriate due diligence on your partner and make sure you work with a partner who is dedicated to quality
Agree to work in alignment with generally accepted standards
Agree to be reasonably available to discuss and resolve any issues related to completing the project
Have a termination for convenience clause that allows you to get out of the contract if your partner doesn’t work to adequately resolve issues in the working relationship
My points above are related to review and acceptance, but I’ve observed contracts getting overly detailed on a cure process for infringement, compliance with policies, etc.
My general point of view is that less is more when it comes to defining cure processes for various kinds of breaches. I recommend:
Keeping detailed cure processes out of contracts
Specifying a general, high-level process for issue escalation and resolution
Having both parties agree to actively work to resolve issues
Having a termination for convenience clause that gives both parties an incentive to resolve issues, and a way out if the other party doesn’t reasonably cooperate
Termination Termination terms define what happens if you and your partner want to end a specific project defined by a statement of work or the business relationship defined by a master service agreement.
I recommend keeping these terms as simple as possible so that you and your partner can end a project or the active business relationship without cause. You should expect and want a notice period (such as 30 days) for termination so you and your partner can responsibly disengage.
During the disengagement period, you and your partner will work to finalize all deliverables, return materials as appropriate, and finalize payment for all services rendered.
You can expect to see a survivability clause in the termination section, outlining sections in the contract that will survive the termination of the active business relationship. These surviving terms may include:
Non-recruitment and Non-solicitation – An agreement to not hire each other’s employees
Warranties and Disclaimer of Warranties – Promises you make or explicitly don’t make
Liability Terms – Types and limits of liability you and your partner are taking on
Indemnification Terms – Losses you and your partner agree to protect each other from
Keeping termination language simple and taking a straightforward, high-level approach to curing breaches focuses you and your partner on keeping your business relationship healthy if something goes wrong. Assuming the business relationship is valuable to you both, each of you will do what’s right to preserve the health of the long-term relationship. I believe this is a better approach than getting into a debate about what does or doesn’t constitute a breach, a failed cure, or adherence to other specific terms that can be open to interpretation.
It’s important to remember that you and your partner will likely both have limited leverage when working together to correct an issue. The common incentive will be the value of the future business relationship.
In Agile software development projects, deliverables are provided continuously. Software is usually committed multiple times every day. Progress reports and other higher-level deliverables are delivered every one to two weeks. Often, all digital deliverables are stored in infrastructure you control. Your partner will probably be invoicing you every two or four weeks.
This situation means you will always have possession of nearly all deliverables from active work. Commonly, your partner will have outstanding payment risk if they don’t require pre-payment, invoice in arrears, and net payment terms at 15 or 30 days. This means you will likely have more negotiation leverage with your partner when you are working to correct an issue. Your partner will want to reduce outstanding payment risk and work to preserve the value of the future relationship.
