Contracts for web designers and developers

“Debts are like children, the smaller they are the more noise they make.” — Spanish Proverb

Contracts are a curse for a small services businesses. Yes, that is right, they are a curse. Most small services businesses enter into them, mistakenly thinking they create certainty, prevent losses, and form an important part of risk mitigation. They are wrong. "If I have a contract, then I am safe, or covered, or I can start work," should no one say, ever.

Contracts are for lawyers

The problem with the contract-based work approach for small businesses is that contract documents should be generated by lawyers. Contracts should be negotiated between lawyers and ultimately litigated between lawyers. Lawyers create contract documents to clearly define the scope of a relationship between two parties, to anticipate problems, and provide solutions to problems ahead of time. They also use them to achieve the best possible position for their client, to gain commercial territory, and to prevent other parties from undertaking certain activities as a quid pro quo for entering into the contract.

This means that contract documents are fundamentally adversarial. Service businesses should not have adversarial relationships with their clients, ever. Just as you don’t need a sword to open a pack of sausages, you don’t need full legal contract documents for web development projects. What you are interested in is receiving payment, and what your client is interested in is achieving their goal. This is a collaboration between you and them.

I have signed agreements with big agencies and small ones on behalf of start-up clients. Never once have I seen a document that impressed me, or gave me confidence in the agency’s ability to deliver. All they offered was confused (borrowed) boilerplate, a vague nod in the direction of certainty, and too many hours of effort in drafting, negotiating, and signing. The best certainty of all is keeping your arrangement simple.

You might also like: 8 Quick Tips for a Bulletproof Freelance Contract

The document is not the contract

There are three things you have to know about contracts (in England & Wales and the US):

The document is not the contract
You can do business without the document
You are not qualified to write the document unless you are a lawyer

I won’t go into the details of contract formation as it changes from place to place, deal to deal, and there is a lot of good information online about what constitutes a contract. Suffice to say, in England and Wales, and most of the US, the written document you call a "contract" is a piece of evidence showing that you and the other party have made certain promises to each other. You sign it as an indication that these are the terms you agreed to, and you date it to show the date on which the agreement was formed.

If you want to spend some money on a lawyer, buy an hour of their time so they can tell you how to validly form a binding contract in your local jurisdiction (NB: there are places where the document is the contract). Think of all the scenarios you might come across (on the phone, over coffee, over lunch) and map out the questions you have to ask, the answers you have to receive, and the actions that have to be taken for a contract to be formed. An email describing the agreement in writing is a good place to start. The money paid up front into your bank account is better.

You don’t need the document

The key terms any small business (or their customer) is interested in are these:

What is the job?
When will it be done?
How much will it cost?
When will payment be made?

For example, Agency A has promised to make a five page website, built on Shopify for Client B within six weeks for a fee of $2,500. Does it matter to which courts both parties submit their exclusive jurisdiction? Does it matter which law governs the contract? Even if it does, is either party in a position to understand or agree to those things without input from a lawyer? No.

You might also like: How to Write a Freelance Contract 101

Good terms / Bad terms

Contracts for web designers and developers: Terms and Conditions

Images have been kindly provided by Marie Mercier, whose work can be seen at mhcmercier.com. All images are copyright Marie Mercier, 2015.

A traditional (bad) service-based relationship might look like this: a customer requires a website; an agency bids for the work; the customer agrees to the design; the agency creates the website; the customer pays the agency on delivery but requires amendments prior to delivery and withholds payment until it is satisfied (or longer).

But payment on acceptance are simply the worst terms you could request. Not only do you have to deliver the website before you get paid, but once the customer has the website, he or she has the opportunity to make additional requests (inside or outside the scope of your arrangement) before making payment. You have to define careful acceptance criteria and then someone in your team has to manage the client against them in order to ensure they are completely satisfied (and this is why you want a contract in place, with signatures on both sides, so that you have a document to fall back on in the case of non-payment or if you have to make the case that you delivered what was requested of you).

Unsurprisingly, this is all bad, unprofitable, and damaging to your client relationship. Instead of experiencing the joy of delivery, the client experiences the pain of payment. The last impression you leave will be of your cost, not your value.

Payment on acceptance are simply the worst terms you could request. Instead of experiencing the joy of the delivery, the client experiences the pain of payment.

