Finding a good, reliable web developer can be like finding a good, reliable mechanic. They exist, but they're not always easy to find. There are plenty of reasons for this, ranging from the fact that many good developers don't need to solicit new business to the fact that it's hard to spot someone who is technically competent when you're not a developer yourself.

As difficult as it may be, finding a good developer isn't impossible. You can spot whether the developer you're considering hiring, or have already hired, is a 'good one' by looking for the following things.

Before Engagement

He or she:

Is responsive. I've seen it time and time again: clients who hire a developer that is less-than-responsive during the courtship process, only to find out that when the project begins, he or she is even less responsive. It's not surprising: if someone is less-than-responsive when they're trying to win your business, why would they be more responsive after you've given it to them?

Has references. Unless you're specifically looking for someone who is new to the business (for whatever reason), a good developer will be ready and willing to provide solid references to you.

Has a portfolio/CV. While it seems like a no-brainer that a developer should have a portfolio or CV, you'd be surprised at how many clients I've encountered who have hired a developer based on a few simple words easily muttered: "sure I can do that."

Gets down to business. Serious developers will ask you to sign an agreement (if you don't present one yourself) and bring up payment terms as soon as your discussions get serious. Sometimes individuals who haven't been in the client role before will be scared by this, but it's actually a sign of a professional.

After Engagement

He or she:

Treats you like a customer, not an annoyance. Anyone who you're going to be paying should treat you with respect. After all, you're paying their rent. If your new developer starts acting entitled and like he or she is doing you a favor, watch out.

Isn't interested in nickel and diming you, but lets you know when you go out of scope.
As a developer, there's a fine line between being unreasonably stingy (and unhelpful) and permitting a client to go too far. Look for a developer who doesn't have a habit of saying point blank "that can't be done" (few things can't be done), but who also isn't afraid to tell you when something is out of the agreed-upon scope.

Keeps you up to date. You should not have to chase down your developer to get a status report. Obviously, you probably don't need a status report every other hour (you don't want to be a legitimate pest) but a good developer will be proactive in letting you know where things are at, especially when milestones are approaching.

Delivers, and on time. Needless to say, a good developers will deliver what you asked for within the agreed upon timeframes. This said, I've met more than a few people who continue to work with developers that don't always deliver an on-spec product or on time.

At the end of the day, finding a good developer requires that you have certain expectations. Obviously, expectations will vary depending on your needs, and your budget. But if your expectations aren't met, your search should continue. Don't settle for mediocrity.

Patricio Robles

Published 16 August, 2010 by Patricio Robles

Patricio Robles is a tech reporter at Econsultancy. Follow him on Twitter.

2642 more posts from this author

You might be interested in

Comments (9)

Save or Cancel

Rob Drummond

I have found this to be a big problem - customer-centric webmasters are certainly hard to find!

For specific projects I have had some success finding good people on elance, although you have to do a lot of filtering and make sure you are very precise in the project description and the way you manage the project.

almost 8 years ago



Excellent post. It also contains good advice for developers on how to provide good customer service (ie how to be a good developer)

almost 8 years ago


Sim Stewart

Great post and very true on lots of points. It would be interesting to hear a developer's view on their client's behaviour as a response to this post. I think an article on how not to drive your web developer insane might also be useful. As you say many of us don't have much idea about web development and this can lead to a lot of problems understanding a job's scope, timings and limitations.

almost 8 years ago


Nik Makris

As a developer, one of the biggest bugbears I have is trying to get the scope of a project nailed down with the client and then trying to stop additional requirements being added well into the development of the project.

Functional specifications are only useful if a client actually reads and understands them, if they promptly sign then off with no comments/changes then alarm bells should start ringing.

I find a lot of clients have trouble visualising what they want, but they generally know what they don't want, but its often its too late by that time.  Wireframes and prototypes are useful for trying to avoid this scenario, however they increase the cost of the project and make proposals appear more expensive on the surface.

almost 8 years ago


Mike McDonald

In such a competitive business, it's amazing that anyone who doesn't treat the customer well and manage projects efficiently is actually still in business at all. I know there are dozens of local designers/developers ready and waiting to grab any of my clients away from me the minute I slip up. So my job is to keep those clients happy by treating them properly and doing what I say I will do, when I say I will do it (if not sooner). 

almost 8 years ago

Francesco Astolfi

Francesco Astolfi, Web Marketing Manager at Web Copywriter

Yes, finding a good web developer is very difficult, especially because is not so easy to match expectations and and skills..

almost 8 years ago

Ed Stivala

Ed Stivala, Managing Director at n3w media

Some very good points Patricio. 

Perhaps the underlying problem is that being a great account manager and project manager requires a different skill set to being a good developer. Whilst a client may find a dozen really good developers in terms of their technical capability, if they are too have a great project experience, they need to find one that also has account management and customer service expertise. This, in my experience, is a MUCH rarer beast.

Having said that I do appreciate and agree that getting some of the basics closer to acceptable shouldn't require world class account management skills.

Clients need to appreciate what they are NOT buying. By hiring a freelance rather than working with an agency almost certainly reduces cost. However that cost is reduced because you are taking people and skills out of the equation. If the client realises this then they may have a better appreciation of the kind of experience they are likely to have to endure in return for saving money. 

almost 8 years ago



Nice article Dude,you have write some wonderful tips.This tip, while closely related to the buzzword concern, is not quite the same but it is equally important if not more so. After you identify potential buzzword issues, the next step entails doing some research on key development needs. This is very challenging, because typically there's pressure to get the website done. Often, that means cutting corners on research—and ending up in trouble down the line.Thanks for great tips.

almost 8 years ago


David Stewart, Senior Internet Developer at G24

Some very good points here for all freelance/contract developers to take note of. They often forget who their client is.

I have experienced this on both sides and from the developers’ perspective, we routinely see a number of major problems:

1. under speccing. Agile development - evolving towards your requirement, rather than defining it in advance - is quite acceptable, but clients often expect quotes based on a vague set of requirements. A good developer will discuss requirements with the client and produce at least an outline spec. If this doesn’t happen, clients should expect an inflated quote to cover the unknowns. Poor spec = high quote or additional charges.

2. bad comms, poor documentation. Document all discussions and their outcomes. Use online collaboration, task and project management tools. These can be very quick and easy to use and are vastly preferable to leaving important information in people’s heads, on their notepads, lost in their inboxes, buried in numerous word docs or spreadsheets - there is no excuse for this kind of shambles.

3. optimistic timescales. Time estimates for software development projects are almost as wildly unrealistic as cost estimates. There still seems to be a fundamental misunderstanding over how complex and time consuming this work can be, particularly when it gets done properly. Developers can be just as guilty of this: they can understate the work involved, in order to secure the project, then worry about the implications later. Be realistic and don’t fall into trap no. 4...

4. corner cutting.  When time and budget are under pressure, rather than re-negotiate, scale back the project or phase it, clients (and developers) often end up cutting corners, which invariably means that non-visible but important things like security, testing, usability, documentation, etc get dropped.

5. failing to budget or schedule for maintenance. Most web sites are living growing things which need maintaining - this applies to backend code as well as content and ongoing SM. Much like a car needs regular servicing, web sites need checking over and updating for security, performance and stability reasons. Plan and budget for this, or ignore it at your peril.

6. abandoning a good working relationship with your original developers. Some clients show an appalling disinterest in paying independent developers regardless of how satisfied they are with the work. Aside from the moral issues - being fair and honest with people, not using self-employed individuals to help ease your own cashflow - you might need those developers again in the future to work on the same or another project. If the accounts department has been fobbing them off for weeks or even months, you might find those people have moved on and will prefer not to work for you any more. Bringing new developers into an existing project from cold is usually more time consuming, costly and problematic than if you had continued with your original team. Don’t let your accounts dept. burn bridges with useful developers.

7. leaving an account manager to assume the role of project manager. A good PM should work closely with clients and developers understanding all sides deeply and ensuring that avoidable mistakes are not made. Account managers not experienced or interested in a true PM role might struggle to meet the needs of the project.

I could go into a lot more detail, but...

almost 8 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.