Hourly Billing is Nuts
… and check why 5600+ Rails engineers read also this
Hourly Billing is Nuts
When it comes to my salary, I am an ordinary guy who earns $ X per hour. I’ve been working this way since I joined Arkency, and I never thought much about it. I’ve been happy that if I need vacations or break, I can just take them (properly communicating it with the clients, of course) without much hassle. When I feel great, and I am inspired to work and work and work, I can just log more hours without thinking much about it as well. Just like monthly salary, hourly salary is a safe way to live. But is it the most rewarding way to live?
Hourly Billing is Nuts challenged my perception that hourly billing is the best way possible. I started to notice the bad parts as well, not only the good ones. I don’t agree completely with some parts of the book, but it got me thinking.
I won’t summarize the book here because it’s better if you just read it yourself. So just a small challenge. At some point, you started working as a programmer with skills X and let’s say your current salary reflects that (no matter if you are an employee or freelancer). You read tons of books, invest in your skills, gain lots of experience and reach level 2X. How do you prove that you should be paid 2X now? Not to your boss but your customer… How? How can they see that you are worth twice the salary? As you can imagine, it’s problematic…
- You could be working on features twice as fast, but you are not working on the same features, so it’s not easy to prove it.
- It gets even worse. If you spent say three years acquiring those skills and your customer spent three years expanding the business into more complex areas then they might perceive you as being on the same level. But that can be misleading because you are now working on twice as hard problems with your skills being twice as good as they used to be. That’s why things can look similar to what they were some time ago.
- You could be working on features that bring 2x the money that previous features used to. That would be perfect. But the thing is… It does not always depend on developers what features we work on, how they are used by clients, what’s the conversion rate. And often the most beneficial features are implemented at the beginning of a project and adding every new cross/up-sell is harder and less rewarding.
- Or it can be a combination of any of those in any way. 25% faster on 25% more sophisticated features worth 25% more money means you are 100% more valuable in this simplified way of thinking :)
So I’ve been thinking how value pricing (pay per feature) changes things here. And I came to the conclusion that the change is mostly about moving this risk (and potential reward related to it). What do I mean by that?
When billing hourly the risk for an agency is minimal, and most of it is on the side of the customer. If the estimations are incorrect (and they always are), and things take longer, it’s the customer who pays more. This can be mitigated some way (for example by “we won’t pay you for more than Z hours” rule) but if it is, you are already beyond hourly billing and taking some part of the risk on your side.
On the other hand, when you are doing fixed price project the whole risk is on your side. When things take longer customers don’t care (unless deadlines apply). It’s your time and your cost only. So the risk shifted.
What if by being a better developer, using the proper technology you can do the project in half the time it would take other companies? In hourly billing model, the reward is received by the customer. You did things cheaper, and they still have the budget to pay you for other features that you could work on during that freed time.
In fixed price environment the reward is yours. You get the same amount of money, and you can work (or not :) ) on a different task/project in the freed time.
Of course, you might argue that when you get 2X better, you can charge 2X more per hour. I agree, assuming you know how to convince your (new or existing customers) that you are now two times better. This can be hard.
But is it hard in the value pricing model? Not really. You charge like you used to, and you implement things faster. You monetize the free time however you want. The price is not directly correlated to the time you spend on the feature but to the value, it brings to your customer.
And that’s only a fraction of my thoughts after reading Hourly Billing Is Nuts. For years I’ve been comfortable with my hourly billing model, and I never challenged it consciously. Now I started to consider pros and cons of both approaches actively and wonder which one I should use with which customers. And which let me easily charge more when I get better.
P.S. Hourly Billing is Nuts is available as part of our Smart Income for Developers bundle in all packages.