* 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.
This is definitely from my experience that hourly ended up being a headache. The clients I've had in this space tend to want a race to the bottom in price when you get hourly. I've always had it where the client wants a lot more validation and other problems when the project isn't fixed price.
That is a good point about hourly rates. Make sure your hourly rate is high -- in my experience, the more you charge, the more your client respects your work and time. Plus, you can afford to give some free hours or work a bit extra to make sure the end result is quality. Keep in mind that as a freelancer in the US, about 1/3 of your income goes toward taxes -- plus you don't get benefits like a normal employee would.
If someone specifically wants you for their project, then you can usually negotiate a pretty high rate -- especially for something as specialized as machine learning! People hire me often because they hired someone off Craigslist at a low rate, and this time they want to make sure the project is done right.
Comments
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.
More thorough answer than mine. Go with this guy.
That being said: you bring up some good points.
This is definitely from my experience that hourly ended up being a headache. The clients I've had in this space tend to want a race to the bottom in price when you get hourly. I've always had it where the client wants a lot more validation and other problems when the project isn't fixed price.
Everyone has their own experience. Let me just defer to patio11 for how you should price contracts: https://training.kalzumeus.com/newsletters/archive/consultin...
It worked for him as well from what I'm seeing. Go with what works for you.
That is a good point about hourly rates. Make sure your hourly rate is high -- in my experience, the more you charge, the more your client respects your work and time. Plus, you can afford to give some free hours or work a bit extra to make sure the end result is quality. Keep in mind that as a freelancer in the US, about 1/3 of your income goes toward taxes -- plus you don't get benefits like a normal employee would.
If someone specifically wants you for their project, then you can usually negotiate a pretty high rate -- especially for something as specialized as machine learning! People hire me often because they hired someone off Craigslist at a low rate, and this time they want to make sure the project is done right.
For some perverse reason, I've found clients get less uppity about a day rate than an hourly rate. Plus that way your timesheets are simpler.
Thanks to you both. I really appreciate you taking the time. Tons of good stuff to think about.