Software development agreement: the ten clauses that decide how the project ends

A software development agreement gets signed in the optimistic week and read in the bad one. Nobody opens it while the project is going well. So the test for every clause is simple: when the client refuses to accept the build, stops paying, or wants out, does this document tell both of us what happens next?

Most of the agreements I am sent for review are long on boilerplate and short on the five or six clauses that carry real money. This page covers what the agreement contains, how it relates to the MSA and SOW structure, and the ten clauses worth your negotiating time. It is part of the contracts hub.

What it is, and how it relates to an MSA and a SOW

There are two ways to paper a software project.

The first is a single software development agreement. Legal terms and project terms sit in one document, usually with the specification, timeline and payment schedule as exhibits.

The second is a master services agreement plus a statement of work. The MSA holds the terms that stay constant for the relationship: IP, confidentiality, liability, termination, payment mechanics. Each project then gets a SOW of a few pages covering scope, deliverables, price and dates.

The clauses are nearly identical. The choice is about how many times you want to negotiate them. If there is any chance of a second phase, and there usually is, I use the MSA structure, state which document wins a conflict, and keep the SOW commercial. If the client insists on a single agreement, I still write the scope as a separable exhibit so it can be replaced without reopening the legal terms.

The ten clauses that matter

1. Scope and specification

The agreement should point to a specification detailed enough that a third person could tell whether a feature is in or out. List deliverables, list assumptions, and list exclusions. The exclusions list is the part clients skim and the part that saves you. A vague scope clause is where scope creep starts, and no later clause repairs it.

2. Change control

Any change to the Specification, timeline or Fees requires a written change order signed by both parties. Developer is not obliged to perform work outside the Specification until a change order is signed.

Two sentences. Without them, every request in a chat thread becomes an argument about whether it was included.

3. Fees and payment

State the pricing model, the schedule, the payment terms, and what happens when payment is late. For fixed-fee work, tie payments to milestones you control, such as delivery to staging, and avoid milestones the client controls, such as launch. For hourly work, state the rate, the billing increment and the invoicing rhythm. The trade-offs are in fixed price versus time and materials.

Include a right to suspend:

If any undisputed invoice is more than 15 days overdue, Developer may suspend the Services on written notice until payment is received, and all delivery dates will be extended accordingly.

4. Acceptance

Acceptance is the clause with the most money attached and the least attention paid to it. It needs four things: a test period, a standard, a rejection procedure, and a default.

Client will have 10 business days from delivery of each Deliverable to test it against the Specification. Client will either accept the Deliverable in writing or deliver a written list of the specific ways it fails to conform to the Specification. Developer will correct the listed nonconformities and redeliver, and the test period will restart for the corrected items only. A Deliverable is deemed accepted if Client does not reject it in writing within the test period, or if Client uses it in production.

The standard is the specification. “To Client’s satisfaction” is an open-ended obligation and should be struck wherever it appears. The deemed acceptance sentence is the one that stops a project sitting in limbo for three months because the client’s reviewer went on leave. Clients sometimes push the period to 15 or 20 business days. That is a fine concession. Removing deemed acceptance altogether is a concession I do not make.

5. Warranty

A warranty is your promise about the state of the work after acceptance.

For 60 days after acceptance, Developer warrants that the Deliverables will conform in all material respects to the Specification. Developer’s sole obligation, and Client’s exclusive remedy, for breach of this warranty is for Developer to correct the nonconformity at no charge. This warranty does not cover defects caused by modifications made by anyone other than Developer, by Client’s hosting environment, or by third-party services.

Thirty to ninety days is the normal range. The three things to hold are the standard (the specification), the remedy (repair) and the exclusions. A warranty with no end date is a free maintenance contract. When a client wants a year of coverage, offer a paid support plan that starts when the warranty ends.

The clause should also disclaim implied warranties to the extent the law allows. Consumer and some small-business protection rules limit such disclaimers, and UK and EU law is stricter about them than US law, so have that sentence reviewed locally.