In contrast, a good relationship might look like this: a customer requires a website; you bid for and win the work; you define the scope of the functionality and the time frame for delivery of the main project; the client pays up front and you agree to refund payment if the client is unhappy; you agree to an ongoing monthly maintenance fee to be paid automatically by credit card or standing order to cover additional work; you create the website and refine it over time with the input from the client and then maintain it and are on call for small tweaks, amendments and marketing campaigns.

See? You don’t need a document. What you need is to set out the basic terms in a short (one or two-page) term sheet and then do your job, which is not to lend money to your clients. You preserve your client relationship in excellent health, and you don’t tie delivery to expense in the mind of client — you tie it to value. Price is only an issue in the absence of value. You don’t need a document.

Hand-me-downs don’t fit

If you are using a document that you got from someone else, or a previous job with an agency, or copied from the Internet, it is almost certainly not fit for its purpose. If you spend time amending it, updating it and then negotiating it with your clients, you will be wasting time, frustrating yourself, and leaving money on the table. Don’t do it unless you think it’s absolutely necessary (which it never is). If you are not a lawyer, I guarantee you do not understand 90% of additional boilerplate clauses included in the document (choice of laws, jurisdiction of courts, severability of clauses, force majeure — friends of yours?). Even if you do, I doubt you keep them up to date with changes in the law, would know how to, or when to apply them (and if you are reading this and thinking smugly that you know all of the above, it’s not your job and you are wasting your time).

If your contract is worth less than $5,000 (or the equivalent local amount claimable in a small claims court), and you do not have any additional technical risks to document and account for (as might be the case in the construction industry) and you are selling services to business customers, then you have no place involving lawyers and contractual documents in your sales process. I would actually say that is true up to $50,000 and maybe higher. You should look to be paid based on your relationship and not on the basis of a piece of paper. Set out a clear set of terms for the work in plain English including the website, the number of pages, the process for design and feedback, the price (with a number of options if possible), the time frame, and how expenses will be dealt with. A paragraph beginning, “We will know that the project is complete when…” is a useful way to set the scope and expectations. The rest of the boilerplate is a distraction that you and your client can do without.

Doing business on a handshake is still possible, but only if you are willing to put the effort into the relationship with the client, rather than a document that claims to represent that relationship and does not.

The only instance where you might want a contract is if the client wants certainty of intellectual property (IP) transfer. This can be a little complicated and is worth documenting with a contract drafted by a lawyer. If you have background IP (i.e. IP that you have developed) that you will be licensing to the client as part of delivery, you will need to protect it. Likewise, your client will want you to transfer the new IP in the website and in particular the code base over to them. The way to deal with this is the same for an NDA. You put a line in the term sheet that says you undertake to sign NDAs and IP transfer agreements in a form agreed between you and the client.

You might also like: Why You Should Bill 100% Up-Front

Boilerplate is bad

When I was at law school (shortly after the global financial crisis kicked in and Lehman Brothers collapsed), an apocryphal story of Dick Fuld — ex-chairman of Lehman Brothers and formerly an internal problem solver at the bank — was a favourite of my contracts tutor. Called into a meeting after a deal had gone disastrously wrong, Fuld was greeted by a room full of lawyers. One said, “We’ve examined the contracts, it doesn’t look great, but we think we can get out of it if we use force majeure.” Dick replied, “Great, get him on the phone.” An embarrassed silence passed before someone explained that force majeure was a clause in the contract exonerating both parties of their responsibilities in the case of an ‘Act of God’, terrorism, war or natural disaster. “Geez," said Dick, "It’s hard enough to understand you without you speaking Spanish.”

True or not, Dick's story illustrates that your role is to service clients and not to write contracts. The story is a joke, intended to make Fuld seem stupid, but the reality is it would have been stupid for him to fill a room with lawyers charging over $500 per hour (each), only to tell him something he already knew. It's not his specialty and so he didn’t know about it. The same is true of you. You charge for web development services, so it is a waste of your time to produce contracts beyond creating certainty around what your client is expecting and when they will pay. Do yourself a favour instead and start actively managing your relationship with the client so those things are self evident.

