Ask HN: Landed my first freelance job, how should I price the project?
4 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.
* 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 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.
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.
Hourly rate will make more headaches for both of you. Fixed price allows you to negotiate up front, take a certain percentage as a deposit.
Make sure IP is yours till full payment is received. Changes in requirements should require a restructuring of the contract. Make the client work for being fickle.
Get a statement of work. Clearly define requirements, again makes it easier for both of you.
Never think in hours. Think in weeks. 3x your gut estimate should be accurate enough.
Again: hourly is terrible. If your client is THAT focused on price you might end up in a bad situation where it's you vs them. That's a toxic relationship. It should be you two working together to solve a problem. Make this mutually beneficial.
Lastly, never focus on savings. Focus on value add that your project will bring them. If this ML algorithm will help a core part of their business, make that clear to them.
Your value add isn't an algorithm. It's going to help their profits by a measure of X%.
Now some machine learning specific advice: Integrate what it might take to do data pre processing, cleaning and formatting in to your time estimate. Try to get as much information from the client as possible about the structure of the data, how they want it integrated etc.
Oftentimes, I've always underestimated that part of the job.
Make sure IP is yours till full payment is received. Changes in requirements should require a restructuring of the contract. Make the client work for being fickle.
Get a statement of work. Clearly define requirements, again makes it easier for both of you.
Never think in hours. Think in weeks. 3x your gut estimate should be accurate enough.
Again: hourly is terrible. If your client is THAT focused on price you might end up in a bad situation where it's you vs them. That's a toxic relationship. It should be you two working together to solve a problem. Make this mutually beneficial.
Lastly, never focus on savings. Focus on value add that your project will bring them. If this ML algorithm will help a core part of their business, make that clear to them.
Your value add isn't an algorithm. It's going to help their profits by a measure of X%.
Now some machine learning specific advice: Integrate what it might take to do data pre processing, cleaning and formatting in to your time estimate. Try to get as much information from the client as possible about the structure of the data, how they want it integrated etc.
Oftentimes, I've always underestimated that part of the job.
For estimation, I like to carefully calculate exactly how long I think it will take, add some padding, then double it (for all the unknown unknowns). Then add some padding, and double it (to cover overhead and communication and documentation). Then add some padding, and double it (to cover changing customer requirements, and the fact that the last 10% usually takes longer than the first 90%). Then add some padding.
Also, here are some additional cons of an hourly rate:
* The better/more efficient you get, the less you earn for a project of fixed size.
* You are incentivized to drag your feet, while your customer is incentivized to expect superhuman feats of coding in a given time.
* People don't like being charged for phone calls, meetings, email, specs, documentation, testing, "small" changes, etc.
* Some customers are inclined to nitpick itemized time sheets.
A different approach I like is to break the project up into features of manageable size. This forces you to spec it out enough so that you can break it into chunks easy enough to estimate. Then you can put a price tag on each, loosely based on effort but also based on value to the customer. And then the customer can play "feature bingo" to decide exactly what they want, instead of haggling about your rate or the project's scope.
Also, here are some additional cons of an hourly rate:
* The better/more efficient you get, the less you earn for a project of fixed size.
* You are incentivized to drag your feet, while your customer is incentivized to expect superhuman feats of coding in a given time.
* People don't like being charged for phone calls, meetings, email, specs, documentation, testing, "small" changes, etc.
* Some customers are inclined to nitpick itemized time sheets.
A different approach I like is to break the project up into features of manageable size. This forces you to spec it out enough so that you can break it into chunks easy enough to estimate. Then you can put a price tag on each, loosely based on effort but also based on value to the customer. And then the customer can play "feature bingo" to decide exactly what they want, instead of haggling about your rate or the project's scope.
Go with a fixed fee for a set scope of work . . .
I don't like hourly and definitely don't go with hourly not to exceed.
Break it up in to multiple mile stones with incremental delivery, review/revisions and payment . . .
I would have early initial milestones so you make sure you and the client are on the same page . . . and that they are happy with the initial work and making payments . . .
If you can maybe quote 1 or 2 phases and see how the project is proceeding and if you are making a profit . . . you could also take some time to mock up a more difficult part to see how it's coming together and then quote that difficult phase as you are working on the initial ones . . . if a particular phase that you already have quoted don't be afraid to approach the client and see if you can work out an adjusted fee so you're both happy and a quality project is delivered.
I would setup the IP stating that you won't reuse the project in it's entirety but that you have the right to reuse portions of the code in previous, current and future projects. As most projects have modules you've used before, will use on your current project and on future projects.
There are some good boiler plate contracts out there.
Good luck with your first freelance project.
I don't like hourly and definitely don't go with hourly not to exceed.
Break it up in to multiple mile stones with incremental delivery, review/revisions and payment . . .
I would have early initial milestones so you make sure you and the client are on the same page . . . and that they are happy with the initial work and making payments . . .
If you can maybe quote 1 or 2 phases and see how the project is proceeding and if you are making a profit . . . you could also take some time to mock up a more difficult part to see how it's coming together and then quote that difficult phase as you are working on the initial ones . . . if a particular phase that you already have quoted don't be afraid to approach the client and see if you can work out an adjusted fee so you're both happy and a quality project is delivered.
I would setup the IP stating that you won't reuse the project in it's entirety but that you have the right to reuse portions of the code in previous, current and future projects. As most projects have modules you've used before, will use on your current project and on future projects.
There are some good boiler plate contracts out there.
Good luck with your first freelance project.
The work is machine learning algorithm development and then integrating the solution into the client's existing infrastructure.
A few questions:
* What are the pros/cons of an hourly rate vs. fixed price?
* Anything to watch out for in how the contract is structured? e.g., provisions about intellectual property, dealing with changes in requirements, or spelling out what deliverables are required?
* What kind of padding factor do you apply to your estimates of hours to complete a feature?
Based on some other things that I've read, I'm leaning towards pitching an hourly rate with an upper limit. For example, quoting a high-end price of $X and charging by the hour, giving them the savings if I can implement it in fewer hours or (hopefully not) having to renegotiate if it's significantly more complicated than I envision.
Any advice would be appreciated. If someone has a boilerplate contract that has worked well for them in the past, I'd love to see it. Thanks HN!