Writing a Great Software Development Contract, Part 4 – 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.

Disclaimer

This post is not formal legal advice. I’m not a lawyer. I recommend you work with legal professionals for all of your software contract needs.


This is the fourth post in a series that will cover common considerations in the following categories:

  • Overview
  • Intellectual Property Rights
  • Warranties, Indemnifications, and Liability
  • Breaches and Termination

This post focuses on breaches and termination:

  1. Breaches – What happens when a promise in the contract is not fulfilled?
  2. Termination – Under what circumstances can a project or the contract be terminated? What happens when a project or the contract is terminated?

1. 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

2. 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.


Writing a Software Development Contract

This post is part of a series on writing a great software development contract:

  1. Overview & Principles
  2. Intellectual Property Rights
  3. Warranties, Indemnifications, and Liability
  4. Breaches and Termination

I hope these insights will be helpful in guiding you through the development of your contracts.