Ensuring Your Web Site Project Succeeds: Advice for Clients



Formatting Your Code
Why style matters

Universal Programmers Toolkit
Care and feeding of your code collection

Effective Proactive Debugging Techniques
It's all about the tools

Good Programming Practices
What to do (or not)

Banning Bad Bots
A short but effective script


The Joy of Specs
How to (almost) guarantee a successful project

Habits of Successful Freelancers
Advice for success

How to Become a Great Programmer
One easy lesson!

Bidding on a Stranger's Project
The basics

Freelancing 101 - Don't Send That Email!
Pick up the phone instead

Ensuring Your Web Site Project Succeeds
Advice for clients


How to Take Great Photos (And Fix Lousy Ones), Part 1
Composing and shooting your photos

How to Take Great Photos (And Fix Lousy Ones), Part 2
Editing and postproduction

Ensuring Your Web Site Project Succeeds: Advice for Clients


Sometimes web site projects fail because of the programmer but all too often they fail because of the client. Common reasons:



Learn the lingo. I can't tell you how many hours I've spent trying to coax clear requests out of a client. That process can mean a waste of time (at best), a waste of money, or even failure of the entire project. At the very least you should understand basic web site concepts and terminology and know the differences between a window, a dropdown, an input field, and other elements of an application or web site. Throwing around jargon incorrectly will greatly hinder the programmer from understanding what you want.


If you don't know the correct technical terminology, put it in terms you can understand. Avoid using generic words like "thing" and "box." If I had a nickel for every time an ignorant client described "the box on the screen" I would be richer than Bill Gates.



If you don't make a commitment to see the project through to completion then it will very likely flounder and may never be completed. If you haven't heard from the programmer in a while, send them an email or better yet give them a ring. By ignoring the project you are implicitly stating that you don't care, and if you don't care then the programmer will be less likely to care. A committed programmer who has your best interest in mind can drive the project, but that doesn't absolve you from your part. Remember, it takes two to tango.



Learn what you can should and shouldn't expect from your web site. Nothing is more frustrating for a programmer than trying to explain to a client that their expectations are simply unrealistic, whether from a technological, financial or time perspective.



If you don't have a good idea of what to say, be prepared to hire somebody to say it for you. Don't shoulder your developers with the burden of writing copy; they have enough on their hands as it is.



Trust your programmer when they tell you that you can't get features "a," "b" and "c" for budget "x." Either increase your budget, decrease your expectations, or be willing to sacrifice other less important features.

The Process

The process for building a web site is very similar to that of building a house. While the house analogy works well in most cases, there are other cases where it is a flawed analogy.


When building a house, several people are involved: architect, interior designer, plumber, electrician, roofer, painter and, of course, all the assorted construction workers. When building a web site, two basic types of people are involved:



Depending on the nature and complexity of the site, other roles that may play a more or less prominent part include:



While in the real world these are very specialized roles, in the Web world one person may fill any number of them. You may even find some people who run one-person shops.




Return to Kim Moser's Generic Home Page.
Copyright © 2023 by Kim Moser (email)
Last modified: Wed 09 January 2008 17:29:55