Thanks for the write up, it was an interesting read.
One thing I'd add is that I don't understand why anyone would pay a non-employee at an hourly rate. When I have code work done I always pay 'pre project' not 'per hour.' I think it's a much better way to go for several reasons:
1) If you pay per project you have cost certainty. You know exactly what the code work will cost before any work is started and can decide if the investment is worth it based on your projected ROI before any money is spent.
2) If I find a coder who can complete their work much faster than 'normal' they should not be penalized for being quick. When you pay per hour for anything, you create an incentive for the person to take their time with it because they fear sending you the completed job quickly and being asked to reduce the price. I want the work done right and I want it done as soon as possible... being done ahead of schedule is a good thing not a bad thing.
3) I agree very much with what others have said about creating very specific terms for the project. If you find a coder who is not willing to give you a project price it usually means you failed to make a specific enough set of instructions for the project. If your specs are clear, a good coder can tell you how much it will cost to build... so while a per hour rate allows you to hire someone willing to take their time and fumble their way through a murky set of instructions... a per project price requires you to be much more specific and gives the coder good incentive to think things through and ask questions for clarification BEFORE they begin their work.
Incidentally, I price text work per project rather than per word or per hour for many of the same reasons...
