A lot of comments here from people with vested interests, one way or the other.
A few thoughts of my own :
First, I've seen absolutely no correlation between where a developer is located, or how much they charge, and the quality of the work received from them.
We've hired developers all around the world - US, Canada, UK, Spain, India, Pakistan, Vietnam and quite likely elsewhere too without realizing it. We've paid as much as $125/hr and as little as $7.25/hr. Our best experiences and value for money have been with lower paid contractors.
'Buying American' no more guarantees you high quality work with developers as it does with cars.
And the only thing that paying two or four or ten times as much money guarantees is that, ummm, you're paying more money.
Most of the objections to using off-shore developers are paper-thin and of no real consequence. 'Indians only do what they are told to do'? What's wrong with that! 'They work in a different time zone'? Big deal - it cuts down on needless 'chatter' back and forth, and makes for a great alternation of duties - half the day with the developers developing, the other half of the 24 hr period with testers testing and returning/reporting back to the developers for the start of their next day.
Now, to look at the actual question asked in this thread. Several people have suggested using Upwork (the new name for the merged eLance and oDesk companies) and the ratings there. That's a superficially good suggestion, but full of problems, due to the 'mutual suicide pact' associated with bad ratings.
If a hiring company gives a developer a bad rating, guess what happens in return? The developer gives the hiring company a bad rating too (leastways, that's what I've seen on eLance, I presume it works the same way elsewhere). So hiring companies tend to either give undeservingly good ratings, so as to in turn have a good profile to encourage developers to contact them, or else don't rate the developer at all at the end of a contract.
And then there are the starkly unfair ratings given to some developers for problems that in truth were due to the hiring company not the developer. Plenty of false positives and some false negatives, too.
I don't think there is any sort of comprehensive and accurate service for rating developers. Looking at GitHub and StackOverflow profiles is a pointer, but only partially so, and of less help when you're considering hiring a company rather than an individual.. Getting references and calling them to check is again a pointer, but also only partially so and something that can be gamed with only a little effort.
Assuming there to be little in-house technical expertise for evaluating developers, then the best thing to do is to assign work in small bite sized pieces. This is standard 'best practice' anyway - defining your project in a series of short 'stories' that talk about the end-user functionality you want, rather than the bits and bytes of how it is achieved 'under the hood'.
These stories ideally are each less than one day projects; if they are much more than that, you should break them down into more detailed substories.
Then start doling out these stories, one at a time. Pay upon story completion and acceptance.
That way, with 5 - 10 hours of programming time at risk per story, you have much faster feedback. Even a non-technical person can quickly get a sense of 'was this done on time' and 'does it now work the way I expect it to work'.
You should also, of course, hire a part-time independent contractor to act as your 'CTO' until such time as you can bring one in-house. This person should be unrelated to the actual developers, so there are no conflicts of interest, and his job should only be overseeing the code being produced, managing your GitHub repository, and quality controlling the technical side of accepting each story.
That has worked well for us. Sure, we've had more failures than successes with the programmers we've hired, but from what I can gather 'on the street' the usual rate is that if you're doing very well, one programmer in three might prove to be a keeper.