We’ve been hard at work developing a social network for dogs for one of our clients. It’s our first community site, so you know we were going to run into some issues. That said, we’ve learned some extremely valuable lessons from the project:
1) NEVER leave the testing up to your clients.
Over the course of the past year, we’ve gotten into the habit of giving our clients early access to their web development projects and then relying on them to communicate any bugs, deficiencies, or usability issues as we go about finishing the project. The reason for this was that we figured we’d kill two birds with one stone by reducing testing costs (time spent by client instead of in-house) while improving client experience (more time for revisions and more early input).
While this has worked quite well at times, lately it has turned a couple of projects into inefficient time drainers that result in massive scope creep. This happens because if a given client is allowed to test out a site while it is still in development, one of two things will happen:
A. Client sees all kinds of things that don’t look right or don’t work right and bombards the developer with changes to things the developer was already well aware of and was planning to change anyway. This results in wasted time spent communicating and extra frustration on both ends.
B. Client tells the developer that everything is great even though they haven’t even looked at the project in progress. Developer is then led to believe that certain aspects of the site are perfect. When the client finally does take a look much later on, they inevitably find things they want changed at which point the developer is forced to either revisit closed components of the project or to tell the client “no” - which leads time wasted and extra frustration.
The best way to avoid each of the above is by getting very clear instructions from the client at the outset and then completing development AND internal testing BEFORE moving on to the client revision stage. This doesn’t mean you can’t give access to your client during development - in fact I would say you should. Just make it crystal clear that client revisions will not be addressed until the internal testing phase of the project is completed.
2) Set your own standards - and stick to them.
Whenever developing a site for a third-party client, you’re likely to encounter a situation where you’re forced to choose between a complex option that your client may not even realize is beneficial and a simpler option that will be easier for yourself to implement and will initially be fine with the client. Whenever this happens, ALWAYS choose the best solution for the client - even if it means you will blow your budget on the project.
The truth is that even if the client doesn’t realize there and then that they need something, they eventually will. And when they do, they will also realize you skimped on the job. Don’t let that happen. In many cases, the difference can be repeat business from your client and all their references versus never hearing from them or anyone that knows them again. It’s that simple.
3) Set your client expectations at a reasonable level.
This is basic Service Provider 101 - but especially true in a field as mysterious and misunderstood as web development, where most clients have no clue what they are getting into and how to tell whether they got a great deal or ripped off. It goes something like this:
Say you have two clients that want a basic 5 page informational website with a working contact form and they have a budget of $1000 to make this happen.
You tell client A: “Not a problem at all, we’ll build you the site, give you unlimited revisions, a full money-back guarantee, and even throw in some on-page SEO optimization at no extra cost.” You then build the site as promised, but the client revisions turn out to be so extensive that your budget is blown and you’re eventually forced to cut the revisions short. Furthermore, as a result, you deliver late and do a rush job on the on-page optimization that you wish you hadn’t thrown in.
You tell client B: “We can do the site, but it won’t be easy. You’ll have to trust our judgement when it comes to design and layout. You’ll be encouraged to provide input, but be prepared for us to charge extra if your revisions are so extensive that they force us to blow our budget.” You then build the site on time as promised, cut the revisions short in order to stay within budget, and throw in some on-page optimization at no extra cost.
Which client do you think will be happier? Notice that in both cases, the client is getting the exact same thing. Where client A was expecting the sun and the moon, he just got a website after a lot of heart ache. Meanwhile, even though client B was merely expecting a functional website, he ended up getting the sun and the moon.
Under-promise + Over-deliver = Happy Clients + Happy Developers
4) Never assume that any open source product - even if popular - is bug-free out of the box.
We love open source software and products. The entire open source community is, in my humble opinion, the future of all information-based activity - be it research, software, journalism, even product design. This is why we always encourage our clients to go open source when it comes to any programming-related issues.
That said, it’s important to realize that any open-source product, even those that are well established with thousands of collaborators, are still imperfect at best. We recently built two sites using open-source products as a base in order to save time and budget. In both cases, we ended up spending more time fixing bugs within the out-of-the-box software then had we built the entire thing from scratch ourselves! This does not mean you shouldn’t use open-source products when developing sites, but it does mean you should plan for bugs inherent in the software that need to be fixed for the end-product to be finished.
In case you’re wondering, the products we had issues with are Virtuemart and Elgg. Both solid products with lots of support. But like they say, nothing in life is free!
5) Educating your clients is just as important as developing a quality site.
Anyone that owns and operates a semi-successful website knows that in order for it to gain traffic that converts, it has to be constantly updated, reviewed, tested, linked and massaged or else it gets left in the dust. Anyone that has developed a website for a third party knows that many people have no idea just how much effort is required to make even the best idea work at all. It’s up the the web developer to bridge this gap.
Whenever we take on a project, we always try to make this as clear as possible to the client BEFORE embarking into any work whatsoever. What we haven’t always done well, though, is properly educate our clients during the development process and, most importantly, after hand-off.
We recently came into a situation where we had built a social network that allows for users to add, move, and remove dashboard widgets, similar to how Facebook works. Little did we know that our client had no idea what a widget was or why his site needed them. Once he understood what we had accomplished, he liked it - but getting there took a lot of explaining on our part - and frustration on his part. This could have easily been averted had we been crystal clear with him at the outset as to what we were trying to accomplish with the widgets.
The most important aspect of this lesson is the post hand-off education. It takes a LOT to get a website from launch to success. Often, clients can feel overwhelmed once they start to realize just how little they know about marketing their website post-launch. In order to better prepare our clients and give them the best chance of succeeding, we’re now providing them with a tailor-made (by yours truly) Starters Kit. It explains some basic explanations of how to read analytics, strategies of how to get their website populated with quality traffic, and links to resources that they should read and understand if they are serious about making the site work. In most cases, not providing this type of information is like selling a car to someone without a driver’s license - it looks great, but they have no idea how to use it.
advantage to ccTLD’s. Add to that the fact that Sedo’s highest priced domain sale involved a ccTLD for the first time ever (
