How to convince a client that "expensive" is "cheaper"?

Question

Many clients see only the "per hour" price and go "eek" and choose a "cheaper" coder to do the job. Very often these clients ends up with a complete MESS because they wanted to save a couple of bucks per hour.

Just because one consultant charges $100 - $200 per hour does not mean he is more expensive for the client. One coder might do the same job in a fraction of the time the cheaper coder can do it in.

Not to mention that the cheaper coder will often end up creating a complete mess of the project, making it completely un-maintainable and forcing the client to do the "big rewrite" after having spent three months and 480x$20 with some "cheap guy."

But the Grail question here is: "How do you convince a client that he'll SAVE money if he uses you for $200 per hour compared to some other guy for $20 per hour?"

Note that I do not mean to generalize here saying that all cheap consultants are bad. Some cheap consultants are probably great coders, but often when you think you are saving some few bucks you are really just damaging yourself and your project...

Answer 1

It's very difficult, but I would try accurately scoping your project and offering some kind of guarantee.

If you are as good as you think you are, I'd inform your client that good specs are important and a good starting point, and that he should start out by investing in a cooperative effort to produce very specific specs.

When the specs are restrictive enough offer a max coding cost to meet those specs. (Maybe 1/2 pay until delivery, the other 1/2 on acceptance)

If the others are as bad as you say, they won't dare match your offer because they know they'll go over on time (and even if they go with them, you come in and fix it because the client will have only spent 1/2 his budget and will have less of a commitment to them).

Answer 2

My advice is: show the client some of the articles that show how some programmers can be literally ten times more productive than other programmers.

This article gets the point across and is well-written, with many references.

This one by Joel is also good.

Now that he's convinced someone can be 10 times more productive, you just have to show him that you're one of those top-tier guys, and that the $30 an hour coder likely isn't!

Answer 3

It all depends on what the client thinks they're buying.

• Hours? If all they're buying is someone who shows up and types, cheaper is best.
• Quality? Perhaps cheaper isn't best.
• On-time delivery of usable functionality? That's what they want, right?

You you can't compete on price, then don't dwell on it. Dwell on what you can compete on.

You seem to be focused on quality -- you don't create a complete mess. That's a start. Do you offer anything else? Can you phrase that more positively? What's a positive, discernible attribute that's equivalent to "not a mess"? What's an offer that someone would pay for that's "not a mess"?

All you can do is make an offer. What specific, tangible things are you offering?

Answer 4

In my experience, you will have a hard time convincing them if you are in the role of the aforementioned consultant. Many companies, large and small, look at up-front costs and nothing else.

If you have an existing clientele, you can solicit recommendations and/or develop case studies. Chances are you would have at least one client who has learned a lesson from shopping for a discount.

Answer 5

Don't try to convince them that expensive is really cheap or vice versa. They are too smart for that.

Talk to them about the investment that they are making in the system. Then show them the value you are going to add that the next guy is not (e.g., actual documentation, a real design, code that is maintainable and expandable, and perhaps even risk-mitigation - if you go over schedule are you going to eat the overage).

If that's not enough, consider offering a cut rate for cut services (good enough to do the job, but not all the extras).

Answer 6

This is a difficult one!

In my experience, a lot of this sort of thing is down to trust. The catch-22 is that until you have worked with a client, they probably won't have the level of trust they need in you to truly believe what you're telling them.

It does depend on your personal circumstances and how well the project is defined in the first place, but as a way of getting 'in' to the client (in order to build that valuable level of trust), why not suggest working on the project for a fixed, project fee?

There is an obvious element of risk to you in doing this - but if the project is well defined and you manage change throughout the development, you will actually be in a position to demonstrate what good value you can deliver. Once you have done this, you will have living proof that you're worth every penny and can talk to them about hourly rates for future work.

In my opinion, supplier-client relationships for software development done on an hourly rate are often strained due to the nature of what we do. How many times have you developed something which you thought would take half an hour only to hit a problem that lasts a few hours? Whilst it often works the other way around as well, you're setting yourself up for a fall trying to manage your client's expectations when the total price they pay can vary so wildly!

