Writing a Great Software Development Contract

If you’ve never worked through contracting for custom software development services, it can be challenging. Your existing software development contract templates may be rooted in business relationships focused on purchasing tangible goods or pre-existing software. Custom software development contracts have unique considerations and require a slight shift in mindset.

I work with Atomic’s clients and our legal team through many of our contract discussions. I’ve found common, recurring considerations in contract discussions, and I’m sharing my experience and insights to help you understand the logic behind the legal language and redlining that you might experience in the contracting process.

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.

Types of Contract Documents

For long-term relationships or large projects, contracts are usually separated into two types: the Master Service Agreement (MSA) and the Statement of Work (SOW).

Master Service Agreement (MSA)

When I write about contracts, I will be referring to the terms included in an MSA. Different organizations will use different names for an MSA like an “Independent Contractor Agreement” or “Professional Services Agreement.” Regardless of the specific contact name, the intent is the same.

The MSA will contain the legal language framing all project work done under the MSA. Other considerations covered in an MSA may include:

• Payment terms
• Non-disclosure and confidentiality
• Non-solicitation and non-recruitment of each other’s employees
• Insurance requirements
• Marketing rights

MSAs usually have agreement terms that span multiple years or have an indefinite term unless they are terminated by one of the parties. Putting all of the general, legal language in a long-term MSA means SOWs can focus on specific project details and be reviewed and executed more expediently.

Statement of Work (SOW)

SOWs will contain specifics about a project. SOWs will commonly include a high-level project plan including:

• Software team composition
• Roles and responsibilities
• Estimated budget and schedule
• High-level phases or milestones
• High-level descriptions of deliverables

SOWs will reference the MSA and be bound the terms of MSA as if the MSA terms were logically included in the SOW.

How Custom Software Dev. Contracts are Different

Note: This post assumes you’re hiring a partner to provide you with software development services. And that you’re planning to allow your customers, employers, or other stakeholders to use the software they make.

An established company may have created many MSAs over the year. But most are for purchasing physical materials/equipment, pre-developed software, or professional services like legal, accounting, marketing, etc.

What do these all have in common? The deliverables are:

• Pre-developed and the risk of design, development, and product/market fit is low
• Mostly inactive once delivered (e.g. a contract is reviewed, a financial audit/projection is complete, digital assets are delivered or a marketing campaign is executed)

Neither of these is true for custom software services.

Pre-Built Software vs. Custom Software

Providing custom software services is different from delivering pre-built software. And it needs a different kind of MSA.

PRE-DEVELOPED SOFTWARE PRODUCT

• Your provider has removed most of the risk out of developing the software. The software project is done, the cost and schedule are known history, and your partner is focused on marketing and sales.
• Your provider is pursuing the upside opportunity of their investment and risk-taking through increased sales. The more they sell, the more return on investment they make.
• Because their upfront development costs are known, you can probably expect your provider’s pricing structure to be closer to fixed-budget, fixed-scope, or a set price for particular volume (e.g. $100 per user, or $100 per month, etc.).
• An increased customer base also means an increased risk footprint for support, warranty claims, intellectual property infringement claims, etc. Your provider’s business model should protect them against the downside risks relative to their success.
• You should expect the partner to take on more responsibility for warranties and indemnifications against intellectual property infringement.

CUSTOM SOFTWARE DEVELOPMENT

• Software development risk is at its highest point. Scope is roughly defined but software is extremely complex and the devil can be in the details.
• Product/market fit risk (regardless if your customers are external or internal) is high and the scope should be influenced through proper human-centered design practices. Cost and schedule can be set as a constraint for a first release that begins to generate revenue. Hard trade-off decisions will need to be made throughout the project. It’s also likely that subsequent phases of development will be required to create and maintain a desirable solution.
• Your partner is essentially selling the time of their experienced consultants to collaboratively help you create a software product you will take to market. Your partner will guide the design and software development process and work to surface areas of important consideration and risk. You will be owning key decisions on scope based on your customer desires/needs, competitive landscape, intellectual property considerations, legal compliance requirements, etc.
• Your partner can control the quality of the services they deliver and the delivery process they use to provide you an informed and successful project experience.
• Your partner will likely be selling their time and have a limited, revenue upside based on the number of hours they work. Once developed, you will essentially be in the position outlined above for marketing and selling a pre-developed software solution. You will be working to maximize your upside through sales based on the scale you can achieve.

