Freelance contracts: A cautionary tale
When it comes to freelance programming or design work, you need a proper contract. But don't let the legalese stand in the way of getting the job done.
By Donald Ritchie
Photo: Ian Britton (FreeFoto.com)
Whenever the conversation turns to the subject of freelance contracts, I like to tell a cautionary tale. It concerns a friend of mine - a software manager for a small service company in the American Mid West.
My friend wanted to outsource a web development project. He found a local firm - a two-person business - which was able to take on the job. He met with the developers, discussed the requirements, and agreed a price.
Before starting work, the developers sent my friend two copies of their standard contract. It seems that, when they set up their company a couple of years earlier, they asked an attorney to draw up a contract that they would be able to use for all their projects. It was this contract that the developers sent to my friend.
There was nothing particularly onerous about the contract. It covered all the usual issues: invoicing, payment, non-disclosure, settlement of disputes, and so forth. But it was set out in fairly small print, and was expressed in the sort of closely-worded language that lawyers love.
When my friend received the contract, he did what many managers in his position would do: He sent it to his company's attorney for advice. The attorney did what you would expect a competent lawyer to do: He scrutinized the wording, then reported back to his client with a list of comments and queries.
The client sent the list to the developers. The developers, wishing to be cautious, sent it to their attorney. The attorney commented on the comments, and drew up some suggested amendments for consideration, which he sent back to the developers, who sent them to my friend.
A modified version of the contract was eventually produced which everyone was happy with. But with several round trips between lawyers and clients, the process took six weeks. That meant six weeks before the project could start, and six weeks added to the completion date. That was bad news, considering the entire job was only meant to take a month.
What lessons can we learn from this story? If you do any kind of freelance work, or if you're a client who employs freelancers, should you dispense with a formal contract, and just get on with the job? Or should you perhaps insist on a contract, but write it yourself rather than involve the lawyers?
The answer depends partly on the size and complexity of the work. If the project entails a substantial amount of work by many people over many months or years - and especially if it involves sub-contractors or other third parties - then a proper legal contract will be essential. It should ideally be drawn up by lawyers who have expertise in the relevant field. And it should be carefully scrutinized by those representing all the parties involved.
But for a small design or programming job, like the one that my friend was commissioning, that kind of contract is rarely necessary. It could even be counter-productive. But don't go to the other extreme. Don't start work without some form of clear written agreement that everyone can accept.
Exchange of letters
For most small projects, it will usually be sufficient for the contractors to set out their terms in an informal letter or email. Write it in everyday language that the client will understand. Keep it as simple as possible, consistent with covering all the essential points. Finish by inviting the client to write back (again, either a letter or email) to say that they accept it.
Such an exchange of letters is just as legally binding as a small-print contract full of definitions and disclaimers. Arguably, it will be less likely to lead to disputes, given that it will be written in clear language rather than the sort of extended sentences that you have to read three times to understand.
The letters should be informal, but they should never be sloppy. Keep a business-like tone, and be sure that you deal with the relevant points clearly and unambiguously. If you're unsure what points you need to cover, see my article, Freelance contracts: Covering the essentials.
Forgo the written contract?
What if the project is so small or so simple that even an exchange of letters seems like over-kill - if it only involves a few hours work, for instance? In such cases, you might prefer to forgo a written contract. But be aware that a contract will still exist, even if the terms have not been set out in writing.
For example, if a client calls a developer and says, "Hey, Steve. Remember that bit of programming you quoted for? Well, I'd like you to go ahead with it." And the developer replies, "OK Suzie, I'll get it done by Friday", then that's the contract. Even though it's not in writing, it's just as binding as one that is.
In this example, the verbal contract - that is, the phone conversation - establishes three important points: the scope of the work, the price, and the delivery date. So what about all the other essential issues, such as the payment terms and the ownership of the work? In most cases, these will be governed by whatever is the normal practice within the context of the project. For example, if the developer has worked for the client before, and if he or she has always submitted monthly invoices, it's reasonable to suppose that the same thing will apply in this case. Similarly, if it's normal practice in the relevant country or industry to charge interest on overdue payments, the developer can reasonably expect to do that here, even though it wasn't explicitly agreed.
Of course, the biggest problem with verbal contracts is that one or both parties can dispute what was said. For that reason, it usually makes sense to put the agreement in writing, even if the effort involved seems out of proportion to the value of the work. But that's a judgment call. It's a decision that will depend in part on how well you know the client, and how much money you stand to lose if things go wrong.
Whether you're a freelancer or a client, I hope this article will help you out next time you need to agree a contract. Remember, if the project is complex, lengthy or expensive - and especially if the cost of failure is high - then you should always take legal advice. But for small bits of design or development work, a simpler approach is often preferable - as I hope my cautionary tale has demonstrated.
Please note: The information given on this site has been carefully checked and is believed to be correct, but no legal liability can be accepted for its use. Do not use code, components or techniques unless you are satisfied that they will work correctly with your sites or applications.