We always work by quoting fixed project prices against a fixed specification and then manage change requests from there. This way the client knows exactly what they're paying from the outset. It does mean that we run the risk of overrunning in terms of time, but there are the occasions where we run under, too. We're constantly improving our quoting processes - but the main thing is, all of our customers are happy pretty much all of the time, and we have several lucrative, long term clients who trust us as a result.

Answer 7

Offer a "recovery" service for those who have made this mistake and are trying to sort it out properly.

Offer it to clients when they turn down your "expensive" offer to make them think.

Answer 8

You need to have cases you can present where the value of the systems you provided far exceeded the expenditure.

References are going to be very important, as well as the professionalism and experience which you show when discussing their pain points. Demonstrating a good understanding of their problems is going to quickly undercut any price advantage they might see in other developers, because invariably the "cheaper" producers are not good at communicating or listening to clients.

If you don't end up getting the job, remember: that it's not necessarily your fault or a bad thing. They could have turned into your most horrible client. They are entitled to make bad decisions and until they hire you, it's not your responsibility to stop them from making them. Even when they do hire you, there is a limit to your obligations and power to stop them from doing immensely stupid things.

It is not going to be a lot of use trying to differentiate yourself using studies and papers as a much more productive programmer to people who aren't technical enough to already know the difference. It will never come off right. That's only good for you to know when you are hiring.

Answer 9

We’ve ran into just this same problem. We had one customer, when push came to shove, always wanted our most experienced developer to do his work. We charged a blended rate, so he figured why would he want less experienced developer to work on his project, when he could have the more experienced one?

Which I can totally understand! If I have a plumbing problem, and the cost to me of the master plumber and apprentice plumber are the same … well I want the master plumber to fix my problem! I don’t really care if the apprentice plumber can fix it, there’s no apparent benefit to me to have him do it when I can have the master do it.

I would also argue that the cost and skill involved too actually code the solution is far less than the cost and skill involved in the design of the solution.

What we have since done is created two rates, a lower rate for development, and higher rate for consulting, design, implementation and training. This has allowed us to show our customers that for such and such a feature it requires X hours/dollars in design and X hours/dollars in development. Now our more experience developers can focus on the design and project management, while our less experienced developers can code.

So far it seems to be working, and most importantly, the customer understands and is happy!

Hopefully that made some sense!

Answer 10

An analogy may help:

"building a software system is similar to building a house in many ways, in that you are going to have to live with the outcome and maintain it for quite a while. Would you rather live in a house that was designed and built by one master carpenter, or a dozen apprentices?"

then you must prove that you are better:

1. tell the customer about your personal success stories
2. offer to put them in touch with your satisfied customers for references

If they still balk at the price, politely say thanks and walk away. You have nothing to gain from arguing with a potential customer, and only undercut your value by offering 'special deals' or 'discounts' to get the business. If you believe that the value you add is worth X dollars per hour, stick to it.

Answer 11

Short answer - "you don't".

Instead, you have to find ways to maximise your return given the innate biases and traits of the human brain (which you wont be able to persuade or change cost effectively).

