Don't sign a contract for the development of a website until you read this.
In a special section devoted to e-commerce, published on July 12 in the Wall Street Journal, the editor wrote that: "Last December, when we first devoted an entire report to online commerce, it felt like we were capturing a trend that was just starting to become mainstream. Now, only seven months later, there's no question. It's mainstream. And moving fast."
I certainly agree that it's moving quickly, but like a precocious child, the developments aren't uniformly accelerated. One area that's lagging is the legal side-the contracting.
Broadly speaking, when we discuss e-commerce and contracting, we're really talking about two areas. One is, how do you form a contract online. That question deals with issues like, is clicking "I accept" on a website enough to form a legally binding agreement. (The answer is probably "yes," but it's really more complicated than a simple "yes" or "no" question.)
The second topic and the one for this column is more low-tech, but just as important. It's contracts for the development of an e-commerce website.
While e-commerce may be a pre-teen ready to grow-up rapidly, the agreements between otherwise sophisticated parties for the development of these sites are often infantile. They lack essential terms, fail to adequately address the most basic intellectual property issues and are often breeding grounds for expensive and nasty litigation.
It needn't be this way. Considering the costs and associated business risks involved, it must not be this way.
To give you an idea of the costs you should expect, according to a survey by the Gartner Group (a large and well-known computer-consulting firm), developing and launching an e-commerce site costs an average of $1 million. In their survey, the participants' spending ranged from less than $350,000 to more than $2 million to develop their sites.
It doesn't matter whether you're a website developer or a buyer of those development services, a mature, robust and complete contract is essential. It doesn't help either side to be $500,000 and three months into a development project to then discover that your basic conceptual design ideas are miles apart. It would be like thinking that a car dealer was special ordering you a 2-door sedan and instead delivered a sport-utility vehicle. Both may be quite nice, but you didn't want an SUV.
The Basic Agreement
At a minimum, a contract for the development of an e-commerce website should answer six questions. After each question, I've provided some examples of questions that you need to address in the agreement.
- What are the responsibilities of each party?
The agreement should specify who provides the content. Who will license any needed third-party software? How will credit card processing be handled? Who is responsible for obtaining required intellectual property releases or consents? Who will write and provide the Terms and Conditions of Website Use? Who will be responsible for necessary disclaimers? Who will provide for hosting of the site?
Who will develop the basic look and feel of the site?
- What are the procedures for feedback, mid-course corrections and change orders?
It's not possible to write a Website Development Agreement that completely describes the final product. If the agreement could do that, then the website would have to already exist. A good agreement provides broad outlines of what the site will look like and what it will do, while providing a framework for constant feedback, mid-course corrections and change orders.
For the process to work well, the developer and the customer must be in constant communication. This must be a collaborative process and the agreement must outline the procedures for this partnership.
A typical agreement might call for weekly status updates, a password-protected area where the customer can view the site as it's developing and a procedure for the customer to sign-off on discreet parts of the development process before it continues.
The agreement should deal with pricing issues if the customer requests significant mid-course corrections or outright changes in design. These things happen all the time. Remember, this is art not science and the agreement can't be rigid.
- What is the procedure for accepting the final website?
The agreement should have a procedure and criteria for final acceptance. It should have provisions dealing with issues like the functionality required, load time for pages (too many graphics can be a killer even if your user has a 56k modem), and browser compatibility.
- What is the price for the work and when is it paid?
It's basic, but I've seen agreements where the price was fuzzy at best. Is it a flat fee? Is it based on time? What's the hourly rate? What's the estimated time to completion? If it's an hourly rate deal, the agreement should require regular updates on time to date so that the buyer of the services doesn't end up with a shocking bill at the end. This is good for both sides since it prevents battles.
The agreement should specify when payment is due. Often, the parties will tie this to milestones like: development of the site outline, working model available for review, electronic and dynamic catalog working, and site available for final testing and review. Each of these milestones may call for a partial payment.
- Who will own the copyrights and other intellectual property rights in the website?
The agreement must, absolutely must, be specific in this area. Unraveling intellectual property rights in the face of an ambiguous agreement can be a nightmare. Imagine spending $1 million dollars and not knowing if you own the site.
This problem can be just as bad for the developer who may have a programming library that she's developed and uses on many sites she programs. A poorly worded agreement could conceivably create a situation where she loses the rights to her own library. She may have signed it away to the customer.
Here is the most important rule of thumb for a customer. Unless you have a written agreement that specifically and properly says that you own the copyright to your website, the developer will own it. It doesn't matter that you paid for it. It doesn't matter that you "figured" that you would own it because you paid for it. Nothing matters except a signed written agreement.
You're correct when you think that this answer is counter-intuitive. It is.
If you asked me to build you a table for $100 and I do, you clearly own it when I'm done and you've paid for it. This is simply not so in the world of intellectual property.
Now, you also know why the photographer won't give you the negatives to the wedding that you paid him to photograph. It's the same principle. The independent contractor who created the intellectual property (the negatives) owns it unless you have a written agreement that says otherwise.
- What are the remedies for delay or failure?
The parties need to strike a careful balance here. Developers often correctly point out that the customer causes many delays. They often don't provide the developer whatever it is that they're supposed to provide on time. Typical examples would be the text that will be on the site and logos and other graphics that will become part of it too.
Still, it can be the developer who's juggling too much work or is understaffed that causes the problems.
This is an area that can cause an otherwise good relationship to have problems. To help avoid this, your agreement should deal with time limits and any penalties for late performance in some detail.
This is Just a Bare Bones Outline
My purpose here has been to give you a basic outline for some of the considerations you need to take into account in creating an e-commerce site for your business. I don't have the space to be complete, but your agreement needs to be.
Don't slough off the contracting part as lawyers getting in the way. The contracting process is an important step that helps insure that the parties are on the same page before money starts exchanging hands. In many ways, it's the foundation for the creation of an e-commerce site.
Mark Grossman's "TechLaw" column appears in numerous publications. Mark Grossman has extensive experience as a speaker as well. If you would like him to speak before your group or corporate meeting, please call (305) 443-8180 for information.
You can find a TechLaw archive at: www.DeWittGrossman.com.
If you have any comments, please send them to MGrossman@DeWittGrossman.com.
Disclaimer: The advice given in the TechLaw column should not be
considered legal advice. This newsletter only provides general educational information. You must never rely upon the advice given here. Your individual situation may not fit the generalizations discussed. Only your attorney can evaluate your individual situation and give you advice.
Except as provided below, you may feel free to forward, distribute and
copy the TechLaw column if you distribute and copy it without any changes and you include all headers and other identifying information. You may not copy it to a Web site.