In the last post, I talked about how to make sure your projects are profitable for both your client and you. In my final installment of this series, I’ll show you how to articulate all of that to set you up for a successful relationship with your client. In other words, I’ll show you how to write a great contract.

Necessary disclaimer: I am not a lawyer, so none of this is legal advice. It’s only stories from my experience. I’m fortunate to have worked with my lawyer to evolve and iterate on my boilerplate agreements for over a decade. (If you’re looking for a great lawyer to work with on your freelance or agency business, look no further than Matt Sherlock.)

About contracts

Before we get into the details of a contract, I’d like to share some of my own ground rules around contracts.

First: what a contract is not. A contract is not a proposal. I’ve seen many freelancers and agencies treat a contract like a proposal, a way to provide a few options that a client can choose from. That’s not what a contract is for. Contracts should only contain obligations: what you’re obligated to do for your client and what are they obligated to do for you. The more “coulds” and “shoulds” you have in your contract, the more ambiguous and difficult to enforce it becomes. Shift the “coulds” and “shoulds” to “musts.”

Many treat contracts as a zero sum game: in order to get the most, your client has to lose the most. That’s the game that’s played: write a contract that incredibly one-sided, knowing that your client (or client’s lawyers) will negotiate it the other way, and eventually you’ll land close to the middle.

I think that’s garbage.

Why start a project with either you or your client feeling duped or even defensive? How do you expect to do a fun, collaborative project from there?

I always strive to write my contracts in a way that’s fair and just and benefits both them and me equally. I try to write contracts where I would agree to every clause if I was in their shoes and where they would agree to every clause if they were in my shoes. Many clients have said that they and their legal/procurement teams think my contract is the most balanced contract they’ve ever received, so they didn’t feel the need to redline much or anything at all. I think that’s a massive compliment that I’m immensely proud of.

The two reasons to have a contract

Every time you do work for a client, it’s generally a good idea to have a written contract between you. Most service providers know this, but they don’t always know why. From my experience, there are 2 main reasons to have a contract: accountability and risk mitigation. (A lawyer may reverse the order of those.)

One of my biggest reasons for having a contract is to articulate what we’re mutually agreeing to. If you’ve followed the steps I’ve suggested for a valuable sales process, you’ve had many conversations about the possibilities. That’s great at those stages, but now you have to converge all of those conversations from “here’s what we could do” to “here’s what we’re going to do.”

Contracts can be short, they can be long, or they can be somewhere in-between. Heralded design firm Segura has a famously short 13-line contract. This type of short agreement is incredibly seductive to the design business that wants to quickly get past the sales phase and get on to the project.

As Basecamp CEO Jason Fried points out in that article, “…there are many ways to do business. One way is working with clients you trust — people who appreciate this approach to work. And if you guessed wrong, and someone fucks you, rather than pursuing legal remedies which cost even more time, money, and hassle, there’s an alternative: Take your losses, wash your hands, and don’t work with them again.”

Which bring us to the second reason for having a contract: risk mitigation. Every project contains risk. The amount of risk you’re willing to carry is inversely proportional to the length of your agreement. If you can carry a large amount of risk, your contract can be short. If you aren’t willing or able to carry a large amount of risk, your contract probably needs to be longer.

Useful contracts answer the question “what do we do if {this specific situation} goes poorly?” in advance. Useful contracts outline the specific agreements you and your client are making, and the implication is that anything different that occurs is a breach, which is a fancy way of saying that the agreed-upon, binding terms have been violated or broken.

“A contract” usually means two contracts

In order to create a useful contract, a common practice is to actually have two separate agreements:

1. A General Services Agreement (also known as a Master Service Agreement or a Framework Agreement) that outlines the terms of every project you do with that client
2. A Statement of Work (also known as a Work Order), a shorter document that outlines the terms of a specific project that adds more detail and/or may differ from a term in your General Service Agreement.

Overall, we’d always insist that we use our agreements as a starting point, not our client’s agreements. Even though it sounds like I’m being a diva, it’s actually for a more practical reason that I’m happy to share with clients when they ask. I tell them that we’ve done thousands of projects like this, probably more than they have, so we have a better sense of what makes for a great project than they do. Especially if we’ve had a great probative conversation with them where they now see us as an expert and their preferred partner, this usually makes sense to them and they agree.

Let’s walk through each, clause-by-clause.

General Services Agreement

Our General Services Agreement has 29 clauses in it! Remember: this is the document that governs every project we do with a specific client, which sometimes lasts over several years. These 29 clauses are the non-negotiables that are table stakes for a project for us. Unless it’s tiny revisions on these, we typically don’t accept major reworkings or removals of anything in here. Clients that don’t agree to these are usually not a good fit for us to work with.

Here are the 29 clauses in my General Services Agreement and what they mean:

