3 ms·

I generally believe that stating your hourly rate and providing frequent updates and milestones is a much better practice than giving an up-front project cost.

I generally believe that stating your hourly rate and providing frequent updates and milestones is a much better practice than giving an up-front project cost. Software dev is a very difficult task to estimate. Giving an up-front project cost is either pushing uncompensated risk onto the developer, or overcharging the customer for hours of work that may not occur, depending on how tough the project turns out to be once down to the nitty gritty.

scarejunba 8y ago
Do your clients accept that or is there push back? How do you bring them around to your (I think accurate) viewpoint?
rpedela 8y ago
I think upfront is better because you should be charging based on value. So what if something only takes you a few hours. If it generates enormous value for the client then you should capture a percentage of that value regardless of the cost to you. Likewise, if you underestimate then yes you eat the cost but you have a much happier client in the long-term. They don't feel cheated when you tell them it will take X more time, and you don't have to waste your time on time tracking and emails about why something takes 30 minutes. I also try not to give estimates to clients. Rather I ask when their deadline is. If they have none, then I say I will give weekly updates.
melicerte 8y ago
none of my customers would accept that. They have a budget and your price has to fit the budget period.
- nathanyukai 8y ago
  Have a hourly rate makes it easier to decide wether to take more project or not. Especially if the company getting big.
claytonjy 8y ago
I disagree; hourly rates are an invitation to get bullied by the customer. I much prefer setting a project cost, and informing client we can negotiate _scope_ but not _cost_. (roughly parroting patio11 here). This is in many ways _harder_, though. Hard to estimate time required (supply-side), hard to estimate value to customer (demand-side). As a service provider, "overcharging the customer for hours of work that may not occur" is effectively sidestepped by project-based billing. You're providing a product of value to them, not a number of hours of labor. Hourly rates are best left as an internal estimator of cost-to-supply-the-thing, and nothing else.

scarejunba 8y ago

Do your clients accept that or is there push back? How do you bring them around to your (I think accurate) viewpoint?

rpedela 8y ago

I think upfront is better because you should be charging based on value. So what if something only takes you a few hours. If it generates enormous value for the client then you should capture a percentage of that value regardless of the cost to you. Likewise, if you underestimate then yes you eat the cost but you have a much happier client in the long-term. They don't feel cheated when you tell them it will take X more time, and you don't have to waste your time on time tracking and emails about why something takes 30 minutes. I also try not to give estimates to clients. Rather I ask when their deadline is. If they have none, then I say I will give weekly updates.

melicerte 8y ago

none of my customers would accept that. They have a budget and your price has to fit the budget period.

nathanyukai 8y ago
Have a hourly rate makes it easier to decide wether to take more project or not. Especially if the company getting big.

claytonjy 8y ago

I disagree; hourly rates are an invitation to get bullied by the customer. I much prefer setting a project cost, and informing client we can negotiate _scope_ but not _cost_. (roughly parroting patio11 here). This is in many ways _harder_, though. Hard to estimate time required (supply-side), hard to estimate value to customer (demand-side). As a service provider, "overcharging the customer for hours of work that may not occur" is effectively sidestepped by project-based billing. You're providing a product of value to them, not a number of hours of labor. Hourly rates are best left as an internal estimator of cost-to-supply-the-thing, and nothing else.