4 ms·

I think starting with an hourly rate is uninformative. For example, if a client's budget is low I might grab a RAD tool to get the job done (while letting the c

I think starting with an hourly rate is uninformative. For example, if a client's budget is low I might grab a RAD tool to get the job done (while letting the client know that this decision might hinder flexibility in the future.). "You want a database on the web, that you can customize yourself, for $600? Great, let's grab a copy of FileMaker Pro, or sign up for Quickbase.com and get going" Yes, those solutions may limit potential of the app down the line, but they might actually be the right fit. I'm another hourly-rate-all-the-way guy, but if I can extract the budget out of the client, then I can decide (essentially), "Given the client's other requirements, will a RAD/off-the-shelf/OSS-package-with-a-custom-theme work for this project... or do I just politely tell the potential client to get bent?"

kls 15y ago
In my experience an hourly rate usually either a) extracts the budget number that they have or b) gets the response of OK lets just do it hourly or c) I get show to the door. In situation A it is usually because they see my hourly rate a pricy and so they give up their max budget, as a negotiating tool. In which case I tailor the solution to that budget. In situation B they generally have a budget in which they don't see my cost as even making a dent in. Finally in C generally we would have never had a meeting of the minds in the first place. I don't compete on price, there was a point where I had the price shoppers filtered out of my sales pipeline, but as we are bringing on new clients again, we do end up in situation C from time to time.