We've been contending with a pricing model for our clients at Foliovision. As Foliovision has grown outside its old bounds as a single person company doing relatively contained projects, our rates have had to rise.
It's not such a problem as we are a lot more productive.
There are two primary models: flat fee and pay-per-hour.
In principle, flat-fee is more profitable (if you charge $1000 but through automatisation can get your time to render the project down to 2 hours from 12 hours you've just made $500/hour instead of $80/hour.
On the other hand, we mainly do made-to-measure work. There is rarely the opportunity to automatise to that extent. We get exponentially better results in our markets than the competition so made-to-measure clearly works.
With made-to-measure work one can spend more time quoting and negotiating spec back and forth than working.
Gradually the client can grow to hate your emails demanding expansion of project scope and budget. Generally the (busy) client would prefer to pay more for something delivered with no hassle, complete and working. Then he or she only pays once for the project, instead of twice.
Twice is their time spent micromanaging what ends up costing more or less the same anyway.
There is an interesting extended discussion of the pricing issue over at BlueFlavor (the not so new site of old favorite site architect Keith of *sterisk)
One benefits to hourly billing is the client is responsible for increases of scope, protecting the vendor and the customer. If the project is completed early the client pays less, protecting the client. This puts the onus on both parties to communicate regularly and work more effectively.
This isn't to say that working on an hourly basis is license to an open paycheck. Rather, budgets and requirements should be defined, watched and met. If the hours start to go over, this should be called as soon as possible, ideally before the hours are committed.
Blue Flavor almost exclusively charges on an hourly basis. Over our careers in the web we've seen requirements invariably shift, and often for good reason, to produce a better, more people-centered end product. We believe that the pricing structure should be flexible to reach that for every project, but also put some checks and balances in there to prevent overages in our original estimates.
I couldn't agree more with Keith. Every time we've had clients try to move us to project quotes the relationship has gone downhill. First the client pushes for too low a budget with incomplete specs. Client gets said quote and rubs his or her hands with glee. Then when things are underway the client wants a whole lot new changes. Emails go out about change of project specs. First the client argues. A lot of time is wasted on both sides talking about the money instead of doing the work. Finally the client reacts with dismay. He or she hadn't managed to burn the developers after all.
A lot of stress for everyone. We've gone back to hourly charges for all but the most quantifiable work.
Hint: when we accept flat fees, it's only if we know that it will make us more (cost you more) than if we did it on hourly rates.