Avoiding Legal Headaches: How to Read a Contract

You must use a contract.

We’ve discussed this many times before, but it’s essential to document the project scope and responsibilities for every client. Costly misunderstandings and legal shenanigans can be avoided from the start.

A concise and easy-to-read contract is normally written by you and signed by both parties. However, you may find at times that the client issues a contract when you’re undertaking agency work or charging an hourly fee for your services.

This may sound obvious but: Read it. Twice.

Contracts are a binding agreement. No one will try to catch you out (I hope), but contracts are rarely written by those with software development experience or expertise. A seemingly innocent clause could cause untold damage to your business.

Consider this statement in a recent contract I was issued:

The Consultancy [me] shall be liable for any defects arising in relation to the Services [my development work] and shall rectify at its own cost such defects as may be capable of remedy within a reasonable period from notification.

The remainder of the document consisted of benign “don’t steal paper-clips or look at dodgy websites” requirements but this spectacularly vague clause made me nervous for several reasons:

• What is a “defect”? In relation to software this could be a bug, a missing feature, an undocumented requirement, a widget being 1 pixel out of place in IE6 or any number of irrational whims from a megalomaniac CEO.
• A defect could arise “in relation” to my work. Perhaps a new version of jQuery doesn’t support an aging BlackBerry device. Perhaps a new version of Firefox changes or removes a feature I was using. Perhaps the next edition of a language or framework I use is incompatible with the previous version. I may not have written the offending code but it still relates to mine.
• “Capable of remedy”? That’s anything and everything. Clients often state they want to be the next Google, Facebook, Amazon or eBay. There’s nothing wrong with ambition, but should developers be responsible for fixing fundamental issues if a company doesn’t achieve these goals?
• What is a “reasonable period”? One week? A month? Five years?

While I understood the intention of the clause, a difficult or demanding client could expect me to work many months for free until their project reached an impossible level of perfection.

As a developer you understand the complexities. Software can be improved indefinitely, and all products have bugs. Even if your code is perfect, what about the libraries you depend on, the database, middleware, operating system, or the remote user’s operating system or web browser? You appreciate that code you write today is not necessarily compatible with the software stacks and browsers of tomorrow.

Does your client appreciate that software needs to be updated and maintained? It’s better to explain the issues before a contract is signed than argue against a hotshot lawyer in court many months later.

I questioned the viability of the clause above and refused to sign. The agency was stunned; they’d been using the same industry-standard document for many years and I was the first person to raise an objection. There are three possible reasons for this:

• I misunderstood the meaning or context of the statement. However, a contract is a mutual understanding between two parties, and you should never agree to anything which isn’t clear.
• Other developers reached the same conclusion but signed regardless. They may have been concerned about losing the job or causing a fuss, but a contract should never make unreasonable demands of either party.
• The simplest reason: no one else had read it. Few developers have legal expertise, but if you require that knowledge to understand the implications, don’t sign. In this particular case, the document wasn’t long or complex–developers had been too lazy to look at the fine print.

A Contract Reading Checklist

Contracts are daunting to read but they benefit you and your clients. A few hours examining the fine details could save months of effort later.

Taking the following steps before you sign on the dotted line can help you avoid trouble:

1. Always read your contract. Then read it again. Properly. Without skipping bits.
2. Ask a friend or colleague to read it. They will have different perceptions about the context.
3. Take your time and don’t feel pressured into signing quickly. If the client is intimidating you before you start to work with them, imagine how they’ll be when they’re paying!
4. Contract statements should be unambiguous. Watch out for clauses which are vague or could have double meanings.
5. Consider the worst case scenarios. For example, what could happen if the client wasn’t happy? What if I had to leave the project prematurely? What if I failed to complete a task on time?
6. Question every statement that isn’t clear or that you don’t understand or disagree with.
7. Where necessary, get the contract changed — never accept the client’s verbal reassurance.
8. If the contract is too complex, request a simpler, plain-language alternative.
9. If all else fails, consult someone with legal expertise. Warn the client that this extra expense will be charged to them. They will understand if the contract is necessarily complex.
10. If you have any doubts, do not sign and be prepared to walk away from the job.

Have you been asked to sign contracts with preposterous requirements or impossible ultimatums? Did you tackle the problem or sign anyway?

Frequently Asked Questions about Reading Contracts