Everybody lies: either knowingly (through deliberate deception) or unknowingly (by not revealing important information, unconscious misdirection, or a thousand other stratagems). Lies may make people feel better, but they are also major obstacles to communication, and erode the relationship between the client and the freelance web developer.

The central misconception most web site clients have is related to the very reason they want a presence on the web in the first place: its ubiquity. Many clients see the web, and the tools used to create it, as something commonplace, so their assumption is that developing a website must be easy, and cheap. Curiously, they don’t tend to have this association with other media: very few people believe that writing, designing, setting, printing and binding an illustrated hardback book should be easy just because they have Microsoft Word.

Here, we’ll discuss lies typical to the web development process; later, we’ll go in-depth on solutions to these common problems, which are usually resolved by writing a good contract and maintaining an open line of honest communication with the client.

Typical lies told by developers and clients include:

“I can’t tell you exactly what I want, but I’ll know it when I see it.”

Answer: “Once you have a concept or a purpose for the site, I will be happy to work with you.”

There are many, many poorly designed websites out there, and clients are notorious for their tendency to add features, gimmicks, and distractions with every conversation regarding their goals for the site. In addition, many clients simply work from what they know, and provide abstract guidance in reference to that knowledge: “I’d like the site to be like MySpace, but cleaner, like Facebook, and with videos like YouTube”.

As a developer, it is your role to guide the client. The client is not, generally speaking, a designer: that is what they are paying you for. Input from the client should be respected, but they should also be firmly told why having a 30-second Flash intro, or an animated GIF of their puppy running across the screen, is a bad idea. A good client is a well-educated client, and that education is your responsibility.

Attaining a needs analysis from the client, and using that to write a clear mission statement for the site – a dozen words summarizing the purpose of the site, containing a goal that both the client and developer agree to – is vitally important to clarify the work ahead of you.

Generally speaking, “I don’t know what I want, but I’ll know it when I see it” is evidence that the client is both high-maintenance and a poor communicator. For contracts less than $10K, a client gets one mockup, and one, possibly two, revisions or variations of that mockup: any more than that wastes the time of both client and developer.

“I can’t pay you right now, but once the site is finished money will start rolling in!”

Answer: “Once you have money, I will be happy to work for you.”

This common wishful thought is a holdover from the dot-com era when people worked for stock options. Don’t do it. (Also, don’t work for products, discounts, etc). Cash talks – everything else walks.

“How much do you charge per page?”

Answer: “I don’t. I charge by the hour.”

Charging “per page” is a losing proposition, as the length, size, and content of a web page is fluid, and can alter from one conversation to the next. It is far better to make an estimate of the total number of hours to create all the content of a site, regardless of the number of pages.

“I can’t believe your rate! My 15-year old cousin could do the site for far less!”

Answer: “Then you should let your cousin do the work. I’ll be here in six months when you come back.”

There is a tremendous temptation to lower your rate and underquote the time it would take to complete the site, especially on your first few contracts, because you want to impress the client or because you overestimate your own ability. Doing so undercuts your income, to the point at which you would earn a better hourly income cleaning toilets.

“You can have this done in two weeks, right?”

Answer: “No, it will take me x hours, starting from the moment you provide me with the content.”

As a freelancer, your hours are your own. It’s certainly possible to complete a website that would take 60 hours of work in three days, with minimal sleep, but that’s not an experience I would recommend. Generally speaking I build time estimates from the assumption of a 40-hour work week, but your weekly hours may be different.

In addition, most clients assure you that they are going to provide some content for the site: photographs, body copy, etc. Many clients are poor in actually providing this information, and often will not understand that the website cannot be completed without it.

For that reason, if a client is contractually obligated to provide content, I do not provide a completion date for the website, but a statement of completion a certain amount of time after the delivery of content. (For example “Two weeks after delivery of all photographs and body copy”.)

“Why should I pay you this rate? You’ll be learning on the job. I shouldn’t have to pay for that.”

The reality is that as a developer you will always be learning, with every site you make: technology changes rapidly, and there is always more to learn. If a site features technology or a technique you are unfamiliar with, be honest with the client, and tell them “I don’t know how to achieve this, but I will find out how it can be done.”. It is very unlikely that research will take the bulk of your time on the website, and thus your rate should not change. If the client thinks they could do a better job for themselves, let them.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.