Congrats! Based on my experience:
* Fixed-price is acceptable risk only if: (1) The project is small (e.g. <= one month), (2) The client has a precise spec (and he is hopefully technical), (3) The project is not R&D -- there is little chance of it failing or taking a lot longer than expected, and (4) Your gut says the client will be easy to work with, will pay you, won't try to add on extra features, etc. Also, I recommend the client be a business where no one is personally invested in the money they are paying you.
* If the contract is hourly, generally the contract is simpler and is much less risky to you than a fixed-price one -- I would recommend hourly for a first freelance project. (Respectfully disagreeing with agibsonccc.) With fixed-price, clients can eat you alive with revisions if you aren't extremely careful with the initial spec and being on the same page as the client. You can also easily go over your profitable window if you have not estimated software before. (A lot of it is not based on your skill, but on how particular the client ends up being.) Also, you run a good risk of not being paid at the end, unless you take precautions.
Keep in mind that with fixed-price bids, you are fundamentally at odds with your client -- you must finish quickly to make a profit, whereas they want a quality product. With hourly rates, you both are trying to do the project as "value-based" as possible, and you make decisions together based on cost.
If you do a fixed-price contract, then ask for half up front. (A retainer isn't a bad idea for hourly either.) If you make a fixed-price bid, I recommend estimating the absolutely worst-case scenario hours required then multiplying by even more. I tell my clients it would end up being cheaper if they go weekly, since my fixed-price contract by necessity must be a worst-case scenario estimate.
Also, in general don't transfer copyright (and hopefully the source code too) until all work is paid for. Your contract should state that it must be renegotiated if additional work is added beyond the original spec ... again, you don't need to worry about this as much with an hourly contract with no guaranteed finish date.
* A better pricing model than hourly/fixed is usually weekly or monthly, where you agree to work full-time for that period and you agree to goals to be accomplished. This way, you do not have to pedantically record every hour and expose your time management skills (for better or worse :)
* For padding, it depends on your experience with your own work. I recommend never to guarantee finish dates in a contract, unless you have a huge multiplier. Estimating the finish date would be fine though.
Personally, I set my prices based on how much I want a job. If I am not excited about the project, then I am one of the highest bids (and sometimes my bid is accepted). I do recommend that if you don't like selling, you should take the rate you were going to ask for and ask for something higher. Much of the time, the client just says okay -- worst case, he'll just negotiate something lower.
* I am not a big fan of your upper limit idea. I would quote the high-end price with an hour cap. For instance, $X guaranteed for up to Z hours, then $Y/hr after that -- and you estimate it will be done by Z hours, but it's not guaranteed. If they don't like that, you could say it isn't worth your time unless they buy a Z hour block for $X, then you'll put the extra time toward improvements or whatever else they want if you finish early.
* If you are worried about a contract, do not hesitate to have a lawyer review it. If it is fairly standard, you can probably negotiate a fixed rate of around $200. This Nolo book has a good fill-in-the-blanks template on the CD specifically for freelance software consultants: http://www.nolo.com/products/consultant-and-independent-cont.... The book has separate ones biased toward the employer and biased toward the contractor, so you can see the differences and what they might try to put in that would be against you. It is a pretty comprehensive contract and pretty biased toward you ... but it's always in your favor to supply the contract rather than to accept theirs.