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".