Hourly rates get you paid less, because your rate sounds higher in the context of "one hour's work" than it does in the context of "cost for a completed project", plus the fact that the hourly quote comes with the implicit risk that you'll go wildly over budget. The client will mitigate that risk and take the cost of that mitigation out of your hide.

You won't realize it until you and your friends start complaining over beers about how jacked up your big competitors rates are; they aren't, though, they're just not getting rolled by their clients.

People here really seem obsessed with the risk that the client is going to change their mind a hundred times. That makes sense, because it's the element of risk that developers actually see, care about, and feel entitled to an opinion about. But some important things about that risk:

* Unless you're working for tiny clients, it's much less of a real-world risk than it sounds. Major clients don't start projects with the intent of squeezing extra hours out of their devs. The amount of money they save by doing that is less than a rounding error, and, most importantly, they aren't spending their own money to get you.

* There are better levers to pull to mitigate project/schedule risk than quoting at your most flexible and least favorable rate by default.

* Even if you shoulder the risk of midstream spec changes, in all likelihood a client that pulls the rug out from under you is probably going to be reasonable about buying more of your time, especially when you say "no, I can't get that done in the original schedule; I don't see a way to resolve this without adding time to the project".

The middle ground between project and hourly rates has been our default for years:

* We break pricing down by person/week

* Our proposals loosely attribute milestones to weeks

* Any negotiation is conducted over the total project amount

* Project price cuts take the form of scope/effort reductions

This is a project-based bidding system that leaves you with the ability to say "no" or "you choose, either this new stuff, the original project milestone for the week, or an extra billable week and a new SOW".

For what it's worth, my experience also echoes what Thomas is saying here. When he speaks of larger firms pulling shenanigans around doubling up work or other suboptimal practices...yeah, that's my company.

The only thing we ever billed at an hourly rate was forensic work, and that was specifically done to make up for the reactive nature of that work.

For everything else, it's a fixed rate contract based on the estimated number of person/weeks of work with a clearly defined scope as to what is expected to be done. Our contracting department (which itself is larger than most of the companies we work for) would never want to deal with anything else.

I have seen scope change been an issue on 10k projects as well on multi-million dollar projects. All of which in my history would have been better off with an hourly billing.

The number of bodies were talking about makes a big difference, and the larger that number is the more a fixed rate person/week makes sense. Just like the larger consulting firms its all about placing a lot of people for a long time, +/- 1 week here or there won't matter. You mitigate the risk and it makes sense to take it on spread across the team and only as granular as weeks. Agreed your system works really well with those scenarios.

I interpreted the the original post was an individual who provides consulting service where 1 week could make a difference, 20% overage on a 1 month project. The companies aren't necessarily tiny, but maybe the departments within those companies (read budget) he consults with are limited. In this scenario I would favour a good hourly rate over fixed price every time.