6. Intellectual property

The agreement must say who owns the deliverables, when ownership passes, and what happens to the tools and libraries you brought with you. My standard position: the client owns the deliverables on full payment, the agency retains its background IP, and the client gets a perpetual license to any background IP inside the build.

This clause deserves more space than it gets here. Who owns the code covers the default rules and the three ownership models, and the IP clause article has sample wording for each negotiating position.

It also has consequences that outlast the project. An agency that signs “client owns all work product” on every deal finishes a decade of work owning nothing. An agency that keeps its background IP, and keeps title on the projects where the client only needed a license, ends up holding a body of working code that is its own property.

If your past agreements left the IP with you, that code is an asset with a value you can check. See what your repositories are worth.

Code assigned to a client stays the client’s and is never yours to license. For what the rest can be worth, see what your old code is worth.

7. Confidentiality and data

Mutual confidentiality, with the usual exceptions for information that is public or independently developed. If you will touch personal data or production systems, say what security measures apply and who is responsible for backups. Vague promises of “industry standard security” get quoted back to you after an incident, so describe what you actually do.

8. Limitation of liability

Two parts: an exclusion of indirect and consequential losses such as lost profits, and a cap on everything else.

Neither party will be liable for any indirect, incidental or consequential damages, or for lost profits or lost data. Each party’s total liability under this Agreement will not exceed the Fees paid by Client under this Agreement in the 12 months before the claim arose.

Work the numbers before you negotiate. On a $180,000 build with a cap at fees paid, your worst case is $180,000. With no cap, your worst case is whatever the client’s lost revenue turns out to be, on a project where your margin might have been $35,000. Clients commonly ask for carve-outs from the cap for confidentiality breaches, IP infringement and deliberate misconduct. Carve-outs for the last are standard. For the first two, a higher separate cap, such as two or three times fees, is a reasonable middle. Then send the clause to your insurance broker and confirm your professional liability policy covers what you just signed.

9. Indemnities

The client will want you to cover third-party claims that the deliverables infringe someone’s IP. That is fair for code you wrote. Limit it to exclude client-supplied materials, open source components used under their own licenses, and anything the client modified. Ask for the mirror indemnity for the materials the client gives you.

10. Term and termination

Three exits are needed: termination for material breach after a cure period, termination for non-payment, and, if the client insists, termination for convenience.

Client may terminate this Agreement for convenience on 30 days’ written notice. On termination, Client will pay for all Services performed and expenses incurred up to the termination date, plus any non-cancellable commitments.

Then the clause that matters most on the way out: what happens to the code. Work that has been paid for is assigned. Work that has not been paid for stays with you until it is. Say so explicitly, because a terminated agreement with an ambiguous IP position is how disputes start. If you are the one ending it, how to fire a client covers the handover.

Clauses that can stay short

Governing law, notices, assignment, force majeure and entire agreement need to be present and need little negotiation. Two exceptions. Non-solicitation of your staff is worth a mutual twelve-month clause if the client will work closely with your developers. And if the client holds a license in place of ownership, it may ask for source code escrow, which is a reasonable request with cheaper alternatives.

How to review one in thirty minutes

When a client sends its own agreement, read these in order and stop at the first one you cannot live with:

1. The definition of deliverables or work product. Is it bounded by the specification?
2. Acceptance. Is there a test period, an objective standard and deemed acceptance?
3. IP. When does title pass, and is your background IP carved out?
4. Liability. Is there a cap, and is it mutual?
5. Warranty. Does it end?
6. Termination. Are you paid for work done, and what happens to unpaid code?
7. Payment. Net how many days, and can you suspend?

Seven answers tell you whether you are looking at a fair agreement with rough edges or a document designed to move all the risk to you. The first kind takes two redlines. The second kind is information about the client, and it arrives before you have written a line of code.