DesignTalk Ep. 66: Freelance contracts 101—mistakes and best practices from 40k freelancers

– [Margaret] I’m Margaret Kelsey, and this is the 66th
episode of DesignTalks, a webinar series brought
to you by InVision. Today, Matt Brown discusses
mistakes and best practices of freelance design contracts. Let’s listen in. – [Matt] Awesome, well thanks so much for having me on the webinar. Really excited, been looking
forward to this for a while, so yeah, excited to be here. We’ll dive right in. Just by way of introduction,
I’m a former freelancer myself, and now co-founder of Bonsai. Bonsai’s a workflow automation
tool for freelancers, so you can go from proposal,
to contract, to payment, with minimal time, and Bonsai automates as
much of that as possible, and we bake in best practices and different parts of that
process for freelancers, and it’s kind of the typical
story starting Bonsai. Bonsai is what I wish I
had when I freelancing, and it kind of started almost
as a collection of tips that I’d give out to people
who came to me and asked, “Oh, how do I get started freelancing?” or, “How do I do X, Y, or Z
as it relates to freelancing?” The first product we launched with Bonsai also happened to be the
largest collection of tips and where I’d spend most of my
time talking to people about, which was in the contracts that they had. So, “How do I read a contract? “Why do I need a contract? “What do I put in there? “How do I…” All the questions around contracts. So we started with that
kind of product in Bonsai, and I still see it as one
of our most important things and where I spend a lot of my time, because I think it’s
the most important part, and the most misunderstood, and misused, I think, part of a lot of freelancers’ processes. So yeah, excited to
share what we’ve learned. Quick, quick disclaimer
before we jump in, though. This is important. Bonsai is not your lawyer. I’m not your lawyer. We can talk about general best
practices and all of that, but laws by country vary quite a bit. You may have things that are particular to the type of work that you’re doing, or the clients that you work with, so any specific questions, definitely recommend that you get a lawyer and talk through them, and we’ll talk about that a
bit later in the talk here. In terms of agenda,
pretty straightforward. Gonna go through why you need a contract, why that’s important. Gonna go through some common mistakes that we see in creating contracts, common pitfalls, and how to avoid those. Talk about some pro
tips that we’ve learned how to integrate contracts
into your overall process without it slowing you down, and still giving you the protection and professional patina
of using contracts, and then talk about some resources, and finally we’ll leave some
time at the end for questions. So to dive right in:
why you need a contract. If there’s anything you
take away from this talk, the most important thing, I’d say, is contracts are just tools. A lot of people think of contracts, they start thinking of contracts
as these 50-page documents full of words, like, having
all these Latin words, and complex things, and clause 5.7, and all this confusing stuff. Contracts don’t need to be like that, and we’ll talk about that in a second, but put that out of your head, and just think about contracts as tools for setting very clear expectations between you and the client, and they’re the basis for
structuring that relationship between you and the client. They define what the
client expects you to do and what you expect the client to do. And this kind of leads
to one of the bigger… I think changing your
understanding here leads to one of correct one of the biggest
misunderstandings of contracts. A lot of freelancers see contracts as something that they grudgingly do. It’s like a checkbox and they just sign the contract, whatever, and they get on with their work, and then they think of
contracts as this thing that, if the client is bad, or something happens
and they don’t get paid, they’ll use the contract to come back and sue the
client or something like that. If you have to use a contract
to really threaten a client or something like that, a lot of times it’s
unfortunately too late, and kind of paradoxically, the way that contracts are most powerful is actually avoiding that process, or avoiding that outcome
before it even happens. So in making the structure of the project that you’re doing clear, and setting clear expectations in forcing the client to
explicitly agree to those things, you not only avoid a
lot of potential issues, but you also, in my experience, screen out a lot of bad clients. Nothing is 100% foolproof. Nothing is gonna avoid late or
non-payment 100% of the time. Nothing’s gonna help you
find the perfect client 100% of the time, but again, what I’ve found, and what I’ve seen with Bonsai as well is, having a clear contract correlates much more with
a successful project, and getting paid on time, and positive reviews on both sides. Some of the benefits. We’ve kind of already talked about this, but the benefits of having contracts. Making sure that
everybody’s on the same page about the project. There’s a lot of different elements, even if it’s just a
quick one-week project, or whatever it is, a lot
of different elements, when you get paid, how
you get paid, how many and we’ll go into all
these different terms, but there’s just a lot of different things that you don’t think about, and if you don’t make them
explicit with the client, you may have one perception, and the client will
have another perception. The contract just makes sure all those thousand little things that you may not think about or vocalize to every single
client, it’s made explicit. It also does help prevent non-payment, but again, it’s not as much of, you take this contract and you go sue the client after the case, it’s actually a dispute prevention. It’s not for dispute resolution, it’s more for dispute
prevention before the fact. And then again, in very
worst-case scenarios, absolutely you do have
something agreed upon, and if worse comes to worst,
you do have the contract, but again, I don’t think
that’s the primary way to think about the benefit of a contract. There are some indirect benefits to having a contract as well. Like we talked about, you’ll
help screen bad clients, or clients that are not as
serious about working with you. They’ll be turned off by working with by singing a contract. It also provides structure and
organization to your project. This is one kind of meta-skill that I learned quite early on, and I think it’s super
valuable in freelancing, is having a process for your projects. You don’t wanna have to reinvent the wheel every single time. You wanna have a template
for your proposals. You wanna have a template
for your projects. You wanna understand who are the types of
clients that you go after, and have as much of that
as possible streamlined so you can spend less time on it, you increase your close rate with clients, you either can spend
more time on your work, or just have more free time. So having a contract, I think, is really the foundation of
that structure for your project, and setting a template
for the work that you do. And then lastly, as it
relates to all of this, having a contract just makes
you look more professional. I think a lot of people, it’s certainly a change in perception, but if you think of
yourself as a real business, which you are as a freelancer, you know, real businesses send, when they do a business transaction, they send contracts back and forth, and there are a lot of
other things you can here. You can incorporate as an
LLC, or whatever it is, but even if you’re just
a solo practitioner, you don’t have an LLC
or anything like that, sending a contract that shows that you know what you’re talking about, you know what you want
out of the relationship, and you show what is gonna
happen in different scenarios, really makes you seem more professional to the clients themselves. So let’s dive into some common mistakes that we’ve seen with contracts. Because contracts are the initial step, in a lot of cases, with projects, the mistakes trickle down into the whole rest of the project, so a lot of them have to do with payment, and lot of them have to do
with terms and scope creep. But again, that’s why I think
contracts are so important. They really do set the
tone, and the stage, and the structure,
however you wanna say it, for the whole rest of the project. So in terms of first mistake, just talking about deliverables. A lot of people have different definitions of what a contract is. It can be just a handshake agreement. It can be e-mails going back and forth if you’re hired through one
of the online marketplaces. It can be just a project description. I would recommend using
a contract template that you find online, and we’ll give you some
resources at the end, but one of the first things
in all of those contracts is describing the work that you’re doing. And I would say there, being
as explicit as possible about the work that you’re doing. One guideline that I like to give is, when describing what you’re doing, write 25% more than you
think that you need to, just put on your writer’s
hat for a second, and just go to town and
explain what you’re gonna do like you’re explaining to a five-year-old, or a 10-your-old, or whatever it is, and actually that’s the level of detail, in a lot of cases, that you need. You can edit it afterwards, but really be explicit
about what you want, ’cause again, a lot of times… This is your craft. You’re doing something that
you know super, super well, and you’re working with another individual who probably doesn’t have
as much experience as you do in what they’re doing. They have an idea of what
the outcome they would like. They know that they want a logo, or they know they want
mock-ups, or whatever it is, but they don’t know about the process, they don’t know about
how much time it takes to do certain things, so you being very, very
explicit about that, and often the statement of work is at the top of the contract, so it really helps to be
very explicit about that. Two things related to that. One is including the number of, depending on the type
of project you’re doing, the number of revisions, or being as explicit as possible, quantifying the work that
you’re gonna be doing, the number of screens that
you’re gonna do, or whatever, helps you set these stops
on the number of revisions, or the number of times you’ll go back and forth on something. And then lastly, this
is one of those things where having a template helps you not have to reinvent the wheel every time, ’cause you’ll think about
all these little things, but what happens if you go
beyond those number of revisions? How do you charge the client? I’ve seen a lot of freelancers
actually have a higher rate for revisions right
after they do a project, because you want to incentivize the client to stay within the scope of the project, and you’ve probably already booked work right after that project, and so taking on that additional
work from the scope creep is gonna impact your workload, and so you wanna price
appropriately for that. So again, just thinking through
all of these things before. Having a process, having a workflow, and having your contract be the first step of the foundation of
that is super important. Mistake number two we see, being overly flexible on payments. This is often, especially
for new freelancers, kind of a difficult lesson to learn, because you’re, a lot of
times, at least I did, and I know a lot of freelancers as well, come into this doing freelancing, doing a craft that they love. You really enjoy designing,
you really enjoy writing code, and so the fact that
somebody’s gonna pay you for it is awesome, like that’s crazy that
somebody’s gonna give you money to do something that
you already like to do. And so you almost have this
guilt, or whatever it is, like you almost feel
dirty asking for money for this thing that you like to do, and you learn over time
to increase your rates, and to price yourself on market, but still, people just have this concern about talking about money, or being very explicit about money, but again, that’s what a contract is for, and that’s why having this
piece of serious-looking paper written down with all
these different terms, and having a template for
that is super important. In thinking about all
the different scenarios that could happen, you know, what happens if the client cancels the
project midway through? What happens if they’re not happy with it? What happens if, as we talked
about in the previous slide, there’s scope creep? All these different things. One thing that we’ve seen to be quite beneficial in contracts, to reduce, number one, reduce scope creep, number two, reduce payment disputes, is billing in milestones
as much as possible, breaking it up. Because it relates the
progress that you’re making to the payments that the client is making, so you’re not gonna
lock yourself in a room, and work for five months, and then come back and then
have 100% of your payment hinging on the client
accepting or rejecting that X months of work. Whereas billing on a milestone basis, and checking in frequently, and having those check-ins tied to the client releasing funds, we’ve seen to correlate with fewer disputes and happier clients. Just like the clients who are
more likely to sign contracts are the ones who are more
likely to be good clients, the clients who are more likely to be open to billing in milestones, and having payment terms very explicit, also correlate with them
being good clients as well. It relates to the second point as well, including penalties for late payment. This can seem harsh, or
this can seem greedy, or whatever it is, but again, you’re a
business, they’re a business, and good clients don’t, or at least they shouldn’t
fear penalty clauses, because you’re agreeing upfront, “I’m gonna do this, you’re gonna do this, “and I’m running a business and
I need to get paid on time.” You can include something in there like you have the right to
waive late payment clauses or whatever it is, but again, including that in there gives you another reason
to talk to the client at each milestone and ensure
that you’re paid on time. And then the last point,
on actual payment terms, and how frequently you get paid, or how long it takes between
when you submit an invoice and when the payment’s received, this is another thing that, you know, it’s one of the million things that can fall through the cracks in a process like starting a new project, but unless you have a contract, unless you have to enter these terms, unless you have to ask the client what their payment process is like, the client may work for
a big company where, you know, we’ve seen
net 60 or net 90 terms, which means you don’t get
paid until three months after you submit your invoice, and the client has no idea, ’cause their payments
department handles this, and you assume that you’ve
worked with most clients who pay you within two weeks or whatever, and then when it comes time to get paid, you’re having to wait one, or two, or three months longer
than you normally wait for that payment, and it really
will mess up your budget. So again, just another example
of how using a contract as a structure for the entire project, and it forcing you to be explicit about these certain things upfront, can save you a lot of headache and potential issues down the road. Again, it’s contracts are just tools for being explicit about different things, and you should be building a process to gather that information from the client before the project starts, and get rid of all the
ambiguity around projects. Already talked about this a
bit in the previous slide, but setting clear milestones that correspond to different
points in the project setting milestones, or
having some payment upfront, or breaking it up, at least what I’ve seen is that it breaks a psychological
barrier with the client. Them signing a contract, whether it’s paying
some kind of a deposit, or paying some kind of a milestone after the first week of work, it’s just kind of that first step, and the fact that they
signed this contract, and they’re paying you. Not only does it signal, obviously, that they’re serious and
ready to work with you, but we’ve seen it correlate
with better relationships if you break the project
up into milestones, and have those milestones be clear, agreed upon with the client upfront, this is, depending on how
your own process works, part of this can be done in a proposal, which oftentimes occurs
before the contract step or in parallel with the contract step. You have to figure out here how contracts will fit
with your own process. Kind of a side note here:
some freelancers we see who send proposals and
contracts side by side, or you accept a proposal and then the contract is there next to it, some people just agree to
high-level terms over e-mail or whatever it is, and then send a contract
in lieu of a proposal, but the contract’s relatively
straightforward and simple. So think about how it
adapts to your own process, but I would say don’t
substitute a proposal for what should really be a
more explicit legal contract. And then coming back from that digression, don’t, as far as milestones go, obviously don’t continue work until previous milestones are paid and you agreed to go on to the next step. You can have different provisions in there for how far you’ll go, or
how much work you’ll do until you stop because the
previous milestone isn’t paid. Again, this is a nice way
to set clear expectations on what you’re gonna do and
not going to do upfront. Mistake number four. This is a big one, and again,
a very complex subject, so this is why I say talk to a lawyer, and get advice on your specific country, your specific state in some cases, and the type of work you’re doing, and the clients you’re working with. Intellectual property is
quite a complex topic. One thing I’ll say is, and this gets into what we
mentioned at the beginning, where if the project is big enough, and the client is really
doing wrong by you, and takes your work and doesn’t
pay you or whatever it is, a lot of times it’s actually the
intellectual property clauses that can help you here, where making it clear
that you own the work until you’re paid in full for it. So if you do a couple
of rounds of revisions, and then the client pays you
part of it but not all of it, and takes the work that you’ve done, and is using it commercially, if you have a strong intellectual property ownership
clause in your contract, the case that you have against the client, that’s really what that’s gonna hinge on. Being clear on what that is
and how it relates to payment, and different steps in the
contract is very important. Depending on the type of work you do, if you’re doing design and
you’re using third-party assets, if you’re doing development,
you’re using open-source code, there are a lot of
different edge cases here, so that’s why I say it’s worth it for you to spend an
hour talking to a lawyer who is in your country and knows the laws, knows your business, or at least knows the type of
work that you’re doing well, and can give you guidance on that. But ultimately, I think
the most important thing is tie ownership in intellectual property, however you wanna do it ultimately, to compensation, so you’re not giving that away
before you get your funds. And then the last thing I’ll say on intellectual property is, depending on the type of work you do, you probably want to make
explicit as well portfolio rights, so you having the ability to exhibit, maybe you can’t use the client’s name, maybe you can’t show their
logo or whatever it is, but you being able to talk
about, or use in some way the work that you do in your portfolio. That’s another thing that you
may just assume that is okay, and then the client has
their own perspective on it, or maybe their legal team
says default no to it, so you having that
explicit in the contract, making sure the client agrees
to it every single time shows the importance as
one of the million things that can slip through the cracks when you’re starting a new project. And then some pro tips to wrap up here. We’re kind of getting to the end. Clarity and conciseness is the
thing that makes contracts, I think, successful. It’s the thing that makes
them easier to write. It’s easier to digest. If you create this 50-page
monster of a document and send it to a client, the client’s probably
not gonna read all of it, you’re probably not gonna read all of it, you’re probably not gonna
understand what it says, and that’s almost just as bad
as having no contract at all, to be honest. So really paring down your contract to be as concise as possible. It is a balance. You need to be as concise as possible, not having a bunch of
unnecessary clauses and all that, but at the same time cover
all the important points of your business, so that’s why you should,
number one, have a template, and number two, think of that template as this evolving, living document. When I was freelancing, and before Bonsai, after every single project, I would say, “Okay, well here’s
something that went right. “Here’s something that went wrong. “Here’s something that I
wish went differently,” and in addition to changing my process, I’d actually go back and
change the contract as well, and say, “Oh well, I forgot
to include portfolio rights,” or, “the client was asking
for this weird thing “about portfolio rights, “or how I could say this but not that, “so I should make it clear “that I can use their
name in the portfolio,” or whatever it is. Don’t think of the contract as this thing that you just save in your drop box and reuse every single time. Actually, after each project, think about how it can be improved. One of the reasons why
we started Bonsai is we have the learnings
of all these different tens of thousands of projects, and so we can update our templates, which propagate out to everybody. In your templates, if you
create your own templates, don’t be afraid to use simple language. There’s no law that says
contracts are only valid if you use all these fancy
words, and whatever it is. Simple language is often better than not. Contracts are actually very simple. It’s something that’s clearly spelled out that two people explicitly agree to. There have been cases where a contract has been as simple as somebody saying something in an e-mail and sending it to somebody, and the other person
responding to it and agreeing. I wouldn’t recommend doing that, but as long as you say something, the other person agrees to it, that, in some ways, is a contract. Don’t feel like you need to
use all these fancy words, and terminology, and blah-blah-blah. It’s really just about being clear, and you and the client
being on the same page. Lastly, I would say, using bullet points, using numbers, using dates, being as specific about that as possible, not over-branding the contract. There are times and places for that. The proposal, obviously
you can customize that and be as visual as you’d like. You can be as visual on
invoices and all that, but I think that the contract is a place to be relatively straightforward and focus on what’s being agreed to. And then lastly, one thing that, just more from a process standpoint, sometimes I’ve seen
freelancers attach NDAs, or at different points in the process. A lot of times you can
actually include NDA terms in the contract itself, unless the client is giving you some material beforehand
to sign, or whatever it is, or to look at before you accept a project, there’s no need to have a
totally separate contract there for the NDA, and more work, more things to sign is more friction that
can gunk up your process. Think about how this applies to your own process particularly, but often it’s not necessary to have a bunch of different things there. Just to wrap up here, kind
of summary, takeaway slides. Contracts are tools for
setting clear expectation, they’re not these scary,
long, legal documents, they’re a reflection of your process, which should be being very
clear with the client upfront about what you’re gonna do,
and what they’re gonna do, and what’s gonna happen
in different scenarios. The contract should have simple
language and explicit terms. You don’t have to have all
these complicated words and blah-blah-blah, just be very clear about
what’s gonna happen in different scenarios. Use a contract for every single project, which, I know, if you’re
doing a lot of projects you have a high-velocity
type of work that you do, that can be burdensome, but that’s where having a template, having a process helps. Thinking of your contract as
the foundation of this process, like when I get a new
client I do A, B, C, D, and the contract is the basis for that, I think really helps
not only save you time, and reduces your mental burden
in working with new clients, but reduces the things that can go wrong. There’s a great book that
I read a few years ago, Checklist Manifesto,
and it talks about how, basically, having checklists, or having these steps that you go through. Airline pilots start the plane, they follow this thing
to turn on the engines, they follow these clear steps to do this, and when something goes wrong
they follow a set of steps. That’s the way that I
think about contracts. They’re your checklist for starting a new project with a client, and whether the project’s large or small, again, you don’t wanna forget to get your intellectual property rights, you don’t wanna forget to be explicit about what happens about
payments and all that. So again, if you take anything
away from this webinar, I think it’d be not thinking of contracts as these annoying, old-school,
ineffectual documents, but really as the foundation for a process that helps you run your business better. And with that I’ve wrapped up, was talking a little fast, so hopefully you guys got all that. – [Margaret] Perfect. Awesome. So I think that that’s the
time that we have for today. So Matt, thank you so
much for chatting with us and sharing your knowledge, and a big thank you to
everyone on the line today. I hope you have a great rest of your day, and keep freelance-designing
awesome things. – [Matt] Awesome. Thanks
so much for joining us.

Add a Comment

Your email address will not be published. Required fields are marked *