If you want to document them, write them down in emails and copy everyone in for clarity. If you really need a contract, ask a lawyer to draft it and sign it off. Then you get the benefit of their expertise and if anything goes wrong, they have professional indemnity insurance. If you don’t think that insurance policy is worth $500, $1000, $2000, etc. that asking a lawyer will cost you, then of course don’t pay it. But know that the alternative is not do it yourself. The alternative is strong relationship-based service work, with good payment terms, and a clear, plain English one-page term sheet that let's you focus on your work and create valuable and lasting relationships with your clients. If you do this (taking payment up front, focusing on delivering value and not wasting time on useless contracts that you don’t understand), it’s unlikely that you will ever need a full contract for a services business.

But my partners/investors/clients insist on contracts!

Great. In that case, set out the terms you are planning to enter into. What, when, who, how much, and who owns what at the end? These are the key questions that you need to address. More precisely these:

Who is the contract between?
What are their respective obligations in terms of service delivery and payment?
Who will own the final work product? (Will you continue to own some of it and pass the rest to the client? if the client wants 100% ownership, will this be a different (higher) price than if you kept your pre-existing intellectual property?)
What happens in the event of a dispute?

Now give this to a lawyer and ask him or her to draft it for you into a legally-binding agreement. Ask them to make it short, and to include any of their standard provisions to protect your company. You will need to review it to make sure it accurately describes the situation you are seeking to document. Your lawyer should produce this document, not your client’s lawyer, though your client’s lawyer will want to comment on it. If anyone should know what will be in the legal documents it is you and your lawyer.

You also want maximum protection in the contract (this is contradictory to some of my previous advice but since you are required to provide a contract, you should make it a strong one.) Nonetheless, the most meaningful protection will always be payment up front. You will need your lawyer on hand to follow up with the client and explain some of the provisions. Leave this conversation to the lawyers as much as you can: you are supposed to be making websites.

What if they don’t pay and I don’t have a contract?

You chose a bad client. It happens. It’s not always their fault (not directly at least). Let’s get one thing clear. Your business is not a debt-recovery business. There is a reason why credit card companies write a couple of letters, make a lot of phone calls to bad debtors, and then sell the debts to a hedge fund for 8¢ in the dollar. Collecting bad debts is difficult, expensive, and very far out of your core business. Proceed with caution. If you had taken payment up front, not only would your cashflow have looked great on day one, you would have had guarantee of payment regardless of your client’s solvency and you would never put yourself in the position of delivering the work (your only leverage over the client) and then waiting for a payment which isn’t coming.

If a client doesn't pay, the first thing you should do is stop work and call your client and explain there is a problem. Payment date has passed and you have not been paid. Be understanding, be human, but be firm. Work cannot continue without payment. If they are well meaning, intend to pay but need some leeway, that is fine. A few weeks, a month, is no problem. After 90 days, you should assume they will never pay and move on. Decide whether you want to maintain your client relationship (and why?) and pick your favourite of (i) forgive the debt (at least in your mind) and stop chasing it, (ii) sell it to a debt recovery agency for 20-60% of its value, (iii) assign someone internally to pursue it politely until it is paid, or (iv) consider making a claim in a local (small claims) court. The moment you go to court, it will cost you some money. That and a lot of time, which in a services business, also equals money. If you have to resort to litigation to get a client to pay you, it will be abundantly clear that they either don’t want to pay you at all, or they can’t pay you. Either way, you are in for a rough ride.

If you've maintained control over code repositories, or hosting accounts, you can switch these off or deny the client access to put pressure on them. Either way, you are now on the attack and attacking your clients doesn’t make them more likely to pay. If you are in this situation, your best option is to switch off what can be switched off, tell the client the reasons for doing so (or ask a lawyer to write a letter for you) and then walk away and assume you will get nothing (you can hope for a little more).

Tell your value story

In summary, when dealing with your clients, you have the chance to tell the value story for yourself. View the contractual relationship as being part of your service and marketing. Timing payment is seriously important. If the client receives the product and then has to pay for it, it will seem like an expense. If the client pays you and you start work and begin delivering value immediately, the client will see you as a sound investment and remember the value you delivered instead of the price that they paid (and you will be in a great cashflow position). When the site is finally delivered, they will be pleased to have received it and your last impression with the client will be of value and not expense. Thoughts of contracts will be very far off.

Do you use contracts to manage your client relationships? Tell us in the comments below.

James Farha