grumpy finger puppet couple

In the past month, I’ve had two new clients come to me because they were deserted, let down, or under-valued by their current web developers. Both of them had existing contracts with these developers, and yet both of them were so fed-up that they were ready to walk away from existing relationships, financial investments, and in one case, established technical infrastructure, just to avoid dealing any further with these other firms.

This should never happen.

Every business relationship should begin with some basic professional understandings that make the process transparent. While you may or may not understand all the things that go into building a web site, a good development house will walk you through enough of the details that you can monitor the success of the project with some accuracy. Today I’ll be sharing the pieces of your agreement with your developer that should be in place before the project begins — otherwise, you’re likely to be unhappy with the way it ends.

Price and Deliverables

This seems like a pretty simple thing, but I’m always surprised by how many people tell me that their developers gave them a price for “doing” their web site without detailing all of the things that are involved in that “doing.” No one ever gives you a price for “doing” anything without details. You can’t get a party catered without telling the caterer how many people are coming and what kind of food you want. You can’t get a custom suit made without agreeing on the material and telling the tailor how tall you are. The same goes for a web site. You and the developer need to have as close to the same picture in your heads as possible.

Examples of the kinds of things that should be in writing and crystal-clear to you both ahead of time are:

  1. How will you agree on a design for the site? Are they giving you a design and you can ask for changes? If so, how many changes? How long will the design process take? What if you need more changes than they expected — will that be free or cost you more? What if you change your mind about colors later? When do you have to decide on the design and what is changeable later?
  2. What are all the things the site will do beyond show people words and pictures? We’ve discussed this before — extra functionality can be easy or very difficult to implement. You might think all web sites come with a contact form, but your developer might think of that as something extra for which she charges more.
  3. How many pages will there be on your site? Who is putting the content on those pages? Who is writing the content for those pages? Some web consulting firms have writers on staff, but do they know your business well enough to write the copy for your site? If you’re doing the writing, are you also pasting that writing in to the content management system (Joomla, WordPress, etc.), or are they doing that? How are you supposed to deliver the writing to them?

Timeline and Deadlines

calendarIf you have a deadline in mind — however far away that might be, even so far off that you think there’s no way your developer could take that long to build your site — you must communicate it clearly to your developer and make sure that they agree to deliver by that date. Your developer should then be held to it unless you have agreed in writing to circumstances that would allow for missed deadlines. Here are some things that could make your timeline shift, and if they occur, you should know before you start what the consequences might be:

  1. What if you don’t agree on a design right away? Is there a time by which you need to agree, otherwise your developer can’t make the deadline?
  2. What happens if you change your mind about design, site architecture, the order of items in your menus, or some other aspect of the site that you agreed to previously? How long will each change take, and how does that impact the final deadline?
  3. What if you don’t deliver the content when the developer needs it? Do you know when he needs it? How much content do they need, and when?


Here’s where what your developer knows and what you know can be very, very different. Your developer may assume you know all kinds of things about the technology that goes into building a web site, and you may assume that your developer will tell you everything you absolutely need to know ahead of time. These assumptions are both dangerous not just because they are often incorrect, but because they can eventually lead to a last-minute panic about hosting. (Side note: if you’re not sure you understand what is domain hosting, web hosting, and content management, you can learn the basics from this infographic.) Here’s what you should be sure is clear before you start:

  1. Do you own your domain name? If not, are you going to purchase it yourself or is your developer going to do that on your behalf? If your developer is going to do that, will they own it, or will you?
  2. Have you paid for web hosting? If so, will the servers at your web hosting company be compatible with the kind of software on which your developer is working? If not, will you be purchasing hosting based on your developer’s recommendation, or will she be purchasing it on your behalf? If your developer purchases it for you, will you be paying your hosting fees to your developer directly or to a third-party web hosting company?
  3. Are you using a content management system? Which one? Will your developer install it for you? Is the content management system portable to another web host if you ever wanted to move your site? Are there any limitations of the system you and your developer have chosen?

Post-Launch Support

wrenchWhen your web site launches, you may have some expectations of your web developer that are not actually written into your contract. Then, the developer who was so responsive during the site-building process might suddenly stop responding quickly — or at all — to your email messages, and you are left with questions you were waiting to ask that now go unanswered. There are lots of things that may come up after your site launches. Knowing ahead of time what you can expect later is important.

  1. Will your developer train you on how to make updates to the site? If so, for how long? Will there be written documentation included? What if you think of a question you need to ask later — is there a charge for that?
  2. Will your developer answer your questions or fix things you didn’t notice until after launch? Is there a charge for that, and if so, what is it? How high on your developer’s priority list will your questions be? Are they going directly from your project into another, leaving you without anyone to ask? If so, do they recommend any other people or online resources for your questions?
  3. If you need upgrades or want to add features, will you be offered priority in your developer’s schedule? What is his availability in the coming months?

It’s just a mess when you have to start over with a new developer mid-project. Clear, written instructions are always good insurance against that type of disaster. Projects can become challenging even with the best of plans, but if there is a plan for how to handle changes, bumps in the road, and redirection, everyone can move forward together.