Like many consultants I bill hourly for my time, and it certainly seemed to work fine for the last few years. I’ve been thinking a lot about my pricing lately though and I’m no longer convinced that pricing hourly is really a great idea.
Ron lays out a compelling argument as to why cost plus billing is not only wrong but economically flawed. While there are many reasons it is a flawed system, the biggest reason is that it misaligns the incentives for clients and agencies. In any system where hours are used to determine the price of work, its your incentive to convince your client it will take many hours and their incentive to convince you it won’t take that much.
I hit this exact scenario today actually. I was asked to quote on a feature and after I sent it in I was challenged that the feature shouldn’t take as long as I quoted. Now the client is semi-technical so when I explained it all to them they changed their tune but it’s still a pain.
I don’t like fighting a battle with clients about hours, it starts things on the wrong foot entirely. We should be working as a team, not as opposing forces.
A Feature is More than Simply the time it takes to write the code
If you’re billing hourly then you are simply charging for the time it takes to write and debug the code. For smaller clients (small business) that might be totally fine, but for medium sized businesses that’s not really valuing the work properly.
Say you build a feature for the client and as you build it you have a few tweaks to make it just right. That feature increases their revenue $20k/month. Was it really worth $2k to build it? Nope it was work way more, you just increased their revenue $240k a year.
More than that, with every feature for a site there is admin time to set that up. One client I have often changes features and requires multiple estimates, sometimes with entirely differing features. The short version is that they cost 15% more administrative time which I have to make back somewhere. So when I say a feature will take X hours, I’m really bumping it up a bit to account for the 15% admin time. So no the feature won’t take quite X, but I need to make money and all the extra admin time means I can’t do that with my normal rate.
One of the best podcasts I’ve listened to recently talks way more in depth about this exact topic. So go listen
No More Hourly Pricing
Yeah that’s right, I’m not pricing hourly from now on. I’m going to price based on a feature for now with no time associated with it. Then we don’t have questions about the hours it may or may not take.
The other thought I’ve been mulling over is selling my time in weekly chunks. As I’ve talked about it with my wife she always asks the same question, for which I’ve never been able to get a satisfactory answer. What do you do with a long term client that needs an hour for a little site fix if you’ve sold your ‘week’ to another client?
I think about working at night or on the weekend, but I don’t want to work all the time. I’ve got a kid that needs my time and that’s time I want to spend.
Quote can be found here.
4 responses to “No More Hourly Pricing”
I was just thinking about something very similar myself this morning. Actually, it was in conjunction with a post idea; but, what I will say here is: I mostly agree with these ideas … just have to find my happy median before I publish my own.
It’s a lovely idea, but it doesn’t work in all cases.
Fixed cost billing is lovely, if you can be certain that you’ll not overrun. You can’t charge more based on the value to the client – that’s unfair. That’s like charging more for chocolate to a rich person than a poor one. It infuriates buyers because they know that you’re suckering them. It also encourages them to simply hire their own dev teams.
Hourly billing is also problematic, for the reasons you state.
This is why as a business we’re moving towards product based solutions + hourly rates for implementing and change requests. Then you can sell it multiple times over, but at relatively low cost. Some buyers will get better returns than others, but that’s for them to work out.
You really need a balanced solution that gets you the best of both worlds.
Uh.. wait, rich people do pay more than poor people, for chocolate, gas, and code.
Just check out the prices for things at convenience stores in Beverley Hills and Compton in California.
Gas and candy prices are much different in those two neighborhoods. Yes, you can adjust what you charge based on the ability of the client to pay, as well as other metrics such as delivery priority, # of features, level of documentation, etc.
Just be sure you can justify it if questioned about why you charged different rates.
That’s a different metric – charging based on your location is normal. After all, setting up shop in Beverley Hills or Primrose Hill isn’t going to be cheap and those costs have to be covered somehow. But they’re in the business of chocolate provision, rather than chocolate making – chances are the shops paid exactly the same to get it from Hershey’s or Cadbury’s.
The key thing in code is that the marginal cost is zero. You can sell your code again at no additional cost to yourself. So if a client pays us to develop a Kindle periodicals plugin for WP (as recently happened) because it’s GPL and we keep our rights to it, we can resell it again. So there’s a value for us as well as the client.