3 ms·

I've been thinking about revising my tactics some, to try to get a potential client to spill what kind of budget they have to work with before I even start thin

I've been thinking about revising my tactics some, to try to get a potential client to spill what kind of budget they have to work with before I even start thinking about anything else. It certainly helps sometimes in picking out project infrastructure ("I have to do this cheaply, so let's get inventive")

kls 15y ago
If they don't give me a budget I give them an hourly rate until I know what budget they are working with. That said, I prefer to work on an hourly arrangement if at all possible.
- rpwilcox 15y ago
  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.

kls 15y ago

If they don't give me a budget I give them an hourly rate until I know what budget they are working with. That said, I prefer to work on an hourly arrangement if at all possible.

rpwilcox 15y ago
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.