How to Choose the Right Web Developer
- Discuss Your Site Plan with at Least Three Developer-Candidates and Obtain Written Proposals
- Get the Proposed Statement of Work in Writing
- Evaluate the Developer Proposals and Select Your Developer
- Monitor the Development Progress
- Establish Procedures for Ongoing Site Maintenance
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Following the Web development project steps shown in Table 1, we have now completed steps 1 through 8. (See my earlier article "A Planned Approach to Web Development" for a discussion of those steps.) Assuming you have decided to hire a Web developer to assist you in launching your Web site, how do you go about choosing and then managing the developer? The next step is finding several developer-candidates and spending a little time with each before deciding which to hire.
Table 1 Steps to Follow in Your Web Development Project
-
Decide what exactly you want from your Web site.
-
Decide on a structure for your site and develop a rough site plan.
-
Decide what interactive elements you need.
-
Decide what graphics you want to include.
-
Write the text for each page in your site.
-
Determine your budget and timeframe for the project.
-
Establish your Web infrastructure.
-
Collect your toolkit.
-
Discuss your site plan with at least three developer-candidates and obtain written proposals.
-
Evaluate the developer proposals and select your developer.
-
Monitor the development progress.
-
Establish procedures for ongoing site maintenance.
Discuss Your Site Plan with at Least Three Developer-Candidates and Obtain Written Proposals
Finding a good Web developer is a lot like finding a good consultant of any sort. Ask for referrals from your business acquaintances who have Web sites. Review the Yellow Pages listings for Web developers, and/or go online to look for qualified Web developers. One excellent online site to mine for a Web developer is eLance. Here you can request quotes, compare credentials and obtain references. A similar site, but one that displays less pricing information, is Guru.com. I like eLance because it functions as an open market and you can see what folks are bidding for each kind of work. The average job size is also smaller in eLance, making it more likely that you, as a small business person, will find a developer with an interest in your relatively small job.
Decide on a method for screening candidates, then run everybody through your screen and see who is left. Too many? Increase the requirements incrementally until you have just a few who measure up. Finally, check the references of your finalist candidate and move on if you get even a hint of poor service.
Below are some suggested qualifying questions, with explanatory comments.
What is the smallest job you have done in the past year?
Some developers avoid entry-level Web sites, preferring the heavier clients. Find out if your project is in their target range. Heavyweight developers have a much higher overhead, which you can easily avoid paying by choosing a Web developer whose focus is on jobs the size of yours.
Who does the work: you or a staff member, and is your staff member an employee or a sub-contractor?
Web development is mostly a cottage industry. Sole practitioners (like me!) join forces with other loners and small shops when necessary to tackle larger jobs. For your first Web site, I actually do recommend a tiny shop with just one or two people who do everything. If your projects later dictate that you hire a developer with more horsepower, you can always move up.
These small shops offer the primary benefit of lower overhead, and as a bonus you will get service that is more personal. That said, however, I must add that tiny shops are of highly variable quality, depending entirely on what the owner knows and how the owner chooses to operate. If you do decide to work with such a vendor, make doubly sure you get and check lots of references from current and prior clients.
If you have the time in your budget, you might consider using a brand new Web developer who is just starting out. Once you identify a developer as such, have a heart-to-heart, with the purpose of extracting a lot of great work in return for a very little money and the opportunity to create a good reference that the fledgling developer can then use to secure new, more profitable business. Point out that you are taking a considerable risk by hiring an unknown developer, and so you should be compensated by significantly reduced prices. Do not be afraid to dicker. Offer a quarter to half of the developer's first suggested rate.
What development tools do you use?
Professional Web developers virtually all use some sort of productivity tool such as FrontPage or DreamWeaver as their primary development tool. Any Web developer who claims to use only a text editor will just cost you unnecessary money through inefficiency. Go someplace else.
When could you start and finish my job?
Always find out how busy your candidate is. You do not want to find your project queued up for six weeks before it even gets touched. Nor do you want your Web developer to begin right away, only to shelve it for three months while dealing with a big piece of work already in the pipeline. A simple brochure Web site ought to be done in 8 to 15 man-hours if you hand off the pieces I have suggested. Five to ten workdays is more than ample time to allow for completion of such a site. Larger, more complex sites will of course take longer.
What questions do you have for me?
Ideally, your candidate will ask all the following questions:
Why do you want a Web site, or what do you want it to do?
Do you have a domain name?
Where do you plan to have your Web site hosted?
How much of the work do you want to do yourself?
When do you want it completed?
What is your budget?
A good Web developer who has your best interests in mind will ask these and more questions, probing to determine how best to meet your needs. Any developer-candidate who does not ask these basic questions is probably working on a set of unexpressed assumptions about what you need or want. If these assumptions are challenged later in the game, your project can suddenly take an unexpectedly sharp turn to the ugly.