$200/hr and up for good guys who understand the business, how to communicate and of course code. Most of the plebs here are better off learning python and hiring a mentor on codementor to overcome hurdles. It's possible to hire great devs on codementor for $60 an hour. Lots of them can handle the analytics component (time series analysis, correlation, cointegration etc) but I couldn't find anybody who coded to a popular trading API. As for full on automation, I would only use the $200/hr guys. A bug in a trading algo can be very expensive. Or just use ADL and CQG's scripting language and be done with it. Just my 0.002. And I count myself amongst the plebs using $45- $60/hr developers
Actually, when hiring really good people in 99% of cases money is not the reason. For example, it's totally common to see these people to pick a job that pays 50% less but is more interesting (e.g. see a guy pick a job at google over a job at a hedge fund). It's more about the team, the actual content and the purpose of work etc.
Just my opinion - don't try to get best people, get good enough to get things going. Good article on this subject below. The main idea, relevant to this discussion, start ups are willing to sacrifice quality for cost and speed to market.
There is a number of differences between a developer at a start-up and a quant developer in a PM group or a fund. The main one is that "I know what I want but I don't know how to do it" - in most cases, there is no project, so things like creative thinking and ability to pick up business knowledge quickly matter as much as coding ability.
Another consideration is what needs to be built. Coding an indicator or a relatively simple app is a lot different than building software that can be built upon, scale and easily be extended.
Imo, the best (only?) way to bridge the gap between the smart, logical layperson and the less skilled developer is via flowcharts. https://en.wikipedia.org/wiki/Flowchart If the layperson can think logically, they should be able to draw a flowchart(s) describing what they want. The developer can then refine the chart with questions to the layperson. Charts also create a 'clearer' and easy record of what is expected. The charts can start very generally...and become more specific over time. In sum, if dealing with a competent coder, the coder will ask the necessary questions--client won't need to make charts etc. But if dealing otherwise, also use flowcharts to communicate with the less skilled coder. If the client is not a logical thinker and can't communicate precisely, ... and the coder is less skilled ... good luck.
Flowcharts are pretty much useless in the current OOP environment, the type of flowchart shown above hasn't really been used by actual developers since the 80s. That said anything that helps you organize your thoughts to spec out a project is good, so perhaps at a very high level this might be useful.
Add to that the consequences of errors in at least consumer oriented startup software is significantly lower than the consequences of errors in financial software. It's not unusual to spend significantly more time on testing and bug fixes than on actual development even in a non mission critical app, something to think about if you haven't budgeted any time for that.