That completely depends on the situation. I totally agree that cutting the hourly rate will be much harder to debate later on. As I wrote, it does not have to turn out as expected if you try to get a foot in the door, but if you lower your estimate on the time (= don't bill every hour) in the first place, you can learn the technology on the way, become an expert in the area and charge every hour with the same rate for follow-up projects.
I agree with that, if you need to put in extra hours to catch up with a technology that you said to the client you already know seems unfair to include in the final cost.
Also I understand that my hourly rate can't be the same as someone's who has many years of experience in the field. But I can "get my foot on the door" now and raise the rate gradually as I get more experienced, right?
Your experience (entry level, junior, mid, senior).
Your current job status (working now, looking for a job, urgent job)... you won't stay with no job to work on, and it might be okay to lower the price to have something in hand instead of free hand (same goes to a client who wants urgent work done while you work on something else, you will raise the bar).
Your location (if you are in India, your customer already came cuz he knows they pay less there)... how much they pay for the dev of your experience in your country?
Your client location, he won't accept an unreasonable price in his point of view... he might have a price already and he thinks that's the standard since it's like that in his country (different in remote case).
Who is the client? a normal guy wanting his blog ready? or a bank wanting a blog for marketing their latest tech? (silly example, but you see how to deal with different people).
But I can "get my foot on the door" now and raise the rate gradually as I get more experienced, right?
As @asparallel
wrote, this can bite you later. If you start working with a client and raise the hourly rate later on, they will probably want an explanation. But you can use the estimated time to maybe compensate for lack of knowledge at first and later align this with the real time you need as you get experienced in that area or established in the market in general.
You should always charge the client for research costs. I've been coding for 15 years but that does not matter I need more or less googling then you do. You probably know tricks I don't and Visa versa. The client pays your hourly rate for doing work. And if that work is writing code or looking stuff up it does not matter.
I still would say that it depends on a few factors. If I would research how to write a loop in JS for half an hour, I would probaly not bill that. If I research edge cases of support vector machines to evaluate if they are suitable for the client in this case, then yes, research should be billed.
Saying that every hour we spend should be billed it's our egoistic developer perspective ("I worked for an hour and the hour must be payed by someone"). The client perspective most likely is that they hired an expert who knows things they don't and is an expert in his field. So they will most of the time not be happy to pay us to learn things we should know in their perspective. So, as often, it's about finding a balance and being honest about what you offer for the hourly rate.
Damn and I thought I could get by without time tracking software haha.
So yes, that balance is what I am looking for. Charge for the "important" research and maybe not charge for the hours remembering the selected language's syntax.
If you are a developer that has to research how to write a loop in JS for half an hour your hourly rate should reflect that.
In my country you can get developers from 10 euro an hour to about 250 an hour. The hourly rate reflects the skill and expertise of the developer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That completely depends on the situation. I totally agree that cutting the hourly rate will be much harder to debate later on. As I wrote, it does not have to turn out as expected if you try to get a foot in the door, but if you lower your estimate on the time (= don't bill every hour) in the first place, you can learn the technology on the way, become an expert in the area and charge every hour with the same rate for follow-up projects.
I agree with that, if you need to put in extra hours to catch up with a technology that you said to the client you already know seems unfair to include in the final cost.
Also I understand that my hourly rate can't be the same as someone's who has many years of experience in the field. But I can "get my foot on the door" now and raise the rate gradually as I get more experienced, right?
Not just that Kostas, you charge depending on:
Your experience (entry level, junior, mid, senior).
Your current job status (working now, looking for a job, urgent job)... you won't stay with no job to work on, and it might be okay to lower the price to have something in hand instead of free hand (same goes to a client who wants urgent work done while you work on something else, you will raise the bar).
Your location (if you are in India, your customer already came cuz he knows they pay less there)... how much they pay for the dev of your experience in your country?
Your client location, he won't accept an unreasonable price in his point of view... he might have a price already and he thinks that's the standard since it's like that in his country (different in remote case).
Who is the client? a normal guy wanting his blog ready? or a bank wanting a blog for marketing their latest tech? (silly example, but you see how to deal with different people).
As @asparallel wrote, this can bite you later. If you start working with a client and raise the hourly rate later on, they will probably want an explanation. But you can use the estimated time to maybe compensate for lack of knowledge at first and later align this with the real time you need as you get experienced in that area or established in the market in general.
You should always charge the client for research costs. I've been coding for 15 years but that does not matter I need more or less googling then you do. You probably know tricks I don't and Visa versa. The client pays your hourly rate for doing work. And if that work is writing code or looking stuff up it does not matter.
I still would say that it depends on a few factors. If I would research how to write a loop in JS for half an hour, I would probaly not bill that. If I research edge cases of support vector machines to evaluate if they are suitable for the client in this case, then yes, research should be billed.
Saying that every hour we spend should be billed it's our egoistic developer perspective ("I worked for an hour and the hour must be payed by someone"). The client perspective most likely is that they hired an expert who knows things they don't and is an expert in his field. So they will most of the time not be happy to pay us to learn things we should know in their perspective. So, as often, it's about finding a balance and being honest about what you offer for the hourly rate.
Damn and I thought I could get by without time tracking software haha.
So yes, that balance is what I am looking for. Charge for the "important" research and maybe not charge for the hours remembering the selected language's syntax.
If you are a developer that has to research how to write a loop in JS for half an hour your hourly rate should reflect that.
In my country you can get developers from 10 euro an hour to about 250 an hour. The hourly rate reflects the skill and expertise of the developer.