Intellectual Property Rights

Custom software contracts need to be clear about intellectual property rights—the ownership and use rights for each component in the final product. A software product can have some components that are custom, some that are open-source, and others that are commercially licensed. And each can have separate IP rights.

Custom Deliverables

The author of any creative work inherently owns the intellectual property rights to their work. Without agreeing otherwise, the code a software developer writes belongs to that developer.

You want to make sure your contract assigns ownership of all original, creative works developed under the contract to your company. Your contract should define all deliverables created as original work under your contract as “works made for hire” and assign your company as exclusive owner of all original works and their related intellectual property rights.

Your partner needs to own the deliverables and related intellectual property rights in order to assign them to you. They should have similar agreements in place with their employees and contractors in order to assign the creative works and related intellectual property rights created by the people who work for them to their business. This chain of agreements assigns ownership and IP rights from the author to your partner, and then to you.

You can expect your partner to have terms specifying when ownership is assigned. It’s common for custom software firms to assign ownership of deliverables upon payment for the deliverables. Assuming your projects are using Agile software practices and deliverables are being continuously delivered, you will be receiving deliverables on a daily basis.

Many custom software providers invoice based on the time spent creating deliverables. You will receive invoices for a period of time (e.g. hours, or development team weeks, etc.) and will own the received deliverables created during the duration of the invoice upon payment of the invoice.

Pre-Existing Work

Custom software applications commonly include pre-existing work. For example, a web application will include pre-existing work like a web framework and supporting libraries.

Pre-existing work is used by your partner for your benefit. Instead of creating everything from scratch, your partner is using pre-existing work to save you time and money.

This type of work can be created by your partner or a third party.

It’s important for you to know what pre-existing work is included in your deliverables and to understand your rights and limitations related to the pre-existing work.

INVENTORY OF PRE-EXISTING WORK

I recommend asking your partner to maintain and supply an inventory of all pre-existing work included in your deliverables. It should include the specific version and source of any pre-existing work, along with related license information. The inventory will serve as a reference for you to help manage your rights and limitations related to the portions of the deliverables you don’t exclusively own.

RIGHTS AND LIMITATIONS RELATED TO PRE-EXISTING WORK

You should expect your partner to use their professional expertise to guide your selection of any pre-existing work included in the deliverables. Based on your commercial expectations for the deliverables, your partner should be able to recommend pre-existing work with the appropriate licenses.

Keep in mind that your partner’s expertise will be primarily focused on the technical and functional considerations related to the included pre-existing work. Your software partner will not likely take on a contractual obligation to provide you formal, legal advice of any kind.

You should also expect to own the responsibility of managing the benefits, limitations, and risks of including pre-existing work in your deliverables, based on your intentions of using the deliverables. You need to carefully consider your rights and limitations related to pre-existing work from third parties and your partner.

PRE-EXISTING WORK FROM A THIRD PARTY

A competent software partner will help steer you toward frameworks and libraries that, to their knowledge, have appropriate licenses. However, you should also engage the help of a legal professional to carefully consider the license terms of any pre-existing work you will include in your product in the context of how you will be using the pre-existing work.

When you include and use third-party, pre-existing work in your product, you are creating another relationship with those parties. You shouldn’t expect the contract you have with your partner to make representations or promises about any license terms related to third-party, pre-existing work, as those terms are defined in each third-party license.

Some pre-existing work may be open-source software and have a generally-known, publicly available license.

Other pre-existing work may be closed-source, purchased, and have a unique license agreement.

You will want to make sure the license terms of all third-party, pre-existing software enable you to meet your commercial goals. Some people unnecessarily fear open-source software due to common license terms that require any solution using the open-source software to also be open-source. However, there are many open-source software licenses with more commercially friendly terms.

PRE-EXISTING WORK FROM YOUR PARTNER

