Writing a Great Software Development Contract, Part 1 – Overview & Principles

If you’ve never worked through contracting for custom software development services, it can be challenging. Your existing templates may be rooted in business relationships focused on purchasing tangible goods or pre-existing software. Custom software dev 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.

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

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

Custom software development contracts have many more considerations than the topics I cover in this series. I’m writing about these categories because I’ve found them to be the most commonly misunderstood.

This post provides an overview and foundation for the other posts in the series. It will cover:

1. The types of contract documents defining the business relationship and projects.
2. How custom software contracts are different than other types of supplier or IT contracts.
3. A few general principles.

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

When I write about contracts in this series, 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. MSAs will include all of the topics discussed in this series, plus more. 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

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

• 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 series 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 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 positive 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.

General Principles

There are two principles at the foundation of my points in this series:

• Each party should be responsible for the things they can control based on the services provided or intended activities.
• Upside opportunity and downside risk should be relative in scale for each party.

The rest of this series will cover some of the nuanced details in key sections of MSAs where I commonly see confusion around pre-developed software solution purchasing terms being applied to custom software development services or violation of the principles listed above.

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