I’ll be honest, I don’t particularly like hourly billing. This list will likely show you why.

Description:

Hourly billing (Rate * Hours): This seems to be the favorite of the industry. It is based on an hourly rate and the concept that time is money. It also is generally the way consulting companies sell consultants. The more qualified and experienced the consulting / programmer is, the more their time is valued and therefore they are more expensive per hour of work. The assumption is, they will be more productive. There’s a kind of factory mentality here. The customer is hiring a worker to do what they want and are willing to pay them for their time.

Pros:

• Simple to calculate for programmer and customer: Hours * Rate = Invoice
• Industry standard. Barely anyone will bat an eye at it.
• Easy for customers to compare programmers as a commodity by looking at their hourly rates. (maybe this should be a con?)
• Customers who believe they know how many hours something should take the programmer will have the ability to calculate what they think the work should cost. (They already know how much they’re willing to spend, or at least can ball park it with a gut feel.)

Cons:

• Hours do not have a simple conversion to anything useful for the customer. They will always ask you how many hours it will take to do a particular task, and you will generally be wrong. Customers will decide at the point of the estimate whether to purchase or not.
• Hourly estimates are generally treated by customers as a solid quote. This is because customers need to base their decision on some dollar total, not an hourly rate. Customers have a general feel for how much their willing to spend. I’ve never had a customer appreciate the “it took more hours than I thought, so the final price is more than I originally told you.”
• There are a limited number of hours per day that can be worked. This tops you out at some number of maximum hours. You can never work more hours in a week than actually exist. The only way to honetsly increase your income then is by increasing your rate, or hiring more developers who will work at less than what you charge.
• The customer is unconsciously (or consciously) focused on saving money by you decreasing your rate by giving discounts or minimizing the time you work and scrutinizing your timesheets for productive hours if they are over-budget. This simply slows everything down and makes everything worse for both parties and puts them at odds with one another. It tends to produce a lot of bad blood.
• The programmer is unconsciously (or consciously) focused on spending at least the amount of time they estimated, not finishing early – that would mean less money. They are not incentivized to find more efficient ways to work.
• The focus is on time the programmer works, not on the actual results delivered to the customer and whether the product delivered meets their needs. It is likely that is being considered, but it is removed from the actual pricing / billing.

For me: Hourly billing has been a limiting factor in my ability to produce good results for customers and I’ve hit the ceiling of my ability to receive income using this method. What do you think? Does hourly billing work well for you?