It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
We're all constantly googling basic stuff. All of us. Time is the only thing that matters when it comes to setting a rate.
You could try backsolving from annual salaries in job postings which describe similar responsibilities to what you're undertaking to get some ideas, but the fundamental question is "what is your time worth?".
We're all constantly googling basic stuff. All of us. Time is the only thing that matters when it comes to setting a rate.
That's a very debatable point of view. From a developer's perspective, this might sound reasonable, but the client will not be happy if you tell him "I don't know much, but you will pay me a hefty hourly fee to look it up on Google". Yes, everyone has to look up things, but I believe that you should treat productive hours (coding, doing real research etc) different than catching up with things you should know when you are the technology expert for the client.
The second reasonable perspective is the customer value you bring. If you can save the customer 100k per year, it's easier to charge something in the neighborhood of the first year's savings than if you calculate based on yours estimated hours and the client's savings of the next 20 years will be spent on the project. If that's a reasonable price though, the client might have to re-evaluate if it is worth for him to run the project. It's not the duty of a developer to do it with a loss just so the client can afford it.
But it gets even more complex: if you are new and want to expand your freelanceship, you might start cheaper to Hain a track record. Or to get a foot in a door with a client with great potential. Of course, the goal is in both cases that future projects will compensate for that, which is not always the case.
As last point, there might be developers with same hourly rate that work faster than you. If you just base your prices on the hours, you might not get the project if others can offer a better price, because they are more familiar with the technology.
I'm not sure if this really helps as an answer, but finding a reasonable price is really hard. If you have a good and trustful relationship with the client, you might agree on an agile model, think about an MVP and a maximum price where you would stop to re-evaluate. Until that point, it was be billed by the hour. And afterwards add feature increments with their own value.
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.
We're all constantly googling basic stuff. All of us. Time is the only thing that matters when it comes to setting a rate.
You could try backsolving from annual salaries in job postings which describe similar responsibilities to what you're undertaking to get some ideas, but the fundamental question is "what is your time worth?".
That's a very debatable point of view. From a developer's perspective, this might sound reasonable, but the client will not be happy if you tell him "I don't know much, but you will pay me a hefty hourly fee to look it up on Google". Yes, everyone has to look up things, but I believe that you should treat productive hours (coding, doing real research etc) different than catching up with things you should know when you are the technology expert for the client.
The second reasonable perspective is the customer value you bring. If you can save the customer 100k per year, it's easier to charge something in the neighborhood of the first year's savings than if you calculate based on yours estimated hours and the client's savings of the next 20 years will be spent on the project. If that's a reasonable price though, the client might have to re-evaluate if it is worth for him to run the project. It's not the duty of a developer to do it with a loss just so the client can afford it.
But it gets even more complex: if you are new and want to expand your freelanceship, you might start cheaper to Hain a track record. Or to get a foot in a door with a client with great potential. Of course, the goal is in both cases that future projects will compensate for that, which is not always the case.
As last point, there might be developers with same hourly rate that work faster than you. If you just base your prices on the hours, you might not get the project if others can offer a better price, because they are more familiar with the technology.
I'm not sure if this really helps as an answer, but finding a reasonable price is really hard. If you have a good and trustful relationship with the client, you might agree on an agile model, think about an MVP and a maximum price where you would stop to re-evaluate. Until that point, it was be billed by the hour. And afterwards add feature increments with their own value.