One of the most successful pricing models in this regard (it seems to me) is the ongoing monthly fee (see mobile phone plans/companies' eagerness for direct debits). Human beings just aren't very good at adding up, so they don't realise that the 30 bucks a month on their phone adds up to 360 bucks a year, plus sales tax.

Of course, the other widely used tactic is to charge for something immeasurable and intangeable such as "convenience" or "quality" or "luxury".

Another ploy is to confuse the customer (see mobile phones again).

Another is to lock them in (see Microsoft, Apple, Nintendo, Sony etc).

All of the above enable a lower upfront cost, but retain a good return over time.

Answer 12

Did you know that according to the CHAOS report from the Standish Group, only 29% of software projects are considered successful? The reason why my firm charges a higher rate is closely tied to these statistics - we really know software, and our failure rate is much better than that.

It is possible to find cheap developers. Indie devs who moonlight as consultants can work at a fraction of our rate and they don't have to bill like lawyers, but there are downsides, not the least of which is that, if they happen to have the skills to create working, flexible software, they have other priorities and won't always be available when you need them. Or they might make themselves invaluable and dissapear... Actually, this happens a lot.

Read some books like The Mythical Man Month and Dreaming in Code. They are full of awesome, horrifying, educational data. This is actually a favorite subject for me... Many managers think they know all about the software game because they know about other games.

They don't have any idea how hard this really is, and the key is conveying that while letting them know that you can make it easier and guide them.

And that's the truth.

Answer 13

I don't bother getting into this debate. I'm always busy anyway, and if people complain about the price then I always politely suggest that they use their cheaper consultants.

My relationships with clients tend to outlast many/most/all of their so-called 'permanent' engineering staff, so I must be employing a viable strategy.

Answer 14

Do an ROI (return on investment) calculation. Show them the numbers. Using $ as your unit of measure is very powerful.

Answer 15

First, you have to change your terminology.

There is a HUGE difference between "cheap" and "inexpensive." Make this absolutely clear to your customer, and you'll have won half the battle.

The next thing is to make sure you are adequately selling yourself. Don't try to tell them that you're better equipped to handle the project than the other person, SHOW them.

• Demonstrate that you have a better grasp on their particular project
  • Ask intelligent questions
  • Write everything down in a nice bullet list
• Draw a system diagram that shows how you might implement the project given what you know about it.
  • Teach them about the components you've drawn and why they're important to their project

There are a lot of things in this vein, but at the end of the day you want them to walk away from you thinking, "This guy could implement my system in his sleep."

The second objective here is to fill them with information that the other coder might not be able to similarly answer. Done right it's not simply filling them with buzzwords, but with real concrete information that raises issues a poor programmer wouldn't be able to deal with right off the cuff.

Lastly, don't worry about it.

You REALLY don't want the customer that cares more about price than quality. If the above hasn't convinced them that you are the better programmer, please, please throw them to the wolves, if only for your sake. They are NOT worth your time and energy, until they've been burned once or twice.

It doesn't sound nice, but don't spend your life chasing after bad clients. If you are a good programmer it may take awhile to grow your business, but the clients you have will be worth having, and you won't be tearing your hair out.

Answer 16

If the client is simply focused on cost, put your money where your mouth is:

• Offer to fix bugs for free (Just be sure you define EXACTLY what a bug is - which is hard to do).
• Provide free (or reduced cost) support for some length of time (again with clear definitions of what this means)
• Guarantee an average level of development experience on the project
• Cap the costs, and provide overruns for free (just make sure you define "done")
• Cap the time, and provide overruns for free (again, better define "done", and estimate well)
• Demonstrate good will - offer up a preliminary design document, simple prototype, something, anything to demonstrate interest in the client, and the quality and professionalism you offer.

Simply being more expensive does not imply/guarantee quality, in the same way that being inexpensive does not imply/guarantee a lack of quality, so instead of assuming that the potential client screwed up by selecting the cheaper alternative, I would ask what did I lack that caused them to select the cheaper alternative. Often times it is as simple as communicating and differentiating the value in terms they understand.

Of course, some clients just aren't worth the trouble and once you identify them as such, I would simply not bother.

Answer 17

Everyting you say in the question is right on the money. Maybe you could get the customer to discuss risk.

How about offering the customer a specified solution at a fixed price, assuming unto yourself all the risk? Would you then put your expensive or your cheap developer on the job.

Would your customer accept a fixed price? What kind of premium would you need to charge for carrying that risk?

Or would your customer rather carry the risk? How much risk would they want to carry for the upside of having the possibility to save a little bit.

And, ultimately, how bad do you need this customer? Do you risk your business by turning this customer away?

Also, developement does not scale. A good programmer can do in a short time something that a bunch of average programmers will never be able to do.

Answer 18

You need to read thedailywtf.com and observe that expensive solutions often turn out to be as expensive as cheap solutions.

You need to read stackoverflow.com and observe that correct answers get downvoted to negative scores, so there is nowhere to go.

Answer 19

I have a very simple solution to this problem, which I use every time, and has never failed me...
Don't give them your hourly rate!
Find out what they want done, and quote them on a turn-key solution.
Absorb the risk of misquoting on your side.

I've even gone to the point, with some skeptical clients, to agree on "penalizing" fees for late delivery. So for each day late that I delivered, they'd pay me $xxx less.

This, for the client, is the best value proposition. If you are more expensive per hour than the other consultant, but you are much faster, you end up being less expensive in the long run. And the client can see this in the cold hard numbers you give him. Plus, you absorb the risk of delays.

Explaining to a non-technical buyer the advantages of good, maintainable code, etc is, in my experience, too subjective. They kind of get the concept, but they have no idea of how important it really is.

However, letting them be able to compare final prices, and knowing they have no risk with you is a very strong selling tool.

Just my 2 cents.

Answer 20

The biggest thing I have learnt is that business is perception. Reality backs it up. Not the other way around, for some reason.

That being said, I believe:

• Value Generated > My Pay: I am hired to generate more value for my customer than I am paid for. Whether its profit, a new product, or savings through efficiencies, I am working to permanently keep money in my clients pocket.

• Get more done with less effort. This is my measure of anything I do. If the client can handle more work, with less effort, I have succeeded. Merely offsetting the workload from one person to another doesn't always work.

• Act in client's best interest. I work to gain the trust of my clients that I am making decisions in their best interest, not my own. How else can they be sure I am not sitting here to ring up work. Software developers are a chivalrous group and this is one of our big positives.

• I enjoy your project, but it isn't my life. I make it clear I am not interested in "make work" projects. I have things I want to do and wasting anyone's time is not my priority.

• Educate them on benefits. I actively make decisions in their best interests that they know I could have made another way and I make sure they know that I saved them money, got it done quicker, or got them more for their dollar. This one thing has led me to more work. One client, more educated about the details of their own business thanks to you, will be happy to look good to introduce you to someone they know.

• Understand the detail. I make sure that I understand the details of their business as well as, or better than them. Becoming a problem solver is the highest value in any organization. It also helps clients understand that it is a mutual investment in the relationship. I can't cash out my knowledge, but I can help them build and retain tools within their organization that capitalizes on what I have learnt.

• Build tools/systems, don't be the tool/system. I don't make anyone dependent on me. I have to do some stuff that I would rather not. That's okay. Where there is a budget to create a tool to move something I do in-house, I do it. Often this is rewarded with more work, because you recognize that your higher rate is better spent in-house.

The other things I try to have my clients consider directly, or indirectly:

0) Hours in the mirror are larger than they appear. People working at a lower rate will bill more hours. People who bill higher typically need a fraction of the time to do the same work.