1. Services. They’re hiring us to perform services outlined in a separate document.
2. Fees. They’ll pay us the amount and on the dates we agree to in a separate document. We’ll make sure they approve any additional expenses before we incur them.
3. Term. This agreement stays in place for a year. For clients we worked with more than a year, we write up a small addendum to agree to extend that term, which is much easier than spinning up a whole new agreement.
4. Control of Services. We’ll work our way, not the client’s way.
5. Tool and Equipment. We’ll use our own equipment.
6. Relationship of the Parties. We’re an independent contractor.
7. Licenses and Permits. We’ll make sure to have any licenses or permits we need to complete the work.
8. Taxes. We’ll pay our own taxes.
9. Warranties. We promise to be professional, make good stuff for them, and not disparage them. They promise that everything they send to us is legitimate.
10. No Conflict of Interest. We might work for their direct competitors, but we promise that that won’t stop us from doing good work with and for them.
11. Pauses. They can pause the project anytime, but we can’t promise we’ll pick it back up when they’re ready. If they pause for over 60 days, we have every right to say the project is over and we can terminate.
12. Termination. Both of us can walk away at any time for any reason, as long as we give 30 days notice. If we do end the project, they’ll make sure we’re paid up for the work we’ve completed, and we’ll make sure they get all of the work we’ve done and the rights to it.
13. Publicity. We’re allowed to say they’re a client, but we won’t talk about the work unless they approve our ability to do so.
14. Consequential Damages. Both parties will only be responsible for direct damages if this agreement is breached.
15. Insurance. The type of business insurance we carry for clients.
16. Force Majeure. What we do about events beyond our reasonable control.
17. Indemnification. If we do certain things wrong, we’ll be responsible for making it up to the injured third party. You agree to do the same for us.
18. Ownership. This is a big one. Most clients want their service providers to do “work for hire,” which is a fancy way to say that they own the work as soon as we create it. I don’t like it because I think we give up too much leverage here. We instead say our clients own the work as they pay for it, not sooner. If they pay for 50% of the project, they own 50% of the work. The only time they own all of the work is when they’ve paid in full.
19. Confidential Information. We’ll keep their secrets as long as they tell us they’re secret, and we’ll expect them to do the same for us.
20. Limitation of Liability. We’re not liable for anything more than they’ve paid us in the last year of working together.
21. Trademarks. We’ll only use their trademarks with their permission, which they’ll grant unless they have a good reason not to.
22. Assignment. We won’t assign this Agreement to anyone else without their consent.
23. Notices. Notices must be sent by mail or email to the address specified.
24. Compliance with Laws. We, um, follow the law.
25. Entire Agreement. If we change this Agreement, it must be in writing. Everything we agreed to do is in this document and its attachments.
26. Governing Law. This document should be interpreted using a specific locality law. Because our lawyer was in Pennsylvania, we started by stating Pennsylvania courts as the venue for any disputes. Many clients prefer to change this to the state of their lawyers, so we deferred to our lawyer about which state laws he was comfortable with.
27. Headings. Because we include plain-text explanations with the legalese, we made sure to say it’s added for convenience, not to change interpretation.
28. Severability. If a court determines that any portion of this Agreement is unenforceable, that part will be removed and the rest of the Agreement will remain intact.
29. Execution in Counterparts. If we sign separate copies of this Agreement, including electronic copies, that’s still a valid contract.

Phew! That’s a lot of clauses. A lot of these are in our contract because we’ve gotten burned before by not having them. You may not need all of these specific clauses in your contract, but learn from your past projects and add clauses that help you ensure your most common good things happen and the most common bad things don’t.

Statement of Work

The Statement of Work (SOW) is a shorter agreement that outlines the specific terms of a specific project. Here are the 13 clauses in my standard Statement of Work:

