Are we doing freelance contracts all wrong?
The best contracts are the ones you never have to enforce
I’m frequently asked about how I handle freelance contracts with my design clients. How I outline payment terms, timeframes, deliverables, and what happens of it all goes sideways?
I don’t spend much time thinking about it, because I can’t remember the last time I had a bad client, and I don’t recall ever having to enforce a contract in my life. That probably makes me lucky, but I think it’s also because I work smart, always meet or exceed expectations, and choose clients carefully.
But despite this, I use contracts. Most of my new freelance clients, over the past 17 years, have signed some kind of formal agreement before we began our project together. For as long as I can remember I’ve used a lightly customised, generic, digital design contract template I downloaded about 10 years ago, and barely gave a second thought as to what it says.
But lately I’ve been questioning the value of this type of contract, and have transitioned to using a much simpler, less formal, plain-language agreement with my clients.
They love it, as do I.
It’s made me realise how archaic my old contract was. Chances are your contract has many of the same flaws.
What a contract shouldn’t be
When I think of a contract a few things come to mind. It’s usually dense and difficult to read, stuffed full of legal jargon that makes little sense to a common business person. It’s got formal definitions of who is the provider and the customer. It usually outlines a list of if/then statements that define what happens if either party fails to meet their obligations.
For example, if the customer fails to pay within 30 days, the provider may charge 5% interest. If the provider fails to deliver by so-and-so date, the customer may withhold payment, etc. And it talks about how and when a contract could be cancelled by either party.
It feels like most of the contract outlines what could go wrong, rather than what we want to go right.
I think of my clients as partners, with a shared interest in reaching their business goals with the application of good design. A contract that starts off in that confrontational tone does not feel like the way I want to begin a relationship with a new client-partner.
So I’ve dropped all the penalties. Not a single mention of what happens if I don’t deliver, because I never fail to deliver. Not a word about what happens when they refuse to pay on time, because that thought doesn’t cross the minds of the type of clients I work with.
Partly, that’s because I only work with good clients. I’ve built up that privilege after 17 years of building a strong reputation and high demand. We trust and value each other, so it’s in both of our best interests not to muck up the relationship.
You learn to recognise the red flags and avoid working with clients who may be problematic later. And when you think about it, those problematic clients are the only ones you need contracts with. If you only work with good clients, do you need a contract at all?
How I structure my agreements
Firstly I don’t call them contracts. They’re “agreements”. Contracts are too stuffy and confrontational. Agreements are friendly and open.
I present my agreements as plain Google docs. I want my client to feel that it’s a fluid, collaborative document that they can help shape through their feedback. Not something too polished and official that they need to pay their lawyer to review.
I don’t lead off with any dense definitions or general legal terms. I get straight to the important points: what I’ll do for them, when I’ll do it, and what it will cost.
And most importantly, my agreements are in plain language. Just like the voice I’m speaking to you in now. Polite, professional, and straight up.
Here’s an outline of what I commonly include in my freelance design agreements:
- Who it’s from and who it’s for.
Example: prepared by Benek Lisefski for Bob Widgetburger — 1 October 2018
- Contract length — how long is the project expected to take? This may be a fixed, pre-determined length with a specific deadline — or for longer projects, I may provide an estimated range.
Example: 1 Oct — 16 Nov (7 weeks).
- Responsibilities — what kinds of tasks will I be expected to do during this engagement?
Example: web UX wireframes, UI design, and front-end coding.
- Deliverables — what will the end product be? What kind of work and files will I hand off when the job is complete?
Example: Designs presented for feedback as PNG previews in InVision. Final designs delivered as source Sketch files. Interaction styleguide and responsive design guide will also be provided.
- Workload — How much of my time am I committing to this project? I usually define this as hour per week. Read more about how I balance my schedule and workloads to prevent the freelance rollercoaster.
Example: I can guarantee a minimum of 10 hours per week, and as much as 15 hours per week.
- Retainer (optional) — If I’m working on a retainer, this defines how many hours per week are included in the weekly retainer rate.
Example: You’ll have 10–12 hours per week for my base weekly rate. Any hours above 12 per week will be billed as overage.
- Cost — if I’m working on a weekly retainer this is a weekly rate, plus an indication of the hourly rate for overage above retainer limits. If I’m charging by the hour, it is a simple hourly rate with an estimated total price range. For more on how I price, see Does value-based pricing live up to the hype.
Example: project rate $1,500 per week + GST. ($10,500 + GST for the 7 week duration of the project.) Overage above 12 hours per week will be billed at $130 per hour + GST. You’ll get a weekly retainer time updates so their are no nasty overage surprises.
- Feedback expectations— I let my clients know that the speed of their feedback has a massive effect on the efficiency and momentum of the project.
Example: To maintain project momentum and weekly target hours we must work together to make the workload as balanced and consistent as possible, and the feedback/revision cycle moves without delays. This requires design feedback within 24 hours or less, unless a different arrangement is previously agreed.
- Deposit & billing terms — I always require a deposit payment for new client’s I haven’t worked with before. Nothing proves a clients is serious like a quick deposit payment. I bill monthly and require prompt payment.
Example: A project deposit equal to 1 week’s rate ($1,500) is due before project commencement. I will bill monthly for the duration of the project with each payment due the 20th of the following month.
- Expenses — I let my client know what extra expenses may arise which are additional costs that may be passed on to them.
Example: Any creative expenses that should arise, such as font licenses or stock imagery, will be at client’s expense, to be discussed and agreed upon before purchase.
- Meeting time — I make it clear that any meetings (beyond our free initial meet & greet, which probably already happened) are billed just like the rest of my time. Long phone/video calls count too.
Example: All time spent in meetings or other extended communication will count towards our weekly retained hours. For meetings outside Auckland, client will pay for all transportation and accommodation expenses required.
- Credit & sharing — I’m always clear on where, when, and how I might share the creative work we produce during this project.
Example: I reserve the right to share any and all design work I produce for my own promotional purposes, including but not limited to publishing it on my own portfolio website, Dribbble, and Behance. I will not share design work until it’s live and publicly visible, unless I have your previous permission to do so.
That’s it! No jargon, fluff, or terms. No numbered clauses, and no formal signature page. My client usually replies back with a quick “yes that all sounds good” and we’re ready to begin.
But, but, what if something goes wrong?
Maybe you have a sneaky client who doesn’t show any of the usual red flags, and they surprise you to become a pain in the ass later. Maybe they are unhappy with your work and refuse to pay. Now you’re stuck not knowing your legal recourse because you didn’t have contract terms that define what to do in this situation.
That could happen.
But it won’t.
Because you’re not going to deliver less than satisfactory work, are you? If that’s a possibility, sort out your quality control process first before you worry about the wording of your contract.
And even if they did refuse to pay or otherwise decide to act inappropriately, your local consumer laws usually give you some recourse to recover those payments based on the casual agreement you did have, even if it didn’t explicitly define non-payment terms. (Please check with a local lawyer to confirm the extent of this, as it varies between countries and states).
If using this more casual agreement is a risk, it’s one I’m gladly willing to take. (People like Kevin recommend not using a contract at all!)
Every part of your client interaction adds or detracts from their overall experience. If starting off our relationship with an agreement that’s a lot less “contracty” makes their experience better, then it’s actually helping to turn that client into an easy and trusting partner.
When you build that partnership, a contract becomes obsolete.
Want to comment?See this story on Medium
Hi, I'm Benek Lisefski. Since 2001 I've run my own independent design business. Join me as I unfold 18 years of freelance business knowledge: honest advice and practical tips to help you take your indie career from good to great.
MediumTop writer in Design, Business, and Entrepreneurship.