Article
About the Author
John Tabita
John is owner and senior Web strategist of Jenesis Technologies. John specializes in boiling the "technobabble" about the Internet into information that business owners, entrepreneurs and executive decision-makers can actually use to make smart decisions about their Web strategies and produce a positive return on their investment.
Bulletproof Web Design Contracts
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, 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 (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:
- 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.)
- 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.)
- 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.
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:
- Prevent you from reselling the application to another client
- 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.