You've hired someone to redesign your company website or build your awesome app idea and before you know it, the entire thing falls apart and you're left with a pile of unusable code and an empty wallet.

Why does this happen so often and what steps can be taken to avoid this?

1. You're looking in the wrong places

Heading to a freelance bidding site to find developers often ends in disappointment. That's not to say that there aren't great developers there; the problem is having to sift through 100 of them to find 1 good one. 

Not only that, but these types of websites are bad environments for designers and developers. Now I know you're thinking, "Why should I care?"  Because most of the great web designers and developers realized they can find better work elsewhere. 

If you insist on using these sites, accepting a realistic bid in the upper quartile of bids sometimes yields good results. But for many customers, that may undercut the main reason they're using the site to begin with. 

2. You're not paying your developer enough (kind of)

No one wants to accept that they're underpaying, but it's true all too often.  Ironically, if you paid a higher hourly rate to a more experienced developer, you might actually save money. 

Here's the deal, no high quality self-respecting developer is accepting McDonald's wages to build you the next best social media app. Sure there's some discrepancy between third world countries where the cost of living is lower, but this comes at a cost (communication barriers and potentially quality of work). 

Let's say you pay one developer $15 an hour and he or she takes 100 hours to complete your project while another is worth $80 an hour and will need 20 hours. Those projects are worth $1500 and $1600 respectively; you save yourself $100, right?  

Hold on their, Sparky. 

What's wrong with the above scenario?  First of all, your project is going to take 5x as long to complete assuming they're really working all those hours. Secondly, do you really think the result of those 2 projects is the same quality?  The cheaper one is not only inferior, but you'll end up spending even more to get it production ready. 

Think that's an overstatement?  I'd say at least twice a month we get a client who went down the cheaper route. Unfortunately, somewhere between 50-70% of the original code gets scrapped on average. This is really tough to watch a client go through this as what should have cost them $1600 is now getting closer to a total of $3000. 

3. You don't have the skills to determine the quality of work

This one is a tough point to reconcile. You simply don't have the technical skills to determine whether or not the code is of good quality otherwise you'd be doing it, right?

But you can see and use the website so it's okay right?  Maybe. But with bad code, bugs may not show up for months or even worse, they've left a potential loophole for hackers. 

Testimonials and portfolios are always the first place to look and easy for a non-technical person to deduce. Look good? Alright, let's move on to the less obvious stuff… 

a. Can I see some repos of your previous work?

"Repo" is short for repository, which represents a version controlled code base. Without having a developer to qualify the code, you're really caught in a catch 22 here. But what this question is really asking is, "have you really done this before and do you understand what version control is?"

If they flounder, can't come up with anything, or don't even know what a 'repo' is, you can probably mark them off the list. 

b. How will you manage updates and deployments to the site?

Websites are almost always ongoing projects that require updates.  Updates may seem minuscule until you realize that a single character out of place can cause the entire site to crash.

Now of course there are going to be bugs, even in the most professional environments, but what you want to watch out for is responses that include:

  • FTP
  • Updates from the admin panel
  • Which would you prefer?
  • I don't know

FTP'ing updates are indicative of amateur hour. This means they aren't using version control and more importantly, this method is super prone to error. One wrong move could crash your site and delete entire portions of your code. 

Updates from the admin panel might mean you're working with someone who isn't even a developer. Good cue to run the opposite direction as fast as possible. 

Finally, they shouldn't be asking you how to do their job. Unless you've given specific requirement, they should be telling you how they recommend going about deployment. 

Ideally a good response includes some kind of deployment workflow. This will vary a little bit from project to project, but pro answers may include:

  • Git deployment hooks
  • Capistrano
  • Mina

c. What's your workflow and review process like?

I'm partial to an agile workflow and while there are different types of agile workflows that can all run smoothly, the important piece here is that they do have some kind of workflow in place.

Organization is key to keeping project deadlines and happy customers.  Even for smaller projects, it's important to have an outlook on weekly tasks, who is responsible for a given task, and task dependencies that may block a project's progression.

If your web designer or developer is using some kind of project or task management system, chances of your web project getting completed correctly and on time are much higher.

At Echo 5, we use Asana as our task management system, which works great for us and our clients can either join in on Asana or continue using email or whatever system works best for them.  All emails still get forwarded through our task manager ensuring tasks and requests don't get lost in an inbox somewhere.

