What’s the secret tool to always being able to have the best WordPress developers work on your projects? It’s showing them you’re dang serious and you’d do anything on your end to allow them to do their work at their best.
You could think something along the lines of:
Shut up, Matteo! This is how things work: I hire them, I do the requesting, they do the work.
You wish… but it’s not!
Finding a developer doesn’t mean you’ll be working with them right off the bat because one critical step has yet to be taken: since developers are concerned about losing their time with bad clients, they haven’t picked you as their client yet. They’re still evaluating whether your project would be worth investing time and resources in.
Your most important and first tool to let them interested in working with you is your project brief.
However, it can be the case that nobody really seems interested in doing the job for you. Why is that happening? Why does no developer seem interested in your project?
There’s a high chance your project brief has something that’s keeping developers away.
Instead of losing your hair over the issue, it’s time for a retrospective and to go back and check what you could have done better with project brief and what’s missing.
To help you with that, I’ve put together a list of the 6 worse signals your project brief can feature and the main factors driving developers away from your project!
Get them here below!
Red flag #1: Vague project details and no examples
There are elements of a project that when done poorly lead developers away. Believe it or not, there are sometimes project briefs that just read: “I want a website.”
A website is not a candy bar that you could just buy by saying you want it. There are a lot of things that go into a website and a well-crafted project brief is the first tool to have it built it properly. Other than the core information related to your project requirements, a project brief will be way more useful with additional details and examples of websites you like, of the custom function you’re trying to replicate. WordPress developer and Codeable expert Ashley Shaw explains:
I’ve seen plenty of these poor project briefs in my life where clients don’t even give you a reference site in the details, they don’t tell you what industry they’re in. They just leave out examples of sites that they do like or they have that feature they’re interested in and they leave out any further information that would make us better understand their request.
Lesson to learn: add as many details and examples as you can to your project brief.
Red flag #2: Poor titles
When hiring a WordPress developer on outsourcing platforms, the very first thing developers see is the title of your project. And trust me, they have keen and trained eyes to already foresee troubles right from those few words.
The title of your project is something many clients might overlook, but it could be the deal breaker in some cases and leave you with no developers at all working on your project. As Ashley points out one thing that people usually get wrong:
An important thing is creating a title that is clear and logical because, more often than not, I can identify ‘illogical customers’ by the way that they write titles, brief sets, that sort of thing. And, if I look at it and I just see that they made no effort, it’s a red flag to me.
Lesson to learn: make your project’s title clear and to the point.
Red flag #3: Unrealistic timelines
Another important factor is timelines that seem too hurried or indicate clear signs of trouble. At the end of the day, developers – like all us humans – don’t like to work in a stress-driven environment and within tight deadlines. Ashley elaborates on how timelines can become a red signal to a developer:
Another thing is about having realistic timelines. For example, posting a job and saying I need this done in the next 48 hours. For my own team, I would never go for something that is a pressured job because invariably pressured jobs are pressured for one reason, and that is because the agency was disorganized or made bad promises. So, thinking about things in a realistic sense: within a week for a smallish job is realistic, for more complex ones it’s more than that of course.
Lesson to learn: Plan ahead, start ahead, and postpone your ideal deadline. If you’re an agency owner working with freelancers, stop making promises you can’t deliver and improve how you communicate with your clients.
Red flag #4: The next Facebook for $500
It might seem an edge case but it happens more frequently than you can think. There’s a specific type of project brief that really keeps developers miles aways: “Hey, I need to create a Facebook clone. My budget is $1,000.” You can change “Facebook” with any major, multi-billion companies you know.
To a developer’s hear these types of projects requests, although funny to talk about, sound as clear as what they intrinsically are: jokes. Even if you have 0 knowledge and no experience working with outsourced developers, you’d see a request like that being simply off: how could you possibly create anything that might be even closely considered a clone to such social network with a budget in the thousands of dollars? Elaborates Ashley:
When you get a sense of the customer’s budget, and then they’re giving you Amazon as the reference, and they go: ‘Well I want that/I want that feature!’ and they’re thinking about $500. Well, that’s another red flag.
Lesson to learn: You can’t have a Penthouse for $1,000. Be serious about your budget.
Red flag #5: Poor budgeting
When hiring a developer to work on your project, the budget is an important element of your brief. Remember when I said developers try to stay away from clients who make them lose time? Well, a project brief with a poor budget is one of their worst dreams. As Ashley comments:
When I look at a project, one of the things that I find disillusioning and causes me to be disinterested is when customers won’t indicate some kind of a budget that they’ve considered. I understand sometimes that it’s difficult to foresee a budget. But if you haven’t defined some kind of a ballpark budget, whether it’s approximately $500 or $1,000 to $3,000 or more, then, the developers don’t really know whether it’s worthwhile to get involved based on the brief.
Regular clients on Codeable appear to have a better understanding of setting a realistic budget; this is usually because there is a clear brief at the outset.
I know, I know: setting the proper budget up front isn’t an easy task. And that’s totally fine for the developers too, as long as you make that clear and are willing to discuss it with them.
In fact, what if you honestly have no clue about how much your project will cost? Well, just let them know that and clearly show them you’re willing to discuss one with them whether through a discovery phase, a consultation maybe, or just by answering more questions from them. Continues Ashley:
When customers don’t give a budget, I’m suspicious. That’s usually an indicator for me that I should stay away from that project. Especially when I ask a couple of valid clear questions about that and they refuse to answer. Why That? Because 90% of that time I find that people are being devious, and they don’t want to get a quote through the Codeable platform: they’re trying to test the waters and just get information.
Lesson to learn: Budget is the first thing a developer will look at. Put some thinking behind it because it could be a deal breaker for you. If you have no idea on a budget, just make that clear up front and be open to discussing one.
Red flag #6: If you say it’s a small task
When your project brief starts with something like “We need help with our theme: it’s a small fix!”, you’re lowering your chances to get starting. The same story occurs when you label something as “an easy task” or, even worse, “a 5-minute tweak”.
It’s almost never the case for you to determine whether what you are requesting is a small thing (or not) because you lack the tools and knowledge to perform such analysis.
Lesson to learn: be like a reporter and just state the “facts”, which is what you need to get done and want to achieve in the first place. Then, let the developer take care of defying what’s involved and required to get you there.
Wrapping up
One thing is looking for a developer to get help, another is actually working with them. While the former is mainly a task that sits on your responsibility, the latter is a relationship:
There can’t be any successful development project if both parties aren’t mutually communicating.
Your project brief is your tool and means through which you do your part within this beneficial relationship. Yet not every project brief will work in your favor and could even keep developers away from your project if has at least one of these red flags.
It can never be stressed enough the importance of how you’re approaching an outsourced developer affects your chances of having them to work on your project. Showing them you’ve put in some effort and reasoning behind your requests, timelines, and budget is your best business card.
This blog post features Ashley Shaw who is the founder of LightSpeed, a web agency that has been developing WordPress websites for over a decade. They can take care of and manage different areas of any business, such as frontend or backend development, WooCommerce support, MailChimp and Systems Administration.