1) Often, it's not what it costs, it's what it will make you.

2) Perception is reality. Make sure you are perceived as and provide value that no one else can.

3) You don't get something for nothing. You get what you pay for.

4) Would you let someone build a house for you because they built a shed without a blueprint in their spare time?

5) If the design of a house is done poorly, will you spend a lifetime spending money maintaining faults?

6) Uncle Pareto runs the universe. You will spend 20% of your time coding, and 80% of your time maintaining that code. The better and more efficiently you write now, the cheaper it will be long run.

7) Short term pain = Long term gain. Do it right now, or do it over when it can't grow with you and you have to re-build.

8) If I create value for my clients, where they profit ten fold or 100x from what I am paid them, is it a fair exchange?

9) If I do the work of 3 or 4 people, or juggle more roles, and hats that don't require other people to be brought in, should I not be worth more? Conversations between consultants are not a good place to be spending money

10) If I help them get more efficient, handle a higher workload, creating more revenue, and some greater degree of profit, with existing levels of staffing, which someone cheaper may not understand.

11) If I save the company 1 hour per week, forever, that is 52 hours a year at their average salary rate. If they pay an average of $15/hr, I have just saved them They get to have that savings of $780 per year, forever. If they have to pay my rate once, they will get that forever.

Thanks for asking the question, it's nice to have an excuse to write this up for myself.

Answer 21

If we look at the present scenario the importance of growing your business and expanding your online brand recognition using all the strategic SEO elements available can just not be overstated. Today to be the very best at marketing the business or even the websites has to reach to its potential customers and hiring SEO companies and SEO experts is proving best method to keep track of the latest developments in search engine optimization. In this article, know how taking help of SEO services from any SEO company can actually boost up your sales.