Quote from slacker:
The quote can be anything you agree on.
1. Most people who want software developed have no spec and no clue how long it will take.
2. Most people who want software developed would never agree to the cost of the project if they really knew how much it would cost before completion.
Suggestion, identify milestones and pay only when milestones are reached. Step-by-step may give you what you want.
Suggestion, get multiple bids from several programmers for each step in your project.
However, programming an automated system is a very unbounded problem and hard to cost out. Anyone smart enough to do a good job is probably doing the same for himself; or knows better than to commit to a 'bad trip'. (Not saying your project would be a bad trip!) 
Good luck on your project!
I have seen a lot on both sides of this issue.
1. Make sure you have a detailed functional description of what the project actually involves. Without someone with software engineering experience being involved in that functional description process itself, you stand little chance of being satisfied with the final result. Seriously consider hiring someone to help you understand what the possibilities are and what the resulting estimate is for each of your functional items.
2. If you can find several competent people that are balking at committing to the job at what you consider a "reasonable estimate", it is likely that the project is either badly defined, an overoptimistic attempt at something very difficult, or you are not correct in what you consider "reasonable". The absolute worst thing you can do is hire someone to do it who thinks it is "no problem" if you have already found several good people that are walking away. If you hire this person, you will be very lucky if the project is completed at all, or the quality will be so bad that you will wish you never did the thing at all.
3. Do not attempt to hire overseas programmers to do it unless it is a very repeatedable, well understood problem, or something which needs a rewrite but already exists in a currently working form. There is an art to systematic disciplined creativity which has cultural roots, and which is very difficult to teach to people who are used to being "programmers" rather than software engineers.
4. Price the work on the project level, not by the hour, but be sure to include incentives for QUALITY as well as SPEED, have definite PAID MILESTONES, and be sure that you price it at a "generous" level. Do not pay by the hour since people have been known to "milk" things when they know they are being paid by how long it takes. On the other hand, trying to save money by underpricing the project will de-incentivize the person from doing their best work. If you want a Mercedes level product, do not pay them as if they are creating a VW Beetle, in other words. A way underbid project is just as bad for you as the person bidding it, because once they realize they underbid it, they will just slap together anything to get it over with and minimize the "loss".
5. Be flexible, and realize that 9 out of 10 projects will have changes made during the process (mostly initiated by YOU once you see something underway), which will necessitate additional effort, and thus additional cost. Figure that 70% of the cost (Step 4) will be anticipated, and 30% of the cost (Step 5) will occur due to changes, some of which will be impossible to anticipate until the project is well underway.
6. Get references from the people that you are considering hiring if possible. Value QUALITY over SPEED and COST. Do NOT usually go for the absolutely lowest bid if you are taking multiple bids. Particularly, if one of the bids is WAY LOWER than the others.
Consider using a friend in this field (if you know one) to help with the process of determining the best people to use for the project.
