What contracts does an agency need?

Four cover almost everything. A master services agreement holds the legal terms. A statement of work defines each project. A retainer agreement covers ongoing monthly work. A consulting agreement covers advisory engagements where the output is advice.

Do I need an MSA and a SOW, or is one contract enough?

For a single small project, one combined contract is enough. As soon as you expect a second project with the same client, split them. The MSA is negotiated once and every later project needs only a short SOW.

Who owns the code an agency writes for a client?

It depends on the contract. A well-drafted agreement gives the client the project-specific deliverables once it has paid in full, and lets the agency keep its pre-existing and general-purpose code with a license to the client.

Which contract clauses matter most for getting paid?

Deemed acceptance, the right to suspend work for late payment, ownership that transfers only on full payment, and payment for work in progress on termination. Together they remove the client's ability to delay payment without consequence.

The four documents every agency signs, and the clauses that matter in each

Most agency owners treat contracts as a formality between the handshake and the kickoff. I did too, until a client stopped paying on a project where the contract said nothing about suspending work, nothing about who owned the half-built code, and nothing about what happened if they walked away. We finished the job to protect the relationship and collected about two thirds of the fee, eight months late.

Every clause in the templates on this site exists because its absence cost somebody money. Usually me.

Four documents, four jobs

You can run a services business on four contracts. Each has one job, and trouble starts when you ask one of them to do another’s.

The master services agreement holds the legal relationship: payment terms, intellectual property, confidentiality, warranties, liability, termination. You negotiate it once per client and then leave it alone. The master services agreement template is the longest document here and the one you will edit least.

The statement of work holds one project: deliverables, exclusions, assumptions, milestones, acceptance, fees, change control. It is short because the MSA already carries the legal weight. The statement of work template is where I would start if you only read one page in this section, because the SOW is the document you will write most often and the one that decides whether a project makes money.

The retainer agreement holds ongoing work: a monthly fee, a number of hours, what happens to the hours nobody used, and what counts as a separate project. The retainer agreement template covers the rollover and overage rules that keep a retainer from turning into unlimited support at a discount.

The consulting agreement holds advice. When the output is a recommendation and the client makes the decisions, you need a different allocation of risk, starting with a clear statement that you do not guarantee results. The consulting agreement template is written for a solo consultant or a small firm.

Some clients want one contract for one build, with no framework. That is a combined MSA and SOW, usually called a software development agreement. It works for a single project. The moment a second project appears, you will wish you had split them.

The clauses that matter in each

A fifteen-page contract has perhaps eight clauses that will ever affect your bank balance. The rest are worth having and rarely worth fighting over.

Document	The clause that protects you	What happens without it
MSA	Right to suspend work for late payment	You keep working for a client who has stopped paying
MSA	Liability capped at fees paid in the prior 12 months	One bad project can cost more than the client ever paid you
MSA	Payment for work in progress on termination	A client cancels mid-milestone and owes nothing for it
SOW	Out of scope list and assumptions	Every unstated expectation becomes your cost
SOW	Deemed acceptance	Silence from the client blocks your invoice indefinitely
SOW	Change control	Requests in meetings turn into free work
Retainer	Capped, expiring rollover	A client banks months of hours and spends them all at once
Consulting	No guarantee of results	You are blamed for a decision the client made

Four of these work together to get you paid: deemed acceptance, the right to suspend, ownership transferring on full payment, and payment for work in progress. If a client is already behind, the practical steps are in the guide to what to do when a client is not paying. The contract is what makes those steps available to you.

Scope protection lives almost entirely in the SOW. A vague deliverables list with no exclusions is the root of most scope creep, and no amount of project management fixes a document that never said where the work ended.

The clause that runs through all four

Every one of these documents has an intellectual property clause, and it is the one agencies get wrong most consistently. They get it wrong in the client’s favor.

The typical agency contract, often adapted from a template the client’s lawyer supplied, says that everything the agency creates during the engagement belongs to the client. All work product, all code, all of it. The agency signs because it sounds fair. The client paid for the work, so the client should own it.

Look at what is actually in a delivered codebase. Some of it was written for this client and nobody else: their business logic, their data model, their screens. A large share of the rest is code you brought with you or would have written for anyone. Your authentication module. Your deployment scripts. The component library you have refined across twenty projects. The admin scaffolding you start every build with.

An “everything belongs to the client” clause hands all of that over. Read literally, it means you need the client’s permission to use your own starter kit on the next project. Most agencies ignore this and carry on, in quiet breach of half their contracts.

The client never needed any of it. What a client needs is to run the software, change it, hand it to another vendor, and sell it along with the company. A broad license to your general-purpose code gives them every one of those rights. Ownership of your toolkit adds nothing to their position and removes a great deal from yours.

So every template here takes the same position:

The Client owns the Deliverables created specifically for it, on full payment. The Agency keeps its pre-existing and general-purpose materials and grants the Client a perpetual, royalty-free license to use them as part of the Deliverables.

The full reasoning, including what the law says when the contract is silent, is in who owns the code. The drafting detail, with wording for each variation a client might ask for, is in the guide to the IP clause in a software development contract. When a client worries about access to code it does not own outright, the usual answer is a source code escrow arrangement, which is cheaper for both sides than an argument about ownership.

There is a second reason to care. If you have kept your general-purpose code across ten years of projects, you are holding an asset. Most owners have never thought of their old repositories that way. I cover the idea in what your old code is worth.

How to use these templates

Start with the MSA and get it signed before the first project. Then write a SOW for each piece of work. Add the retainer agreement when a project turns into ongoing support, which is the natural moment because the warranty period is ending and the client is about to start asking for changes.

Read the clause notes that come with each download. They say what clients push back on and what I would concede.

Then have a lawyer in your state review your versions once. You pay for that review a single time, and you send the documents for years.