As a developer, I want to help you. It’s that simple. Whether you need help with a quick-fix, like squashing that pesky little bug in your code, or something much larger, like a full website build, I’m here to help.
Over the last ten-months I’ve helped more than 300 awesome clients complete nearly 550 projects and I’ve received just as many perfect five-star reviews from them along the way. The secret to maintaining such a high rate of success and keeping so many clients happy revolves around one simple idea — Quality.
Quality isn’t a one-way street either, understand that part of me helping you is also you helping me.
Now, the reality is that not every developer and client are a match made in heaven. Heck, I’m no exception to this rule either. As a developer myself, I too have worked with a few less-than-pleasant clients. You know who I’m talking about, the fun-sucking people capable of single-handedly making you lose faith in humanity.
Anyways, I’m not here today to rant about awful people, I’m here to share some tips and help those who outsource their projects become even better clients. I’m here to help good clients become great ones.
I’m not sitting over here building websites for myself — I prefer helping others make their websites better. But, in order for me to do that, we first need to establish a solid working relationship with one another.
Over the last ten-months as a freelancer, I’ve identified some of the most common red-flags that I’ve personally seen from clients. These are things that turn developers away from you and your project.
Personally, I want to see the good in every client, I really do. And I’ve found that most red-flag clients can be salvaged through a combination of honest conversation and education.
Are you the type of person who needs to know with absolute certainty that you’ll be starting out your next client-developer relationship on the right foot? Well, then you’re in luck, here’s seven things you can start doing today to establish yourself as a great client, one whom great developers prefer working with.
At the bare minimum, every new client knows they need help from a developer to complete their project. However, sometimes they’ll post vague project briefs saying something like — “I want a new website!”
Sure, I suppose you could argue that you do technically know what you want… But let’s be real, there’s no way an expert developer can provide you with an accurate estimate for you project with such little information. At this point the absolute best you’re going to get is some S.W.A.G.
If you’re not familiar with this acronym here’s what it stands for — Scientific Wild Ass Guesses.
Posting vague project briefs is an immediate red-flag for some developers, but why?
Well, for starters we know that we’ve got a lengthy Q&A session ahead of us in order to figure out what exactly it is that you’re looking for here. Now I’m not trying to rain on your vague-parade here, but there aren’t many expert developers willing to engage in these lengthy Q&A sessions just for the fun of it.
Don’t get me wrong here, I’m not saying that all developers are assholes and that you should expect to pay for the discovery process every single time. Personally I have no problem giving new clients five or ten-minutes of my time, pro-bono. But we’ve all got to draw the line somewhere, right?
So, if it’s looking like we’ll need to spend an hour together in order to get your task properly defined then it’s time we fire up a paid consultation. It’s an investment in your education, but we’ll explore that idea later.
You can impress developers right away by showing up with your to-do list in hand, featuring well-defined, specific requests, that you’ve clearly taken the time to think through. Also, it’s perfectly fine if you don’t know the exact technical language to completely communicate your request initially, at least you tried.
There are right and wrong ways to write your creative briefs, and I’ve outlined this before.
Just like you, developers have a finite amount of time each day to spend working. Surely they’re not going to waste their precious time attempting to decipher your vague requests and read your mind.
Your time and money clocks start ticking the very instant you start writing your project briefs. So please, do yourself a favor and avoid wasting both. Put some extra effort into writing your next project brief.
Back in February I published a “how-to” guide on writing better project briefs, you can read it here.
If this is your first time outsourcing a project then this one is especially important for you.
Surprise consultations are not fun for anyone, but scheduled one-hour consultations up front are great!
Before you dive head-first into that project of yours, a one-hour consultation with an expert developer is always a good idea. Heck, it might not even take the full hour. Keep in mind, this isn’t a life-sentence to work with the expert you’re consulting with either. Use this time to learn something about your website.
These short one-hour consultations will help both of us avoid any surprises later.
I get it — you’ve been burned before. Last time around, you went bargain shopping on another network and the $250 website they built for you didn’t turn out quite the way you’d hoped it would.
Unfortunately, when something seems too good to be true, it probably is.
It’s never fun learning life lessons the hard way, luckily it wasn’t an expensive lesson too, right?
This situation isn’t unique to clients either. Developers can get burned by clients as well. Imagine how awful you’d feel as a client if the distrust was reversed? Guilty until proven innocent isn’t fun for anybody.
So, if someone else screwed up your website, I’m sorry, but I’m still going to need access.
Only then can I fully assess the damage and provide you with an accurate estimate to properly repair it. Withholding login information because the last guy you hired did a cut-rate job doesn’t help either of us.
Imagine taking your car to the mechanic, if you want to know the price to fix your car then first you’ll have to let the mechanic take a look under the hood. Well, research is part of your developer’s job too.
Providing this access, even temporarily, will allow them to provide you with an accurate estimate.
I’ll cover the specifics of this in my next point, but generally: if we’re just starting to talk about your next project and you’re rude to me at all, I’m out. I’ve come to learn that things probably aren’t going to get much better. It’s better to cut ties early than subject myself to a review that brings my average down.
If you respect developers at all times, there’s no reason why they won’t return the favor.
As for lazy clients, here’s what I’m talking about: once in a while I’ll read a project brief that requires some follow-up questions. Sometimes, they respond with some form of — “read my brief for the answer.”
But that’s precisely the problem, the answer wasn’t there to begin with. At this point it feels like my attempt to understand your project is bothering you. Don’t be lazy, take your time crafting helpful responses.
Developers can be an overly-sensitive bunch, trust me. You might think you’re being helpful, when really they’re interpreting the things you say as — “I need to keep costs as low as possible.”
Here’s a few of the most common phrases that aren’t as helpful as new clients might think.
“This should be simple for an expert.”
Sure, maybe in the same sense that hitting a 95 mph fastball is “simple” for a professional baseball player? “Simple” is subjective, but if you can’t do it yourself, then it’s complicated enough to hire an expert.
You wouldn’t tell your mechanic an oil change is simple so you’re only willing to pay half-price, would you?
“This should only take an hour for an expert.”
The most ironic thing about this statement is how often it’s attached to requests that couldn’t possibly be completed in just one-hour by anyone. Please try not to tell developers how long their job should take.
Instead, kick back, relax, and let us do what we do best. If the estimate your developer provides isn’t aligned with your expectations it would then be appropriate to say something. This will give your developer an opportunity to explain why there’s a difference between your expectations, and their reality.
In other words, try to avoid being high maintenance or clingy. Nothing turns developers off faster than constant emails, Skype messages, texts and whatever else you use to ask for status updates every five-minutes. These interruptions just make it more difficult for us to get any actual work done.
It’s the oldest trick in the book, stop saying this — “if this project goes well, I’ll have more work for you.”
I already know what’s coming next, the negotiation. But my rate isn’t up for negotiation. I don’t salivate at the thought of your imaginary future business, and I’m not discounting my price in hopes of earning it.
Developing a website is a team effort, it’s me and you here. I won’t get involved in any power struggles.
Remember, developers are vetting you as a client just the same as you’re vetting them as developers.
If you’re a good client, we won’t hesitate to work for you again. In fact, we’ll actually be excited to help you solve more problems. In the second part of this series I’ll cover even more common red-flags we see as developers. Avoiding these simple mistakes will help establish yourself as a great client.
If it sounds like I’m picky when it comes to taking on new clients, well, that’s because I am.
I’m passionate about the work I do, and the clients I work for. If you need help, let’s connect right away!