Techies, like so many others, don't like contracts. Why? Because they don't realize the reason for a contract. It's not to confuse the parties or ensure permanent employment for lawyers. A contract exists to clearly spell out the expectations of the parties. Think of it as a map, the guide to getting there.

Recently, Susan, one of my clients (not her real name), contracted with Unorganized Grocer (also not the real name) to develop a website with an organic, friendly, earth "look and feel."

Unorganized Grocer provided reams of content—about three weeks later than he said he would. The content was full of typographical errors, which Susan wound up correcting because Unorganized Grocer took too long. Every time Unorganized reviewed the draft site, he made changes: to the site, to the design, to the content, to the graphics. "Oh, just add a button here, tweak this graphic just a bit."

And then there was the ISP.

Eventually, the project was months behind. Suasn tried to pay Unorganized to go away. That's understandable, considering how much money she was losing on the project. But Unorganized refused to leave.

Finally, Susan called me. We were able to resolve the contract, but only at a loss to Susan. Unorganized didn't make out too well either.

How can you avoid these situations?

Two things create the client from hell: lack of communication about the project before the project starts, and poor contracts.

Here are some guidelines to use in writing a web design or customized software development agreement:

1. Avoid the Frankenstein Contract. A Frankenstein contract is a contract quilted together from bits and pieces of other contracts. If you are a web designer or software developer, put together your own form contracts that are clear and completely set out the parties' expectations. By now, you know what the key issues are. Make sure your contract addresses them.

2. Describe the Project. Every web or software development agreement should have two types of project descriptions: a narrative description and a technical description. Include the narrative description in the contract.

The technical description may not be developed until after the contract is signed. Make sure that each party to the contract also signs the technical description. The technical description should be very specific and technical, spelling out the following:

• art work
• hardware and software specifications
• performance specifications
• a detailed test plan
• the deliverables
• all input data (such as type, size, range of sequence diagrams, and definitions)
• text, images, and audio and video clips, if any
• a layout of the navigation of the site.

After each party signs the technical description, make no changes to it, unless the changes are made in accordance with the procedure for change.

3. A Procedure for Changes. Include a detailed procedure for change to the project description. Remember that once the technical description is agreed to in writing by each party, there are no changes unless pursuant to the procedure for change. A good procedure for change avoids so many problems: preventing "scope creep" and cost increases for which you are not paid.

4. Cost Estimates. Try to avoid a fixed-fee contract. Instead, give a cost estimate, with the understanding that the price may change. To allay client concerns, spell out the reasons why the fee would increase and include a requirement that you notify the client if an increase is likely.

5. Payment Schedule. Make sure you get paid! Include a payment schedule tied to objective deliverables. Make sure that you have the right to stop work if you are not paid on time. Set out the consequences of a work stoppage.

6. Delivery Schedule. Identify the deliverables and include a schedule with the times for delivery. Make sure you indicate the client's deliverables. Include a mechanism for changing the delivery time if there is a delay by one of the parties.

7. Escape Clause. Include a reasonable way to terminate the contract if the parties are unable to agree.

8. Warranties. Include a promise from the developer that the software and website designs are not infringing any third-party rights. Include a promise from the client that the content is likewise noninfringing.

9. Testing Plan. Make sure that you have an objective test plan that states that if the software or website substantially complies with the test plan it is deemed accepted. Be sure to define "substantially," and set out a procedure for testing and remedying any material defects.

10. Special Problems Areas. Make sure you address special areas that cause problems, such as the following:

• Graphic design. What happens if the client keeps rejecting graphic designs? Make sure the contract addresses subjective areas like this.

• ISP and other third-party providers. What happens if, after repeated efforts, you cannot work with the ISP or other third-party provider? Make sure that you are paid for excessive time spent working with a third-party provider.

• Content. Spell out the amount of client content and the consequences if the content is not web-ready when it is delivered to you.

These are just some of the considerations in putting together a contract. A good contract does not have to be verbose and full of language that no one understands. It should be readable, spell out the project, and clearly state the expectations of the parties.