This post is based on a talk I gave at the “Finding a developer” event, by Enterprise Nation on 13th March 2014.

The current state of play

There are a lot of great developers out there looking for work, and a lot of great clients looking for developers. Using tools like Elance, Coding Cupboard, Google, oDesk, meetup.com, LinkedIn, etc. makes it easier than ever to find developers.

But things aren’t that simple. I feel that so many potentially great partnerships are thwarted at the first contact.

I receive anywhere between 3-10 enquiry emails per week. Most of these emails make really basic mistakes that make either the client, or the project, seem unappealing. I wonder how many great projects, and clients, have fallen through the cracks as a result.

Where we want to get to

I want to help great clients avoid making those basic mistakes, and find a great developer to work with. I want to give potential clients a framework to use that will pique a developer’s interest, and start a long and successful relationship.

How we’re going to get there

I’m going to give 7 tips covering the most common mistakes. I’ll show you what you need to include and what you should leave out.

Before that, I’m going to run through some advice for the stages before you send out your enquiries. This will probably take a change in your thinking, but it will provide a solid platform for future discussions and a healthy relationship.

A change in thinking

Possibly the most important bit of advice I can give is to change the way you think about the client-developer relationship.

Trust is key

Firstly, I believe that most clients are somewhat sceptical of developers, and there are good reasons for this. It’s a largely unregulated industry, and there are plenty of unscrupulous characters out there. Your short-list of developers should be people that you trust.

How do you trust a stranger? Do your research. Follow up on references, follow them on Twitter, LinkedIn, or at meetups. By the time you contact them, you need to trust them.

A relationship of equals

Secondly, hiring a developer isn’t like hiring an employee. This is a relationship of equals. Think of it like hiring any other professional – an accountant, or a lawyer for example. Yes, you are paying them, you are the client and this is your project.

Each party needs to have respect for the skills, knowledge, and experience of the other.

Good developers are in demand, and in control

If you think of these enquiry emails like you would if you were applying for a job, you’ll get it right. Good developers aren’t desperate for work, but the chances are you’re desperate to find a good developer. You need to pitch to them.

Before you send the first email

Give yourself time

Finding a capable developer, who you trust, will take longer than you think. First, you have to go through the process of finding one. Once you do you’ll probably have to wait for a month or so – good developers are in demand and are busy. Get started as soon as you can and make your deadlines realistic. A rushed project won’t be a good project, no matter how good the team.

Understand the process

The best clients are the ones that have invested some time in understanding what the design and development processes looks like. Not only will you be able to understand what the developers are talking about, it will also give you a better understanding of the timescales and budgets involved.

Know your project

The most important part of all. Have a deep understanding of what you’re trying to build. You need to know your project inside out. It needs to be well thought out and well documented.

What developers need to know

Is the project real?

Is this something that you thought of this morning while walking the dog, or is there research and planning behind it? Developers aren’t going to want to spend their time fleshing out your idea for you.

Do they have the skills and the time?

You need to give enough information so that the developer knows whether or not they’re capable of delivering the project. Deadlines will determine if they have the time.

Will you be good to work with?

How does the client come across in this initial email? Bossy, pushy, organised, friendly? The personal relationship is one of the most important factors (for me anyway!).

Do you have the money?

Is there money set aside for this? Is it a realistic amount? No developer wants to spend half a day writing a brief just to find out that there isn’t enough money available. More on this later.

My 7 tips for a killer enquiry email

1. The right length

Nobody wants to read an essay on your company history, and all of the project specifics, in the first email. Keep the initial email short, succinct, and relevant.

However, it’s important to have enough detail to:

1. Show that you’ve done your research and planning.
2. Let the developer decide if they have the skills.

Think of it like a marketing funnel. A little teaser at the top, and gradually revealing more information as you read down. To make it more palatable, I prefer a short email introduction and then a development brief attached as a PDF.

2. Spelling and Grammar

English might not be your first language. However, it doesn’t take long to spell-check something. If possible, you should run it by a friend or colleague who does speak English.

Poor spelling and grammar show bad communication skills, and suggest that the enquiry was rushed.

3. Be polite

Use a basic greeting like “Hello Keith” at the start of the email. I know that this email is probably going out to 5 other developers – but don’t make it obvious!

Saying ‘please’ and ‘thank you’ also goes a long way. Being polite is so easy, why not do it?

4. Flattery will get you everywhere

This one is optional – but believe me, it helps. You should have already done a bit of research about the developer (to build up trust, remember?), so why not let the developer know what has impressed you? Is it something in their portfolio? A talk they gave? A blog post that you like?

Make them feel a bit special. Flattery will get you everywhere!

5. Don’t talk about your ex

Just like on a first date, don’t mention your ex. Tales of previous, or current, bad developer relationships are red flags. They indicate that you’re difficult to work with. Just don’t do it. We don’t need to know.

6. Have a deadline

Deadlines are positive. They help things get done and again they show that the project is real.

Without a deadline it looks like you might just be quote fishing and not serious about the project yet.

7. Show me the money!

I’ve saved the hardest one until last. It’s important that you have an idea of your budget, and that you disclose this to your developer. I’ve gone so far as to include a field on my enquiry form that asks for your budget. You can’t send the form without selecting a budget.

Why is it so important? Think of it like buying a house. You walk into the estate agent, and she’s going to ask you where you want to live, and what your budget is. Your budget will determine the type of house and the area that you can buy in.

There are 100 ways to build a site/app, and your budget will determine the process and approach taken. Be honest, disclosing your budget shows trust. Are you worried that the developer will just use all of the budget available? They might. You could even argue that they should.

Also, developers don’t want to go through the lengthy process of putting together a proposal, just to find out that there is nowhere near enough budget to do the job. The budget discussion will have to happen at some point, it’s much better to address it early.

A better way

Something tells me there is a better way to help clients find the right developer. At the Finding a developer event by Enterprise Nation, online consultancy was discussed as a possible gap in the market. I love this idea. Clients could pay for a short amount of a consultant’s time, where they will advise on things like MVP, recruitment, process, etc.

I also think that there is potentially a better way to price web projects. I’m currently doing some research on this, and hopefully I can develop a system that works for both the client and developer.