By: John Tabita

October 28th, 2005

Reader Rating: 9.5

When you boil it down to its barest essentials, the sales process is simply a series of verbal agreements that ultimately gets documented in writing. That document ought to become your contract, proposal or whatever legally-binding agreement both you and the client sign to finalize the deal.

If one side fails to live up to his or her part of the bargain, it's called a "breach of contract." Since that's something we all want to avoid, it's important to realize that the key to a bulletproof contract lies in how you sell. In other words, your contract should reflect everything that you and your client have discussed and agreed upon during the sales process.

In order for a contract to be valid, there must be mutual agreement: offer and acceptance. While there are situations in which the offer originates with the buyer, such as winning a project bid on Guru.com ("Build me this type of website for x dollars"), in our industry the offer typically originates with you or I -- the seller. So everything we discuss with the client during the sales process becomes the "offer." He indicates "acceptance" once he signs on the dotted line.

Regardless of whether offer originates with you or with the buyer, there are essential components that should be present in every offering. Some important considerations are: scope of work; client amends and revisions; dealing with client delays; milestones and project completion; payment terms; maintenance and technical support; client or third party site modifications; liability if things go awry; and who will ultimately own the Website you've built. This article looks at each of these considerations, and explains why they're important inclusions for your contract.

Disclaimer: I am not, never have been, nor probably never will be, a lawyer; nor is this article intended to take the place of proper legal advice. Don't try this at home: consult with a qualified legal professional. The information in this article, your proposal and/or scope of work would be a good starting point for a discussion with an attorney.

Since I am a U.S. resident, some or all of this information may or may not apply in your country of origin, if different. Again, please consult a legal professional.

"Does my Client Even Know What He Wants?"

Scope of Work and Scope Creep

According to the people over at A List Apart [1], scope creep is "the natural process by which clients discover what they really want." My first encounter with this phenomenon was relatively minor (a client suddenly wanted a bunch of animated GIFs on a particular page), but it made me keenly aware of what a slippery slope this can become.

The purpose of detailing the project scope is not to prevent the inevitable scope creep, but to give you the flexibility of deciding when it's appropriate to charge for the additional work. Depending on the size of the project, it may not be appropriate to include the project specifications in the actual contract. Regardless of whether the specs are in the contract, or a separate document, be sure to specify exactly what is and is not included -- and have the client sign all the documentation.

"How Many Changes are they Going to Make?"

Client Amends and Revisions

By far, one of the most common mistakes inexperienced freelancers make is failing to limit the number of design revisions the client is allowed to request. When I first started out -- before there was a Web to speak of -- I agreed to design a brochure for an acquaintance. About six or seven revisions later, I began to wonder if the brochure would ever be finished. I learned my lesson early, so when I began developing Websites, I clearly stipulated the number of revisions and haven't had a problem since.

That's not to say that I haven't bent my own rules. One client began to "redesign" the header graphic of his Website. At the sixth or so revision, we put our foot down and let him know that we'd allow one more and that's it. The point is, it doesn't matter if you want to allow two client revisions or ten, or whether you plan on presenting one mockup or 100, so long as both you and the client have a clear understanding of what to expect. When the final revision comes along, the client should understand that all of the changes he wants must be included in this version, or else he may be subject to additional charges.

"Are They Ever Going to Get me the Content?"

Dealing With Client Delays

Another trap into which the inexperienced freelancer commonly falls is that of client-supplied content. According to Kelly Goto, author of Web ReDesign 2.0: Workflow That Works [2] (New Riders Press; 1st edition, August 14, 2001), receiving client content on schedule is "perhaps the most difficult and least-predictable part of any Web project." She goes on to say: "Clients often have an unrealistic view of what they 'already have ready to go' and also what items they need to create. The myth is that the content will arrive on time. The mystery is that no matter how organized both you and the client are, the content will inevitably arrive late."