You can expect the contract with your partner to include license terms for any pre-existing work provided by your partner.

It’s common for custom software partners to have tools and libraries they created for general use across many of their development projects.

At Atomic, we make revenue from the custom software we write for our clients. We don’t charge license fees for our pre-existing work. We include our pre-existing work, as appropriate, to help speed development and focus the project budget on custom development work.

Even if your partner includes their pre-existing work like Atomic does, and you don’t have to purchase it, I recommend that your contract includes general license terms related to all partner-developed, pre-existing work included in their deliverables.

I also recommend making the general license terms as permissive as possible. You should expect a non-exclusive license, as your partner will likely be using their pre-existing work in other client projects. However, you should be able to use the pre-existing in any way possible to further your commercial goals. For instance, you should be able to use, reproduce, sub-license, and make derivative works of your partner’s pre-existing work as necessary to achieve commercial success with your broader software product.

Your partner may reasonably expect that you don’t do things like publish or sell their pre-existing work independently from the overall software solution.

Intellectual Property Issues

When it comes to IP infringement risk, I like to keep the following principles in mind:

1. Risk and reward should be correlated.
2. Risk should be owned by the party that can best control and manage the risk.

When you are buying custom software services, you are effectively buying your partner’s time to create original work on your behalf. Your partner will likely charge you an hourly rate for their time. They have no greater reward or leverage other than the agreed-upon compensation for their time.

You will be working to create leverage from your custom software investment. When you make an upfront investment of capital, you’ll want to maximize the recurring revenue it can generate.

Copyright, trademark, and trade secret infringement

Your contract should obligate your partner to own the risks of copyright, trademark, and trade secret infringement for their works made for hire and their pre-existing work included in your deliverables. You should expect that your partner isn’t copying code that they (or others) have previously written and delivering it you represented as original work. You should also expect that your partner is not misappropriating a trade secret they have learned through their work with another client.

If such an infringement occurs, it’s reasonable to expect your partner to replace or pay for the replacement of any infringing deliverables. This remedy is on scale with the level of value exchange for the original services.

Your partner probably won’t take on liability for any indirect damages resulting from the infringement, as those potential damages scale with your level of commercialization success and are best managed by you.

It’s also unlikely that your partner will take on liability for copyright, trademark, or trade secret infringement risk in any third-party, pre-existing work included in the deliverables. Because you are receiving the speed and cost benefits from using pre-existing work, you should be willing to take on the risk of needing to replace third-party, pre-existing work for infringement or any other reason. You can work to manage infringement risk with third-party materials by relying on legal professionals during your review of the third-party license terms.

Your partner will also likely include contract terms that they will not take on infringement risk for including any deliverables supplied by you or created under any detailed specifications you provide.

Patent infringement

While you can expect your partner to not knowingly violate any patents in their works made for hire or pre-existing work, you shouldn’t expect them to take on patent infringement liability for any of the deliverables.

Custom software engagements are highly collaborative, and your partner will be creating original work that is guided by your goals, needs, industry expertise, and existing knowledge. You know your industry and competitive landscape better than your partner. Patent infringement risk belongs as a key consideration of your broader risk management activities related to product development and commercialization.

Your partner will be evaluating third-party materials from a technical perspective, but not from a legal one. Because you will be getting the speed and cost benefits from using pre-existing work, you should be willing to take on the infringement risk.

Your risk of a patent infringement claim, legitimate or not, scales with your commercial success. Unfortunately, the more successful you are, the bigger target you become. This is another reason for you to own patent infringement risk management and liability. You are pursuing the bigger reward, and the value you create from your investment should be able to cover any risk that materializes.

If your partner held patent infringement risk, their risk would grow as you become more successful. This doesn’t make sense, as your partner had the fixed upside of the fees for their service. Also, remember that you are only engaging your partner for their time and technical expertise. Your software partner is not providing legal services related to patent infringement.

I recommend you work with legal professionals early on to understand if there are parts of your software product that could be infringing. You then should let your partner know of any legal considerations they should use as constraints when designing and developing your product. With that preparation, you will be ready to show due diligence and documentation if an infringement claim is ever made.

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.