Once you've got that idea out of your head, it's time to figure out ways to get shit done while minimizing the risk to yourself/your company. One great way is to start off with contracts, see how things work out and re-evaluate from there. If you have the budget, do a phase two that will require the candidate to hire/supervise another developer to get a task completed.
I'd avoid asking developer friends for help as hurt feelings will tend to spring up out of success or failure. I've learned that when you're starting a company, one good friend is worth one hundred good employees.
How should you structure the payment?
The best way to reduce that risk is to ask business owners you know, "Who wrote your prototype?"
You need 2 things:
1) Somebody who has, and can, deliver a working product.
2) Somebody you can communicate with when differences arise.
If the former, then its unlikely you are asking this question since you should be talking with the grad student who is already your cofounder.
So I’m going to assume you are building a startup like zipcar, taking mostly-known technologies and applying them to solve a business problem. In this case, you want someone who knows their particular stack very well (can debug their own package management issues, can choose good libraries, can navigate the docs quickly). You don’t need someone who has contributed to developing the language itself.
> and connect with the right talent
I’m not sure there is a large category of person who simultaneously doesn’t know their tools well but is well-respected among their contacts in the way that would draw other engineers to want to work with them. Maybe this refers to an engineering manager who hasn’t really been doing much programming in the past 3 years?
EDIT: actually yes, someone with engineering management experience who is a bit rusty with programming to any particular stack is probably a good choice—-as long as they previously have been efficient they can pick it back up again.
Automation is removing the repetative work that a cog would do.
Docs and testing allow you to take on work of greater scope by being more sure of yourself and what your coworkers have built.