1) They ask about it, which may be because they know a little bit about it. For example they tried to DIY it and failed, or they have a half finished version another developer did. Or they want to know how big the market is to get someone else to finish the project if you don't pan out for them.
Or they just have heard some vague stuff that they have read on blogs "Is Wordpress or Drupal better for SEO?" as if the choice of platform is going to rocket them to the front page of google...
2) I ask about it. Because sometimes they already have hosting that they want to use, in which case obviously you need to make sure the technology is going to fit that. The hardest thing sometimes is trying to persuade someone that the uber-cheap hosting provider they've chosen sucks and they'd have a better experience is they paid a few more $ a month.
I've been burned by this before, developed a system for a client. Installed it on their server and then found out they don't support PHP5 or PDO or anything even remotely modern and won't enable it for you.
Shouldn't you ask what features the server supports (and what they can enable) before you even start developing? (Or whether you can host it yourself (in the case of websites))
If the client is insisting on hosting the solution (instead of you offering to host it in a controlled environment), then I assume the client has technical people in charge of hosting - and I would make it a point to meet them before I even start development. Otherwise, you'll get bitten needlessly. If they're inflexible (e.g. low PHP version, or no mysql, etc - then you need to incorporate those constraints into your requirements. (Or fire the client)
This is often a red-flag that they're ging to dick you around on other stuff as well.
We have a strong policy about advising clients like this up-front something like: "Of course we're happy for you to manage/engage your own web hosting. Are you going to be using them or us for first level support in case of problems? We're happy either way, and our usual $150/hr hourly rate, but if you'd like us to be the first point of contact you'll need to supply us with details of your support contact at the hosting company, and authority to incur support cost with them when required."
Not necessarily. I've had some very good and well-intentioned clients in the past where they simply registered a domain through goDaddy and didn't know any better, or some other cheapass set them up.
I simply inform them in a candid way what the problem is, and if they're reasonable they'll probably switch services or find a way to accomodate. Otherwise if I detect a tendency for cheapness, then I know there either needs to be a longer discussion or that they are in fact a red flag.
Sometimes it's also a pretty good discussion early on to help to start getting the feel of the type of respect and consideration potentials clients may hold for the consultant's advice.
Comments
It can come up for a few reasons.
1) They ask about it, which may be because they know a little bit about it. For example they tried to DIY it and failed, or they have a half finished version another developer did. Or they want to know how big the market is to get someone else to finish the project if you don't pan out for them.
Or they just have heard some vague stuff that they have read on blogs "Is Wordpress or Drupal better for SEO?" as if the choice of platform is going to rocket them to the front page of google...
2) I ask about it. Because sometimes they already have hosting that they want to use, in which case obviously you need to make sure the technology is going to fit that. The hardest thing sometimes is trying to persuade someone that the uber-cheap hosting provider they've chosen sucks and they'd have a better experience is they paid a few more $ a month.
I've been burned by this before, developed a system for a client. Installed it on their server and then found out they don't support PHP5 or PDO or anything even remotely modern and won't enable it for you.
Shouldn't you ask what features the server supports (and what they can enable) before you even start developing? (Or whether you can host it yourself (in the case of websites))
If you do that, you are talking about technology.
If the client is insisting on hosting the solution (instead of you offering to host it in a controlled environment), then I assume the client has technical people in charge of hosting - and I would make it a point to meet them before I even start development. Otherwise, you'll get bitten needlessly. If they're inflexible (e.g. low PHP version, or no mysql, etc - then you need to incorporate those constraints into your requirements. (Or fire the client)
They don't usually have ops teams, they've just bought whatever the cheapest hosting is usually.
This is often a red-flag that they're ging to dick you around on other stuff as well.
We have a strong policy about advising clients like this up-front something like: "Of course we're happy for you to manage/engage your own web hosting. Are you going to be using them or us for first level support in case of problems? We're happy either way, and our usual $150/hr hourly rate, but if you'd like us to be the first point of contact you'll need to supply us with details of your support contact at the hosting company, and authority to incur support cost with them when required."
Not necessarily. I've had some very good and well-intentioned clients in the past where they simply registered a domain through goDaddy and didn't know any better, or some other cheapass set them up.
I simply inform them in a candid way what the problem is, and if they're reasonable they'll probably switch services or find a way to accomodate. Otherwise if I detect a tendency for cheapness, then I know there either needs to be a longer discussion or that they are in fact a red flag.
Sometimes it's also a pretty good discussion early on to help to start getting the feel of the type of respect and consideration potentials clients may hold for the consultant's advice.
100% agree, I learned the hard way.
It depends on your clients - some of ours do just that, others might actually have ops teams.