1. Project Name.
2. Key Outcomes. This is an important section. This isn’t a list of services or deliverables; that comes later. I use this section to bring some of the language about the outcomes the client wants to realize from our previous value conversations into the actual agreement we’re now making. That’s usually phrases that include some kind of “change” language, like “increased design system usage for more designers across the organization” or “less time spent on content entry by executives.” These aren’t guarantees, but they are obligations that our team promises to work toward. These are the basis of the project. If these outcomes change, the project—and the timeline and the price—changes. But even in the services and deliverables change but the outcomes stay the same, we’re still in scope.
3. Services. A list of services we’ll perform. Those are generally things like “copywriting” or “user interface design.”
4. Deliverables. A list of deliverables we’ll give to the client throughout the course of the project. Those are things like roadmap documents, creative briefs, web pages, animation exports, and more.
5. Client Materials. A list of the things the client will give us. Those might be brand assets, access to a particular team, access to certain repositories and files, etc.
6. Work Plan. This is a general project plan in sequence that includes estimated start dates and end dates. The most unique thing here is probably the column entitled “Project value.” For every item in the Work Plan, we assign a percentage value in relation to the project. For example, the kickoff might be worth 5% of the project while the first round of design might be worth 10%. It’s completely subjective, but it’s worth documenting. This becomes incredibly useful in the case of termination. Let’s say your client’s funding gets cut and they have to stop the project part of the way through. How much do they owe you? With assigned project values, you can add them up to determine that you’ve completed 36% of the project already and therefore are owed 36% of the total fee.
7. Termination of SOW. There’s a termination clause in the GSA already (section 12), but the one here adds some detail about what I just described above.
8. Project Cadence and Feedback Process. This states what cadence we expect our client’s feedback in. This example says 3 days, but we changed this from client to client depending on their culture and the pace of the project.
9. Scope and Term. Another very important one. Our client’s aren’t paying a time-based rate, but we’re also not working indefinitely. Based on the Work Plan, we give an amount of cushion to allow for the fact that it’s hard to keep complex projects on a strict timeline. We’ll pick some reasonable amount of cushion—like an extra month on top of a 4-month project—that we’re happy to flex out to. But, if the project hits that date, we have to be finished, even if we’re not done the work. In order to extend the time, they’ll have to pay us at a time-based rate determined by the value of the project. For example, if we’re doing a $40k project (determined in the value conversation) that we’ve estimated to take 4 months, we effectively have $10k monthly rate. If the client wants to extend another month on top of the extra month we’ve already given them, that’s the price we start at.
10. Payment Terms. Outlining the expectations of when we’ll get paid. The typical way we do this is to get 50% up front and then amortize the remaining balance across the remaining time of the project. For example, if we’re doing a $100k project that we’ve estimated to take 6 months, we’ll specify $50k as the first payment, then $10k on the 1st of the month for each of the remaining 5 months. It’s important for every business to be able to manage cashflow. That’s why we always specify a date that we expect payment and never upon delivery of a particular deliverable.
11. Key Personnel and Key Positions. We always commit the people who will be leading specific efforts on our end and ask the same of our clients. Without that, it’s difficult to create obligation and have accountability.
12. Fee Exclusions. A standard clause to say we’re only charging them for our expertise, attention, and effort. Any other materials will be acquired and billed separately upon their approval.
13. Effective Date. A standard clause to outline that the SOW becomes effective once it’s signed by everyone.

Preparing, framing, and delivering contracts

As you’ve probably gathered from the previous articles in this series, this is a lot of work to do before the project even starts! I’m a big believer in the fact that getting this stuff right makes the project go smoothly, and not getting it right is the leading cause of poor projects.

The audiences for a contract

I always walk through the agreements with my main client. Maybe not the General Service Agreement, at least not in its entirety, but definitely the Statement of Work. I want to make sure they understand the nuances enclosed and also see the things we’ve talked about in previous conversations memorialized in the agreement we’re about to sign. If we haven’t gotten the Key Outcomes clause (section 2) right, I might go a few rounds of back and forth with them to dial that in. This process, though laborious, has the added benefit of showing them the type of collaboration we’ll have during the project before we even start. Clients who hate that would hate working with us, and clients who are great collaborators here turn out to be great collaborators during the project too.

The other big reason to go over the SOW (and pieces of the GSA) with your main client is that they may not be the primary audience for the contract, especially at a larger company. It might be their boss that’s signing. It’s also likely the legal and/or procurement teams that have to be on board. Because of that, the client is your main advocate; that’s why it’s important that they feel like it’s as much their contract as yours. If they’ve co-authored it, they’ll be able to go to bat for it—and you—much more effectively.

The aesthetics of a contract

As a designer, I want all of my documents to look good. Branded contracts, invoice documents, and the like are things that designers are proud to make in order to put forward a cohesive brand. Generally, this kind of attention to detail also helps build subconscious trust from your client that they’re hiring a competent design professional that sweats the small stuff.

I’ve learned that contracts are an exception to this rule.

I used to have branded contracts that use beautiful typefaces and pristine hierarchy, but in the last decade, I’ve learned that contracts written in Google Docs, Microsoft Word, or Pages set in Times New Roman at 12pt get the job done better. Functionally, it’s easier to add comments and make redlines to a DOCX file than a beautiful design exported to PDF. I’ve also learned that the visual language of a Times New Roman doc is more familiar to someone in legal or procurement. Beautiful typefaces and simple English impress people looking to buy good, simple design, but it makes someone from legal think you’re an amateur. Sending them a doc that both looks and sounds like something they’re familiar with is a better way to get them on board, which is the real job of a contract. So, put away that Indesign or Illustrator template and think of Bold, Italic, and spacing as your only design tools here.

In summary

To round it all out:

• Attract the right clients who already trust you and would kill to work with you before you even have the first conversation.
• Have the right conversations with your prospects to multiply the trust they already have in you exponentially.
• Make sure the projects you’re architecting are profitable for both your client and you—in that order.
• Capture all of that in contracts that make your client—and their procurement department—champing at the bit to send the first payment and get started.

Now the table is set properly for you to do the best work of your life.

That brings us to the end of this series! I hope you’ve enjoyed and learned something from the way I set up my projects. This was the first big series I’ve done in my newsletter. Did you like it? Should I do more series? Should I write more of this series? What would you like me to write about next? Reply and let me know.

Join 57,400+ subscribers to the weekly Dan Mall Teaches newsletter. I promise to keep my communication light and valuable!