Web Design Contracts: Why Bother
In: Columns > The Business End
Published on January 22, 2007
Contract-Shmontract, What’s the Point?
In law school, one of the things they teach you in Contracts 101 (usually on the first day) is that contracts serve more than just a strictly legal purpose. Specifically, the solemnity involved in the act of signing a contract—the ritual of the contract negotiation and execution itself—impresses on the parties that they are making a commitment to each other, and that the document they are signing describes that commitment. In this sense, contracts have a socio-psychological function as well as a legal one. They also have a vital business purpose in that the contract is the accepted opportunity to specify each party’s expectations and obligations with respect to the promise they are making. This specification can be incredibly useful for clarifying these promises as the relationship progresses, even if no lawsuit is ever filed. In other words, a contract is well worth the effort it requires even if you would never sue to enforce it—particularly for designers.
Design work is often difficult to define in advance, and is inherently subjective. A contract helps to remove some of this ambiguity. For the reasons I’ll outline below, working without a contract is unwise and, in this day and age, should be unnecessary. No reputable client will object to some form of documentation (especially if you are willing to do all the work of producing this document). If the client does object, I suggest you run away—far and fast.
Proposals Are Not Contracts
What does this mean for the small/solo web designer? For most of us, the cost of undertaking even a small-scale litigation would far outweigh the potential return, especially when the adversary is a client with its own internal legal department and mountains of cash at its disposal. So why bother with contracts in the first place if you’re unlikely to ever sue to enforce them? Can’t a design proposal adequately serve the purpose of specifying the details of the upcoming project? Why go through the sometimes grueling, time-intensive extra step of negotiating and signing a contract?
Proposals are written to convince the client to hire you over others. This means that you may reflexively minimize the demands you are making on the client, and focus mainly on your expertise and the value your work will provide to them. Of course, your assumptions should be reasonable and your costs should be clearly identified, but it’s unlikely that you will write a proposal (or that your client will read it) in the same way that you would approach a legal document. Most of us have probably had real-world experiences that support this conclusion. Clients will often fail to closely read detailed design proposals that clearly specify scope, deliverables, and underlying assumptions. Instead, they will rely on their own interpretations of conversations they have had with the designers during the proposal process—an interpretation which is often skewed in their own favor. This situation leads to the dreaded, “I thought you were going to…” conversation during which the full detail of the client’s expectations finally come to light—too late, unfortunately, since by this time significant work has already been started, or finished, on the basis of a totally different understanding.
Even if the content of the contract is basically a duplication of what was in the proposal, the act of transforming the proposal into a contract invites clients to pay closer attention to the terms you are proposing. Believe it or not, I have had clients question or object to terms in a contract that were clearly stated in the proposal they had already accepted. In these cases, I was extremely fortunate to have identified these areas of conflict before work was done. A written contract won’t always avoid this outcome—I’ve had clients tell me with a straight face that they didn’t realize we were billing for each hour of work despite a clear statement in our contract to that effect. But in that case, I could at least point back to the contract language (humbly, mumbling apologies as I did so) as evidence of his misunderstanding.
Your Friend the SOW
Now that we’ve covered the why of web design contracts, let’s move on to the what. Broadly speaking, there are two situations that you should be prepared to deal with: 1) Your client drafts the contract, and 2) You draft the contract.
Regardless of who actually writes the formal contract itself, it’s almost certain that you—the vendor—will be called upon to provide the substantive content that describes the work you are going to do, and the basis for your pricing, so you need to be ready to do this. It’s easiest if you create a Statement of Work (SOW) template that will work for most of your typical projects, and modify it as needed for particular contracts. I suggest that your SOW contain at least the following information:
- Overview: A brief description of the services you are providing and the name of the site or product you will be working on. If you will be working in phases, it’s helpful to list and summarize the phases at this point.
- Process Description: For each phase of work, describe exactly what you are going to do, in what order and, ideally, what the purpose of each activity is. Wherever possible, use actual numbers to clarify your assumptions— the number of design reviews and revisions, the number of stakeholder interviews, the number of page templates, etc.
- Deliverables: Clients are always particularly interested in what they are getting from you, so be sure to be specific about the deliverables in each phase.
- Ownership: The ultimate ownership of your work product will be of great interest to your client—and it should be to you as well. In the vast majority of cases, the copyright for all design work is owned by the client who has commissioned the work. This is typical and usually not worth opposing. However, you may want to put some thought into aspects of your delivery in which you will want to retain ownership. For example, the format and organization of your design specification should be your own, and should not be accidentally transferred to your client along with their designs.
- Pricing: Will you be billing on a fixed-price basis? Time and materials? It’s vitally important that the contract specify how you will determine your bill for the work. This should be stated simply and (in appropriate cases) should include hourly rates for all billing resources.
- Payment Terms: State whether you expect payment up front, and when additional invoices will be issued (e.g. monthly, upon completion of phases, on certain dates). You should also outline payment terms, for example, that all payments are due within 30 days of the bill date (net 30).
An SOW containing the information described above can itself form the basis for a contract (in other words, you and your client can simply sign the SOW and move on), or it can be attached as an exhibit to a standard form contract that your client may provide.
Your SOW can, and should, evolve over time as your practice develops. After each project, ask yourself whether you’ve learned any lessons that would be relevant to how you will describe your work in the next SOW. Pretty soon, you’ll find yourself with a customizable SOW that perfectly describes your process and deliverables—which can be a big help with project management and business development as well.
Bring on the Mumbo Jumbo
In addition to the SOW language described above, contracts typically contain a series of other terms that have virtually no effect unless there is a lawsuit—and often not even then. But that doesn’t mean that you don’t need to understand or care about what these clauses (often referred to as “legalese” or “legal mumbo jumbo”) have to say. For clarity, let’s refer to these terms as the Base Agreement.
The Base Agreement is the standard stuff that doesn’t change from contract to contract. These are contractual terms that have evolved out of the legal history in a particular state or country, and they tend to deal with very specific scenarios, usually involving disputes over the contract, that are very unlikely to come to pass. The good news is that you probably don’t need to spend much time or effort negotiating them, as their immediate impact on your project is minimal, especially in comparison with the all-important SOW. The bad news is that you’ll have no earthly idea what most of these terms mean and you’d have to earn yourself a law degree to figure them out. In other words, your ability to safely write a Base Agreement, or review one that a client’s attorney gives you, is basically zero. Here’s my advice: Get a lawyer. Sure, you can find all kinds of form agreements out there that look just like real contracts, and they are probably just fine1. But I can’t in good conscience recommend that you sign something that you don’t understand—or that hasn’t at least been reviewed by someone you trust. In most cases, it would be better to sign a contract that has no Base Agreement terms (i.e. just a plain SOW) than agree to an assortment of legal clauses that could ultimately work against you.
Hiring a lawyer isn’t as scary as it sounds. There are a ton of them out there, and the kind of agreement we’re talking about is as basic as they come. Get a few names from friends, family, or colleagues in the design community. Or check out your state Bar association for some choices in your area. Look for lawyers or firms whose pricing is appropriate to the size of your business, and who has experience with professional services contracts. Make a short list of three or four attorneys and interview them briefly on the phone. What’s most important is that your lawyer be someone with whom you can communicate well, someone who explains things in a way you can understand and who understands what you’re talking about when you describe the challenges you are facing. Find out what it would cost for them to produce a Base Agreement for you. You should also get a sense of how costly it would be for them to review a client’s contract. Finally, be sure that they are not too busy with larger clients to be as responsive as you would need them to be.
Work with your new attorney to craft a Base Agreement that makes sense for your typical project. You should review all the Base Agreement terms together so that you have at least a basic understanding of what everything means and the relative importance of each clause. You may decide together that certain terms are particularly important and should never be changed without additional consultation. The express goal of your Base Agreement is that it be re-usable.
Working Without a Net
If you just can’t stomach the idea of hiring a lawyer—or you can’t afford one at the moment—all is not lost. Sure, you will be operating with a slightly increased level of business risk, and you’ll have to work harder to get through the contracting process, but this is certainly possible2. If you have chosen this path, I suggest the following procedure:
Begin proactively by offering the client your SOW as the point of departure for the contract. With luck, they may agree to sign this without significant modification. At a minimum, you should request that the SOW be used as an exhibit, attached to a Base Agreement that is drafted by the client. Once this Base Agreement arrives, get yourself a cup of coffee and a quiet corner and read through it slowly and deliberately. Be on the lookout for any language that creates an obligation on you. For example, some contracts require vendors to maintain a certain level or type of insurance. Others attempt to hold vendors to a high standard of performance that may or may not be adequately described. As you read the agreement, think about the scenarios that each provision is envisioning and what impact these provisions would have on you. Ask yourself in each case if the outcome would be fair to you—or even tolerable at all. Once you have read every paragraph, make one of the following three notations next to it:
: You understand the clause well enough to deem it harmless or irrelevant to you in this particular project. You need never look at it again.
?: You have read the clause eight times and you still have no idea what it means. The client (or the client’s attorney) will need to explain this to you and make you comfortable that it does not involve the transfer of your firstborn child.
X: You’re pretty sure that this clause does involve the transfer of your firstborn, or something equally heinous. The client will need to remove or modify this provision before you will sign the contract.
When you have completed your review of the draft, I suggest you write up a summary of your questions and objections—referencing the contract paragraphs by number. Return it and ask for a response. The client may respond to you in writing (which is preferable) or might want to arrange a meeting or call to review your concerns. At this meeting, do your best to dispose of your Xs and question marks—either by deleting the offending language, or obtaining an explanation that alleviates your concerns. You will almost certainly get a strong vibe from the client regarding the provisions that they are absolutely unwilling to alter. In these cases, you’ll need to decide whether the project is worth the potential risk.
Following this process may not guarantee you a contract that is entirely favorable to you—or even one that the client is willing to change at all—but it will give you a better understanding of what you are signing so that you can take any project-related precautions that might help avoid the negative scenarios in the contract. For example, if you know in advance that even a minor schedule slip will create a payment penalty, you will be extra careful not to let this happen.
Go Forth Unafraid
Now that you have your form of SOW, your Base Agreement, and (maybe) your attorney, you are prepared for any contract situation that may arise. You are ready to produce a complete contract (SOW + Base Agreement), or simply provide your client with an SOW to attach to a Base Agreement—which you may choose to have your attorney review if it seems very complex, or if it varies significantly from the Base Agreement terms with which you are now familiar.
Sure, after having worked hard to sell a new client (which typically requires a demonstration of flexibility, eagerness, and friendliness), it’s awkward to suddenly turn hard-nosed about getting a signed contract before starting work. It is certainly easier to just smoothly transition from the sunny optimism of the proposal process to the nitty-gritty of the project itself. But, as I hope I’ve outlined in this article, a well-drafted contract protects both sides and clarifies the designer/client relationship in many non-legal ways as well.
Note: Please bear in mind that this article, while it concerns lawyers and legal issues, should not be considered legal advice. You’d need a real, practicing lawyer for that. We’re just talkin’ here.
1 There are several good online sources for business and legal forms. For example: Yahoo! Small Business, NOLO.com, and AllBusiness. Look for forms for Consulting or Contractor Agreements, as well as those dealing with Intellectual Property issues (i.e. copyrights and trademarks). Be prepared to pay for high-quality, detailed forms. You may also need to purchase more than one form in order to cobble together a contract that will work for your specific business. But these costs are minimal compared with the cost of hiring an attorney.
2 Think about how many contracts you sign every year without even reading them—website terms of service, credit card agreements, wireless contracts…. On second thought, maybe it’s better not to think about it.
Nick Gould has witnessed the dotcom boom/bust/boomlet, and, to this day, finds it amazing that a small (but high-powered) design firm has provided more stability, security, and job satisfaction than any of his previous employers (including corporate law firms and Fortune 500 companies). Nick lives in his ancestral home of Brooklyn, New York with his wife and daughter.