DeveloperHourlyRate - our new mini-project with a simple message for clients

One of the most popular questions I'm getting as a developer and team leader is what is my/our hourly rate for web-development. Instead of answering "it depends" every time, I decided to create a mini website with an answer. Might be useful not only to myself but to you too - whether you would show it to your clients, or you are a client yourself.

Why there's no such thing as "average hourly rate"

The problem is that a lot of clients tend to measure the cost of web-development by time. How many hours/days/weeks spent on the project. But if you think about it, it's wrong on many levels:

1. It assumes that every developer has the same quality and efficiency, which is absurd
2. It punishes professionals: hourly means that the faster developer brings the result, the less they get paid. So a lot of room for slowing down artificially, cause that's the only way to make decent money.
3. Hourly rate doesn't allow the client to plan the budget - they can know how much to plan for this week, but how many weeks the project is gonna take - that's hard to predict.

And a lot more reasons why hourly rate is wrong. But the biggest problem is that clients think that developer for $10-20 per hour is cheaper than $50 per hour. In terms of simple math, it is - but in reality more qualified developer will deliver faster, with less bugs and also will provide business knowledge in order for you to succeed. Which then allows you to launch and start earning money quicker, which means you earn more. Doesn't it make sense?

And so we've put up a calculator to demonstrate this in reality - what processes you're getting for different hourly rates.

See the example below - same process with a $50/hr and a $20/hr developer:

See, less time on planning, more time on development and fixing bugs later. Overall time is drastically different. And total cost is roughly the same. That's the whole point.

The numbers, of course, are not exactly accurate, we didn't plan them to be precise. The goal here is to show the logic of why more expensive developers are not that expensive in the long run.

Same logic actually applies to a lot of fields in life. For example, hardware - for the price of new iPhone you could buy 2 or 3 cheaper phones. But they would have less quality, less functions and would break much faster, therefore considering the fixes (or buying a new phone) it might not even be cheaper.

Ok, so how to price projects if not hourly?

I'm glad you asked. I hope by this point you agree that hourly billing is wrong for both sides. Now, let's get into the real world - what makes sense for both client and a developer?

To spend more time on actually evaluating the project.

Simple, right? I'm actually surprised so few people do that.
Typical (wrong) start of the project:

• Client posts the project job on some job board or sends an email to a developer/agency
• Developer is thinking "OMG I need to win this project so I need to make an offer fast"
• Sending the email "I'm ready to help you, here's the rough estimate or hourly rate"
• Client: ok, let's do this
• [in the middle of the project] Oh wait, in my estimate I actually didn't consider this and that, and, to be honest, we cannot deliver on time or within budget...

And it starts going wrong at that moment where the estimate is rushed. I really like the article by Christopher Hawkins, called Dear Client: Stop Asking For A Ballpark Estimate. He is talking about "sitting down" with a client for a discovery process - where both sides talk about the details upfront and try to evaluate it more accurately.

So, the (more) correct way of pricing the project is this:

• Client gives as much details in the job description as possible
• Developer spends time on analysing it
• Then they have a live-discussion (in person or Skype, whatever)
• Both sides find answers to unanswered questions
• Another round of analysis
• And ONLY THEN estimates of how much it would take/cost

That estimate of price can be, actually, based not only on time that it takes. There's a thing called value-based pricing, which is becoming more and more popular. The point is to try to evaluate the profit amount that the client can make potentially, and then that profit becomes the ultimate goal, and from that profit developer takes the percentage and that becomes the price of the project. It actually makes a lot of sense because then a developer becomes like a business partner and aims at the ultimate goal as much as the client.

Final thoughts

So, if you are dealing with hourly-rate pricing, from whatever side, reconsider it and try to evaluate the total cost/scope/goal instead of tracking time. And, also, don't think that smaller/bigger hourly rate directly means cheaper or more expensive project. The formula is much more complicated.

Do you agree with the thoughts? And with the calculator?

Link to the calculator once again: DeveloperHourlyRate.LaravelDaily.com