Upon that inevitable delay in receiving content, the designer becomes understandably frustrated. To compound the problem, if your contract specifies "final payment due upon project completion," you're in the unfortunate position of waiting to get paid while the client postpones indefinitely.

Like many of us, I learned the hard way. On my very first paid project, I foolishly stipulated payment "upon completion." To make matters worse, being naïve and inexperienced, I did not ask for a deposit. Ten months later, when the site was 95 percent complete (less copy), I was still waiting for the content and hadn't been paid a dime. Needless to say, I never made that mistake again.

You must face the fact that most clients will delay, some because they're busy running their own business, others intentionally. Yet, when you signed the contract, you and your client came to an agreement that involves mutual commitments, and your contract ought to stipulate if and when a delay constitutes a "breach." There are several ways you might do this:

1. Stipulate that content is due by a certain date and, if not received, the client is in breach of contract. (You'll have to specify the ramifications of that breach, such as the client loses his deposit or a portion thereof, and the contract is voided.)


2. Stipulate that if content isn't received by a certain date, the remaining balance of the project is due and payable. (This avoids calling delay a breach and canceling the contract outright, yet still spells out consequences and provides a motivation for the client to supply content in a timely manner.)


3. Instead of attaching payments to production milestones, stipulate that final payment is due within a certain number of days, regardless of whether the project is completed or not. You can specify the time frame roughly to correspond with the date you estimate that the project will be completed, were no delays to occur. (This also avoids a breach and cancellation of the contract, but also avoids the impression that you're punishing the client for being late -- and you still get your money on time! The client's primary motivation to provide content in a timely manner is that he'll have paid for a site that remains largely unfinished, due to his own inaction.)

Providing content isn't the only area where a client can hold up production. Consider any milestone that requires client action, such as approving design mockups, and build something into your contract that will keep things moving.

"My Client Wants the Source Files!"

Who Owns the Website you've Built?

The mere fact that the client paid for the work does not automatically assign him ownership of the site or give him the rights to the source files. But all too often, the question of who owns the Website and source files doesn't come up until the client either asks for the source files, or decides to hire another designer to do some work on the site you built. It's always better to establish this beforehand, during the initial sales process, rather than fight over it after the fact.

Avoid "Work for Hire"
To establish copyright ownership, the first thing you must address is whether the work is to be performed as an independent contractor or as "work for hire." In general, "work for hire" occurs when you are an employee and the work is performed within the scope of your employment. In that case, your employer, not you, has full rights to the work.

But be aware that there are circumstances in which work performed by an independent contractor can be classified as "work for hire." While these circumstances generally don't apply to Web design or development work, it's still best that your contract specifically states the terms under which your work is performed. If you want to retain ownership of your work -- even if you intend to transfer that ownership to the client once he's paid you -- then avoid "work for hire" situations.

For more information on "work for hire," see the U.S. Copyright Website [3].

Rights to Design Work vs Development Work
U.S. Copyright law clearly states that the creator of a work owns the rights to that work from the moment it's put into some tangible form. Once you establish that you're performing the work as an independent contractor, not on a "work for hire" basis, you'll have to decide what to do with the copyright. Should you retain "full rights" and license its use, or should you assign full or partial rights to the client?

The debate over assigning the copyright to the client has been waged on many a forum, including those at SitePoint. Whether it makes good business sense to do so is a matter of opinion. Each of us must resolve the issue in a manner that promotes good client relationships, yet doesn't allow us to be taken advantage of.

Most of us would agree that it's plain wrong to withhold copyright and source files simply to keep your client hostage. But before you transfer all rights away, take a good, hard look at the difference between the rights to design, layout, graphics, text and HTML verses code that actually qualifies as being an application. Assigning your client full rights to your CMS, custom shopping cart or database-driven member management application may not be the wisest course of action. As the legal owner of the application, your client can:

1. Prevent you from reselling the application to another client


2. Resell the application himself and not owe you a dime

Personally, I think the litmus test of whether to transfer ownership to the client lies in its potential to be resold. Unless you think the Website you're building has the potential to be a major motion picture or the next best-selling video game, then holding onto the source code/files for the design, HTML, etc. may seem a bit silly. Obviously, a .psd or .fla file can't simply be resold to another party "as is" by you or your client. But an application that manages an organization's database of members or customers would be a different matter entirely. Retaining the rights to the ASP/PHP code and licensing its use to the client makes more sense and is a fairly standard practice.

Assigning Copyright Upon Completion
If the client is paying you, he'll likely assume that he'll own the Website once it's paid for. If your contract states otherwise, your client -- especially smaller ones -- may not fully understand what this clause means, and will likely be unpleasantly surprised down the road when they find out differently. (Larger corporate clients, on the other hand, will most certainly run your contract past their attorney and require that you change the clause to assign them full ownership of the site.)

If you decide to assign ownership to the client, then you, as the copyright owner, must specifically transfer ownership to the other party in writing. When doing so, be clear which portions you are transferring and which you are not, by specifying, for example, that ownership is limited to design, graphics, text and HTML source code, and that the application(s) is used under license and remains the copyright of its owner.

"Help! I'm Being Sued!"

Legal Boilerplate Clauses

As I mentioned earlier, if one side fails to live up to his or her part of the agreement, it's called a "breach of contract." Boilerplate clauses give you the opportunity to limit the amount of risk and liability you'll incur if you're accused of such a breach. Boilerplate clauses are standard parts of a contract that are reusable because they do not relate to a specific project. Examples of such are: Limitation of Liability, Arbitration, Choice of Law, and Cancellation or Escape Clauses.

Limitation of Liability
A standard limitation in your contract should be the exclusion of consequential damages -- that is, damages or losses that arise not from the immediate act of one of the parties, but as a consequence of that act. In the absence of such a clause, your financial liability is theoretically unlimited.

Suppose for a moment you were late on a project. (I realize that this would never happen, but let's imagine that it could...) Normally, this might not be a problem, but in this case, your contact specifically stated that the project would be completed in 45 days -- just in time for your client's extensive marketing blitz intended to drive tons of customers to his new site. Unfortunately, you neglected to include a clause limiting what you'd be liable for in the event of such an occurrence, and you find yourself being sued for all the consequences your client now has to suffer, like loss of revenue and the entire cost of his futile marketing campaign.

Being sued for consequential damages probably falls in the "it will never happen to me" category, but it can and does happen all the time. A client can sue you for loss of business revenue, profits, data, business interruption, loss of business information, or failure to sell its products due to service interruptions. This may become more critical if you are also hosting the site or building ecommerce Websites. (Remember, anyone can sue you for practically any reason, even a seemingly frivolous one.)

Arbitration
One way to avoid court costs and legal fees entirely is to have a standard clause stipulating that any disputes will be submitted to binding arbitration. (In the U.S., this is typically limited to amounts exceeding the maximum limit for small claims court.) You can specify who the arbitrator is to be (e.g., mutually agreed upon or a specific governing body) and who is to pay for this (generally, the loser).

Choice of Law
Choice of Law stipulates what State or Province's laws govern the agreement. As in basketball, it's always best to keep the home court advantage. Being sued is bad enough without having to travel out-of-state (or out of the country) to appear in court.

Cancellation
Whether it's a partnership agreement or a contract for work performed, it's always a good idea to talk about what will happen if one of the parties wants out. Cancellation or Escape Clauses discuss the circumstances under which either party can cancel and what happens if they do. For example, you might specify that neither party can cancel except by mutual consent, or that the party that cancels must do so in writing, within a certain number of days before the next project milestone, and/or that he forfeits his deposit or a portion thereof.

"Will This Project Ever be Finished?"

Milestones and Project Completion

As experienced Web professionals, we know that coding a site before the client has approved the design will likely force us into redoing some or all of our code if the client wants the design modified in any way. Clients, on the other hand, are generally unaware how changes to a previous phase affect the current one. Although I've been fortunate in this regard, I've heard stories of the owner or CEO suddenly deciding he wants to change the design he approved two months ago… when the project's a few days away from being completed.

Having clearly defined and agreed upon milestones can prevent you from finding yourself in this position. If you haven't broken your workflow down into phases, I highly recommend you do so. Some obvious phases are Design, HTML Production, Copywriting, and Site Launch. Consider each phase that will require the client's review and approval, and devise a method for him to "sign off" on each phase. These "sign-off" phases should be the milestones you specify in your contract. The design mockup review/approval process we already discussed is one such example. Signoffs on copywriting, functionally and project completion are other such milestones. If a client decides he must change something from a previous phase, that's fine -- so long as he understands that he may have pay an additional fee for the additional work you're required to do.

Also, be sure to define exactly what "project completion" means, otherwise you may find yourself continually updating the site because the client doesn't quite consider it "complete." To use a real estate analogy, take the client through a final "walk-through" of the site and note anything that needs fixing. (At this point, these should only be minor fixes -- don't allow him to change anything from a previous phase.) Any changes after the client has signed off on the final milestone should be considered site maintenance.

Recommended reading on this particular point is Web Project Management: Delivering Successful Commercial Web Sites [4], by Ashley Friedlein (Morgan Kaufmann; 1st edition, October, 2000)

"My Client Broke the Site and Expects Me to Fix It!"

Client and Third Party Site Modifications

Once, one of our clients placed a banner in the content section their site that was wider than the fixed width of the table cell, breaking the layout apart. Another client was updating her site and somehow ended up with all of the links referencing her C Drive. Admittedly, both of these issues were relatively minor, but any time the client or a third party makes page modifications, you run the risk of this happening. Don't put yourself in the position of having to fix a site for free because you haven't managed the client's expectations beforehand. Be sure your contract explicitly states that you are not responsible for any changes made by anyone other than yourself or your authorized agent.

"They Lost Their Email Passwords... Again."

Maintenance and Technical Support

If you haven't figured it out by now, one of the primary reasons for having a contract is to prevent you from doing additional work for free. If a client reasonably expects that a certain "something" was included in the deal -- and you didn't specify in the contract that it wasn't -- chances are that you'll wind up not charging for the work rather than risk having a disgruntled client. The word "reasonably" is of key importance here. If the client expects that the project was to include you walking his dog every day, no one would consider that "reasonable." But what if he expects you to help him set up his email accounts when the site is finished? What if he thinks you ought to come on-site and set them up for him? Suppose he expects you to do that each time he hires a new employee? I think you get my point.

Remember, what may seem obvious to us is not necessarily obvious to our clients. Your client may assume it's perfectly reasonable, for example, to expect you to make changes on his site whenever he needs it. He may assume the price he's paying includes that. You, on the other hand, might assume he ought to know otherwise. Don't assume anything. Put it in your contract.

Here's how the sales process of "verbal agreements" can help you write your contract. During the sales process, I'll ask the client how he'd like to handle the email setup. Can he do it himself? Can I walk him through it over the phone? Does he have a technical person to do it? One recent client told me he had neither the knowledge nor the means, and asked if I could arrange for someone to come on-site, which I did. I charged a modest fee to cover my cost and, of course, I included that in the contract that he signed.

"Will I Ever Get Paid?"

Payment Terms

I mentioned earlier that, when I was young and dumb, I failed to require a deposit on at least one occasion. That's because I didn't know then what I know now: that business ought to be based on mutual commitments, both before and after the sale. By giving a deposit, the client is making a financial commitment to engage your services. A deposit of 30, 40, or even 50 percent is not at all unreasonable. Any client that balks at giving some percentage of payment up front ought to raise a red flag.

Regardless of whether or not you require a deposit or the amount of it, your contact ought to state what the payment terms are. As we've already discussed, you can require some or all to be paid upon completion, you can attach payments to certain milestones, or you can require intermediate and final payment within a certain number of days.

I mentioned this earlier but it bears repeating. If final payment is "upon completion," or attached to any other production milestone, and the client does something that prevents you from completing that milestone -- such as failing to give you the content, or delaying design approval -- then you may wait indefinitely for your final payment.

Finding Good Advice

Finding a good attorney that fits your budget can be difficult. Here in the U.S., each state has its own State Bar Association that licenses attorneys to practice, but they cannot give referrals.

One option is to ask some of your clients or peers who their attorneys are. Don't be shy about calling around and asking what rate they would charge for such a service. Some cities also make legal resources available to residents. For example, where I live, I can get a free one-hour consultation with an attorney who donates his time.

There are also various pre-paid legal services, but be careful: some people have had negative experiences using these. Whatever you decide, keep in mind that, unlike do-it-yourself Web design, taking contract law into your own hands can have serious consequences if you don't handle it correctly.

Conclusion: Presenting the Contract

As I said before, my sales process is a series of verbal agreements, and I find this process works best when I've covered every aspect that must be covered -- including all of the contractual details -- in a face-to-face manner. You can waste precious time presenting the contract only to find that the client has taken issue with a legality (even a small one) that you didn't discuss beforehand, forcing you to renegotiate and/or submit another one. I recently found myself in this position because I failed to do this with a prospect. He had a problem with several points, some of which he had interpreted to mean the exact opposite of what they actually said.

There are many other things that ought to be included in a contract that go beyond the scope of this article. If you already have a contract, I hope I've helped you determine if it's missing any key ingredients. If you have no contract whatsoever, there are many resources online with which you can begin to piece one together, or you can purchase something like Proposal Kit or the Web Design Business Kit to obtain one. But ultimately, you'll want to consult with an attorney. It may be more cost-effective to have a contract already in hand, and let an attorney edit it, rather than have him draw one up entirely from scratch.

Contract Essentials Checklist

Here's a quick recap to use as a checklist against your existing contract:

1. Scope of Work and Scope Creep
Manage scope creep by specifying exactly what is and is not included so you can charge for the additional work, if appropriate.

2. Client Amends and Revisions
Be sure to specify the number of design comps you'll present and to limit the number of revisions you'll allow, or be faced with changes ad infinitum.

3. Dealing With Client Delays
Waiting for a client to provide content can be one of the most frustrating parts of any project. Be sure your contract addresses the issue of what will happen if the client delays, for any reason.

4. Who Owns the Website You've Built?
Whether or not to transfer copyright to the client is probably the most controversial subject among Web professionals. Whatever you decide, be sure you understand how the copyright laws work in the country in which you're doing business.

5. Legal Boilerplate Clauses
Boilerplate clauses such as Limitation of Liability and Choice of Law give you the opportunity to limit the amount of risk and liability you'll incur in the event that you're accused of breach of contract. Failure to include these can result in lawsuits over consequential damages and traveling to other States, Provinces or countries to defend yourself in court.

6. Milestones and Project Completion
Having clearly defined and agreed upon milestones, with "sign offs" on each phase, will prevent the client from requesting changes to a previously approved phase -- or at least from expecting that you should do it for free.

7. Client and/or Third Party Page Modifications
Be sure your contract states that you are not responsible to repair any damage done to the site by the client or any other party if they attempt to modify it (at least, not for free).

8. Maintenance and Technical Support
Unless you enjoyed repeated calls from clients who've lost their email passwords (again), make sure that the issue of Maintenance and Technical Support is clearly addressed in your contract.

9. Payment Terms
You don't want to be ambiguous about when and how often you'll get paid. A percentage up front and the remainder on or near completion date are standard practices.

[1] http://www.alistapart.com
[2] http://www.gotomedia.com/resources_books.html
[3] http://www.copyright.gov/circs/circ9.html
[4] http://www.amazon.com/exec/obidos/tg/detail/-/1558606785/qid=1121732331/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/104-4639241-8456765?v=glance&s=books&n=507846