The Top 5 Ways to Avoid Getting Burned by a Web Developer

Bad code. Poor communication. Over-promising and under-delivering.

These are just the usual suspects of why hiring someone to build you a website can be a risky ordeal.

At Metacake, we spend a lot of time fixing bad code and remedying unmet expectations left behind by a former developer for our clients.  In fact, at least 40% of our development work is crisis clean up from past developer mishaps.

In doing so, we’ve noticed a few recurring stories of how our clients have been burned by bad web developers.

1. “The Disappearing Email Act.”

You know the experience – when details are chronically missed or it takes days to hear back about any little thing or emails somehow “mysteriously disappear” altogether?

Communication is absolutely key to the success of a project, both in execution and expectations. However, unfortunately, communication seems to often be the last priority for many developers.

How to avoid it? Talk about communication expectations up front and abide by them yourself.

It may be worth noting that, though developers are renown for poor communication during projects, this crisis is more often created by client’s poor communication. Low response rates, an inability to ask questions to better understand a project, and a general lack of attentiveness to emails is something that will kill a project no matter what side of the working equation it comes from.

2. “The Vortex.”

We recently had a new client come to us after pulling the cord on their previous agency. It only took them 1 year and 8 months beyond their deadline to realize that the project was becoming a vortex – constantly sucking in more money, more developers, and more time.

As it turns out, the problem wasn’t bad code or poor communication. The development team didn’t understand the scope of the project. Not on day one, nor on the day they were let go.

How to avoid it? Work with your developer to set milestones for EVERY stage of the project. This ensures that the full project scope and deliverables are clear from the get go. For help on this, see 10 Traits of Highly Effective Milestones.

3. “The Bosses nephew.”

Word to the wise. Don’t hire friends or family to build your website. Full stop.

If you don’t believe us, take it from our countless clients who have come to us after they signed up for “the friends and family discount” and got poor code that took three times as long as it should have.

How to avoid it? I believe we just covered this.  Don’t hire friends or family to build your website.

4. “I’ve been e-lanced.”

E-lance is a great tool, especially for small projects that don’t require any information beyond the initial proposal. However, it can be an achilles heal for many web development projects.

“They finish, we pay, the site breaks down, and they’ve yet to return an email.”
“They built our site 2 years ago and have yet to give us the passwords to our back-office.”

These are just a few of many issues we’ve had to navigate with clients who’ve been “e-lanced.”

How to avoid it? If you must use e-lance or any other online hiring service, filter your proposals ruthlessly. For more details on how to do this, see How to find brilliant outsourced workers quickly.

5. “The Guru Syndrome.”

Today, if you can read a wikipedia page and confidently recite it, you can be a guru at just about anything.

We’ve experienced far too many “guru’s” over-promising and under-delivering to believe anyone’s claims until we see a lengthy portfolio with references.

How to avoid? No matter how smart or creative that they seem or how much you like chatting it up with them, always call their references.

The moral of this story?

Even the simplest of website builds has the propensity to go epically wrong.

Take the time to do your due diligence. It will make ALL of the difference in the end.

Have you been burned by a developer before? If so, tell us about it below and how you would avoid it next time around.

Need help with your web project?

Get in touch with us

Leave a Reply

Your email address will not be published.