How to handle "cheap" clients
Moderator: General Moderators
- Bill H
- DevNet Resident
- Posts: 1136
- Joined: Sat Jun 01, 2002 10:16 am
- Location: San Diego CA
- Contact:
Re: How to handle "cheap" clients
Back in the 60's and 70's the steel business was booming and I was in my own business installing a special kind of machinery in steel plants. There were only 10 people in the country who did what I did and I was considered to be one of the best three, so I was able to dictate the terms under which I would perform services. I did that very happily and to great financial reward until the steel business started declining in the 80's. I continued dictating the terms under which I would perform services, and you notice I became a computer programmer.
I don't know if there is a lesson to be extracted from that or not.
I don't know if there is a lesson to be extracted from that or not.
Re: How to handle "cheap" clients
We (my employers and I) go the other way. We get them to agree to start at the absolute minimum functionality required to achieve what they want. If they want a blog, we agree that the minimum needed is the ability to post articles. They want a gallery? The minimum is the display of pictures and possibly thumbnails.
After we agree that, we complete a sprint or two and provide the initial version. Then we discuss what they want next, and discuss the importance (and any technical limitations) in the priority of user stories (simple descriptions of functionality) and then proceed.
Under no circumstances do we agree what is to be completed as a final product, before we have delivered what the customer thinks is the final product. A bit of a tongue twister, but basically we dispell the myth that we as developers must have a detailed spec sheet before we can even start working.
After we agree that, we complete a sprint or two and provide the initial version. Then we discuss what they want next, and discuss the importance (and any technical limitations) in the priority of user stories (simple descriptions of functionality) and then proceed.
Under no circumstances do we agree what is to be completed as a final product, before we have delivered what the customer thinks is the final product. A bit of a tongue twister, but basically we dispell the myth that we as developers must have a detailed spec sheet before we can even start working.
Re: How to handle "cheap" clients
Jenk: that's an interesting approach. One I might start to use with some clients. An approach like that could also work for clients who are not entirely sure about what they want or need. You know, someone might tell you "we want an intranet, how much does that cost", but doesn't have a clue about what functionality he wants exactly.
I think it will largely depend on the kind of clients you have. Some clients might be afraid that if you only make a deal for the basic functionality (post articles) that the costs will spiral out of control after that. They still want to know what the end result will take.
Thinking more about this, I come to the conclusion that it's simply the case that some people are best to be avoided as a client. Or maybe I should say they're better off with other solutions/ solution providers.
Now the challenge is to find a good way to find the right clients
One other thing I'm well aware of is that the big challenge nowadays is, is to make sure one escapes the devaluation of the web design business. I mean, ten years ago building a website or webapplication might have seemed like a complicated thing. Nowadays many people think that building a webapp is a matter of starting up your front-page like program and drag-and-dropping for a few hours.
I think it will largely depend on the kind of clients you have. Some clients might be afraid that if you only make a deal for the basic functionality (post articles) that the costs will spiral out of control after that. They still want to know what the end result will take.
Thinking more about this, I come to the conclusion that it's simply the case that some people are best to be avoided as a client. Or maybe I should say they're better off with other solutions/ solution providers.
Now the challenge is to find a good way to find the right clients
One other thing I'm well aware of is that the big challenge nowadays is, is to make sure one escapes the devaluation of the web design business. I mean, ten years ago building a website or webapplication might have seemed like a complicated thing. Nowadays many people think that building a webapp is a matter of starting up your front-page like program and drag-and-dropping for a few hours.
-
malcolmboston
- DevNet Resident
- Posts: 1826
- Joined: Tue Nov 18, 2003 1:09 pm
- Location: Middlesbrough, UK
Re: How to handle "cheap" clients
well in my experience (UK), i am yet to work on a freelance role by the hour, i just cant see how people can do this, i could not imagine getting a spec and then quoting the client £50 / £60 per hour, right there you will lose alot of interest, i find its much better to set a final fee, that way the customer knows exactly how much it will cost and it doesnt look like your 'over-pricing' yourself.
Although most clients in my experience are absolute nightmares and i really only deal with businesses i know now.
Although most clients in my experience are absolute nightmares and i really only deal with businesses i know now.
Re: How to handle "cheap" clients
It's certainly not easy to start with, but once the ball is rolling all of our clients agree it is a much more sane way to develop. It's very difficult for anyone to decide what they want until they have something to either compare to or play with. I think the best benefit of Agile and Scrum is that the customer gets a working product ASAP, and then can decide what niceties they would like. I've been involved in stuff in the past where we have developed to a spec sheet, then later in life the customer won't use a majority of the functionality. For me as the developer, that's not really a concern - they still paid for it, but as the customer it should be a concern as it is wasted expenditure. They also went without a product for "x" time whilst waiting for that extra, defunct functionality to be completed.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: How to handle "cheap" clients
All very interesting. As a young developer, I'll keep all of this in mind. 
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Re: How to handle "cheap" clients
Budget is something that needs to be discovered in the first few minutes of a client conversation. If their ballpark estimate is too low I'll politely drop them right away. It's simply not worth the headache.
I'll go so far as to estimate the number of hours a certain feature set is worth, but I make it very clear that all the work will be done and billed by the hour. I also make it clear that the final cost depends more on them than it does on me. The advantage to this is that they'll never hear "no" when they want to add or drop features, rather I'll give them an estimated number of hours they're adding to the project. Again: the keyword here is "estimated".
The way to make this work is to follow an agile / prototyping workflow, releasing the app often with incremental degrees of functionality. This seems to keep clients happy, since they're never waiting for "the product" and a mystery bill. The point at which they release is up to them. The development cycle eventually slows to a stop, but the project is never "over" per se.
To make this work on my end I bill and collect in weekly increments; there's no "release milestones" when I collect a lump sum and hand them some code. If at any point either of us wants to cut and run, they own the last code they purchased and I'm at most out a week. Also, if the payments stop so does development. Net 60 is the bane of a developer's existence, and I won't go through that ever again.
I find that this fosters a much healthier relationship between developer & client. It helps each approach the task as a joint project, rather than thinking that the developer is selling them a "product". Also, the app ends up being a better fit for the client since they get to play with it as you develop it. Specs are almost never a good description of what a successful app looks like.
So in this case, cheap clients never make it past the initial meeting. And if they do squeeze by by some miracle, they don't last a week.
I'll go so far as to estimate the number of hours a certain feature set is worth, but I make it very clear that all the work will be done and billed by the hour. I also make it clear that the final cost depends more on them than it does on me. The advantage to this is that they'll never hear "no" when they want to add or drop features, rather I'll give them an estimated number of hours they're adding to the project. Again: the keyword here is "estimated".
The way to make this work is to follow an agile / prototyping workflow, releasing the app often with incremental degrees of functionality. This seems to keep clients happy, since they're never waiting for "the product" and a mystery bill. The point at which they release is up to them. The development cycle eventually slows to a stop, but the project is never "over" per se.
To make this work on my end I bill and collect in weekly increments; there's no "release milestones" when I collect a lump sum and hand them some code. If at any point either of us wants to cut and run, they own the last code they purchased and I'm at most out a week. Also, if the payments stop so does development. Net 60 is the bane of a developer's existence, and I won't go through that ever again.
I find that this fosters a much healthier relationship between developer & client. It helps each approach the task as a joint project, rather than thinking that the developer is selling them a "product". Also, the app ends up being a better fit for the client since they get to play with it as you develop it. Specs are almost never a good description of what a successful app looks like.
So in this case, cheap clients never make it past the initial meeting. And if they do squeeze by by some miracle, they don't last a week.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Re: How to handle "cheap" clients
Dude, I like that approach. Methinks I'll be stealing that idea very soon.
Re: How to handle "cheap" clients
Indeed, good approach. I'm going to steal it as well.
Although I think this approach mainly works for web applications. When a client wants a "basic" 10-page website, I don't think it'll work. "Let's start with the left column, I'll bill you 8 hours for that and we'll see how to go on after that"
But asking for the budget sooner then later is a very good thing.
Although I think this approach mainly works for web applications. When a client wants a "basic" 10-page website, I don't think it'll work. "Let's start with the left column, I'll bill you 8 hours for that and we'll see how to go on after that"
But asking for the budget sooner then later is a very good thing.
Re: How to handle "cheap" clients
That's exactly the same process I was describing, plus every iteration you discuss with the customer what they want next.
It's a pet peeve of mine when it's called "prototyping" it's not prototyping at all, it's releasing
It's a pet peeve of mine when it's called "prototyping" it's not prototyping at all, it's releasing
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How to handle "cheap" clients
Hahaha...who said they handle cheap clients with a gun...haha...that was funny. Although, now you have the FBI monitoring your every move. 
Big Brother is watching you amigo.
Big Brother is watching you amigo.