How do you calculate the rate to charge for contract/freelance work? How does it vary with web development versus iPhone versus sysadmin stuff? Per hour or a fixed amount for the project?
Thanks.
I've made this mistake twice in my life; both times at the end of the project it worked out to something crazy like $5/hr along with sour relationships with both clients.
An hourly rate is always fair, for everyone. The client gets what he pays for and you get paid for what you give. No more, no less on either side.
Lots of people work for a fixed price with happy clients and they end up being happy with the outcome too (myself included). The key to everything is to be good at specifying what needs to be done, and then be good at estimating how long it will take you to do it.
Also, lots of clients do not want hourly, because THEY feel it is unfair. They do not see you working, and you could be taking them for a ride.
Every experienced developer should know that nobody knows how to estimate how long something is going to take. Even the best developers I know always fudge their numbers by a factor of 2 and that is after they have sliced the work down to parts that take at most 4 hours and used all other tricks in the book to get decent estimates. You add everything, add 50% for writing the tests (either before or after the actual code, that doesn't matter), add another 50% for meetings, discussions, etc., add another 15% for writing documentation and then double it all.
I will never take a fixed-price job, unless I'm sure the client is reasonable in his expectations and I can apply the above calculation while still ending up with a decent hourly rate. I'm currently employed, but my employer isn't doing too well...
I did not say multiply $20 times the number of hoiurs, I just said that you need to derive your fixed price based on your estimation (not DIRECTLY based), which in turn is based on the specifications/requirements.
So we are in agreement. My beef was with the assumption that the service provider always gets screwed if they charge a fixed price; my point was that that does not need to be the case, if you follow a solid process to give your estimate.
Never do unknown amount of work for a fixed amount of money. Forget about "good guys" and "friends". You either charge them per hour or (if fixed job) control the contract with detailed requirements. You deliver that - you get paid. Charge per milestone. Split new features/changed requirements and your bugs. Charge more for new features. Always emphasize the fact it is not a bug, even if you are willing to do it for free. NEVER do life-time free maintenance of the project - set and meet the deadlines.
ALWAYS CHARGE.
People who can not organize and manage the process of development properly are deserved to be charged to the maximum extent.
Charge, charge, charge!
Maybe the trick is, pick good clients.
(The startup was an ISP, in 1996. Even in 1996, an indie ISP was hard to differentiate from the majors and incumbents. Mike and Tracy, the guys who ran the company, managed to build an unassailable reputation for customer service --- to this day, I don't understand how they did it, because I don't see how we did anything different from the other ISPs, other than to tell ourselves we had awesome customer service. But our ISP kicked ass up and down the block based almost entirely on that reputation. I'd love to get some of that mojo at Matasano.)
Guess who they call when they have another job? Me. Guess how much more they're willing to pay than new clients? A lot more.
Customer service being a first priority is not just a marketing phrase - it really does make a huge difference.
That being said, it is very important to define a clear scope, explain how much extra certain pieces would cost if they go out of scope, etc. Most clients are very receptive to changes in the quote - note the use of the word QUOTE - when the scope changes and you explain why it will cost more.
- have a solid spec
- build up a library of code you can reuse
- carefully evaluate the reasonableness of the clientI would never contract someone on hourly basis, I'm always trying to buy someone's knowledge not his time.
I'm trying to build partnership not contractorship. If you sell your time you are like an employee; If you sell your knowledge you are like a friend.
You can also discuss taking a cut of the app revenue in exchange for a discount, but i would be wary of this. I am doing it for one project because the project was smaller in scale, so its less of a gamble. I had another that I almost offered a 50% discount in exchange for 50% equity... and that app has made about $10 in the month or so its been in the store. So, my experience tells me avoid royalty arrangements....
Don't be afraid to start at a high hourly rate, it almost always works out in your favor. Excuse the metaphor, but clients want to feel like they're getting a great deal on a Lexus rather than a satisfactory deal on a Hyundai, even if the price is the same. The key is elevating your perceived value. Talking clients through complex technical issues and possible solutions before negotiating often helps.
Don't bother with the freelancing sites, as rates are low. You'd be competing on price with overseas developers rather than playing to strengths like availability, perceived value of your formal education, and communication skills.
And you shouldn't admit to being an emerging developer, people are pretty wary of dealing with "amateurs". You need a reputation before anyone will pick you.
My advice is as follows: a) Spend about $500 to get some feedback. Don't get greedy and make all of those large projects. You need to start out with a few small ones, then get a few large ones. Your goal is to have 7-8 "feedbacks" about how great you are.
b) At the same time you should bid on other projects, doesn't matter if its big or small, if its a $20 project or a $30 project. Your goal in the early stage is to get a lot of feedback points.
c) Once you reach 20 or so feedbacks you'll be able to actually win some of those larger projects. At this point your skills will improve, and you can actually start charging more than the average offshore developer. You can explain the difference by saying you are in the USA and are actually in the same time zone as your clients.
Also if you have some free time, make 5-6 websites, that you can point to as your "work". They don't need to be super complicated, but they should look good.
On a related note, I started networking lately - going to user group meetings and the like - with a lot of success in regards to my freelancing. I hit groups for topics I am interested in and with good crossover in the fields I know well.