September 3, 2010
Anyone serious about web design understands the essential role contracts play in the process. A contract is a legal document binding two parties to a trade, and it can carry heavy weight should a dispute arise. Unfortunately, not every project goes well — despite your best efforts — and there may come a time when the enforcement of a contract is necessary. It’s at that point you’ll thank yourself for having gone through the trouble of creating a sound legal document, and in the end, it’ll probably end up saving you time and money.
I’ve come across all sorts of contracts in my experience. Some are the size of books and others are mere one-pagers. I’ve seen ambiguous contracts and I’ve seen rock solid contracts.
Having a poor contract is almost as bad as having no contract, so I’ve compiled a short list of the most essential provisions you must consider adding to your contract template.
An obvious consideration, the scope of work outlines the extent of the work to be performed including pages to be built, special functionality, design elements, and so forth. You would be surprised as to how many contracts fail to clearly outline what the designer is offering as the service to be performed. A scope of work solidifies the designer’s job and is a good start in ensuring the project is clear of ambiguity and potential scope creep.
This may be part of the scope of work, but you should always identify the number of design revisions a client is allowed during the mock-up stage of the project. For most contracts, I’ve seen it limited to two or three revisions. Keep in mind, a revision does not include minor, superficial changes to a concept, but rather a complete redesign of one concept to form another. By limiting the revisions, you protect yourself against projects that never leave the design stage — either the client will accept a design, give you additional funds for more revisions, or end the project. In either case, you don’t lose much money or time.
Nearly all of your projects should include a set of milestones to break work into manageable chunks. You should apply this same philosophy to your web design contract. Outlining the milestones in the contract clearly defines the different phases of the project as well as the planned length of time needed for each phase. This leaves nothing hidden from the client and immediately sets out what should be expected of the project.
As part of the listing of milestones, I would recommend establishing the client’s responsibilities for the project. Client responsibilities include anything that they need to provide such as content, graphics, marketing literature, feedback, and technical specifications. If you list these actions as milestones and assign the client a due date, you make it known that there are deliverables the client is responsible for.
Most web design contracts and proposals split the payment into two chunks: 50% before and 50% after. For larger projects, this may be split into thirds or fourths. In any case, the contract should explicitly state when these payments are due. Avoid using wording such as, “Payment is due after the project,” because this is vague and may encourage the client to “delay” the completion of the project indefinitely. Instead, you should tie payments to milestones and/or defined dates. For example, you may have a milestone for the completion of a final prototype, which might be the best place to require the second of three payments. This milestone may have a vague timeframe attached to it (e.g. “Week 8”), or it might have an actual date assigned to it (e.g. “October 25”). I like to keep timeframes more on the vague side in the event the project is delayed a week for whatever reason.
I find it in good form to provide set hourly rates after the payment schedule for two primary reasons. First, it gives the client an understanding that should their requests fall outside the scope of the project, they have the option to pay by the hour. Second, the hourly rates prevent any surprises that may occur if the client must use them.
Inevitably, you will run into clients who must, for one reason or another, cancel the project. It’s unfortunate, but it happens. Your web design contract should be able to handle this situation by specifying what the cancellation policy is, which should basically state how much money will be due, and how the client must provide notification. In these circumstances, I usually keep the initial deposit but waive the final payment, and clients are generally satisfied with this outcome.
Attaching a listing of your general terms and conditions to the contract is a necessity. Your general terms and conditions should clarify dispute resolution, contract termination, confidentiality, ownership, and so forth. This section essentially reiterates your entire proposal, but in legal speak. It’s extremely vital that you have a lawyer review (or perhaps create) this section of the proposal for you. In the event of a client dispute, this section will be one of the most heavily scrutinized, so you want to make sure you protect yourself.
Crafting a solid contract for your projects may seem boring and tedious, but these documents serve as the foundation of any work you complete. Doing work under a poor or missing contract will open you to unknown liability (I say unknown, because you could be sued for just about anything, regardless of the party at fault). And please keep in mind that I’m not a lawyer, message boards are not lawyers, and blogs are not lawyers — you should consult with an actual attorney to fine tune your contracts, which in most cases will run about $1,000 — but that’s money I would consider well spent.
Have a question or comment about this post? Drop me a line!