Asana Task Management

d. Are they asking the right questions?

You don't want a "yes man" when looking for the right person to handle your project. You also don't want someone asking you questions about what they should already know. 

Initially, you should be dealing with a lot of questions and feedback specific to your project, almost annoyingly so. This shows the developer or web designer has taken the time to understand your project's needs.

You will have to deal with these questions sooner or later. Even though it may seem to be a nuisance and you're eager to get started, bringing these issues to light earlier saves a ton of time and money in addition to fostering a better relationship between you and your developer. 

4. You have unrealistic or constantly changing expectations. (Undefined scope)

Scope is bound to change in any project. I have yet to see a single project that has zero scope changes. 

Unrealistic expectations

This article isn't about pointing the finger, but if you haven't given enough thought to what you need, you're going to end up with a pile of hot garbage.

Fluctuating scope

You can continue always continue amending the scope of your web product as you go. This is absolutely okay, but you should attempt to minimize this from the beginning, otherwise you can expect to go over budget pretty quickly. 

Any web designer who has even the slightest experience is going to give you a tight scope of project features if you're asking for a fixed price.  Sometimes people are surprised when they later add ask to add a feature and they're told it will cost more.  How on earth could your web designer give you a quote based on something they did not know?

Defining scope and feature sets

What's the solution?  Super simple. Write out a list of all the pages you expect to have and a list of things you expect to be capable of doing on each page. 

Wait a minute… isn't creating a sitemap my web designer's job?  Yes and no. A developer can help you refine your sitemap but you should be the one to tell them what you need. If you play the mind-reading game, you're going to lose. 

Probably the best solution here is to pay an experienced developer an hour or two to help you walk through your idea.  Even if this is just verbally going through the general user flow of your site, this severely cuts down the chance that you miss a feature in your scope.

5. You're looking for a "website designer" when you need a "web developer."

These two terms are used pretty interchangeably by customers. "Web designer" is kind of a blanket term for all things web. However, while this person may be perfectly proficient at building static websites, they aren't backend developers. 

If you're building a dynamic site, a web application, or anything that stores data, you're looking for a web developer.  The problem with finding someone who labels them self as a web designer may be lack of expertise or specific knowledge in a field. 

6. No project management when hiring multiple developers

This point generally only applies to larger projects whereas static websites don't usually require a handful of developers or designers.  But if you're building a SAAS application or something larger than your run-of-the-mill CMS, you're going to need multiple developers.

I've never fully understood the rationale behind this, but I suppose it's an easy trap to fall into thinking you can outsource different pieces of a project and act as your own project manager. 

Problem 1: Understanding project dependencies

The first problem is understanding general project progression and dependencies.  What do you need to fully build this project and what's the best way to get it done without major stalls?  

Being able to map out the points where back-end development, design, front-end development, an external API or any number of other moving pieces should begin takes experience. Without this, a 2-month project quickly turns into 6 months. 

Problem 2: Lack of separation between feature requests

The next issue seems to be a blur between where one piece of a project starts and another begins.  It might seem like having 2 developers work on 2 different pages is good separation, but this is generally a bad idea. While the pages themselves are separate, the stylesheet for those pages is most likely shared.  

If you're lucky, both developers are using version control and you'll end up with messy code. If you're unlucky, you get a battle between developers constantly overwriting each other's code while your budget becomes more inflated than Justin Bieber's ego. 

Big web projects need to be managed

Expecting developers to communicate without paying one to manage the others requires that you take on the role of project manager. If you're a senior developer and have the time, then by all means take the lead. Otherwise find a developer or company that can. 

Much like you (probably) don't understand where to begin or how to efficiently build a car from scratch, trying to coordinate a web app without a solid grasp of all the code involved will not go well.

TL;DR Summary

Finding a good web designer and/or developer is tricky.  With so many people masquerading as actual web developers, building a good relationship with one is not as easy as it used to be.

  • Spend time vetting and asking the right questions
  • Underpaying will cost you more in the end
  • Define the features you need beforehand and effectively communicate what you want out of the project
  • Make sure there's a project manager when multiple developers are involved

Did we miss anything?  Have any great methods of filtering out developers?  Leave us a comment below.