Rates and pricing are a huge source of concern for web developers. We’ve all felt at some point that we don’t charge enough or need to figure out how to earn more. If you do any sort of research on the subject, eventually you’ll stumble onto something called value-based pricing. The basic idea is that you deliver a fixed bid on a project that is priced in respect to the value your client will receive from having that project executed. This causes an exponential increase in what you charge.
As an example: A SEO expert pre-value-based pricing charges clients $100/hour and has average engagements of $5000. They figure out that most of their clients earn more than $50,000 a year based on their work and switch to value-based pricing with an engagement fee of $20,000. The SEO expert still does 50 hours worth of work, but now they pocket an additional $15,000.
It’s a big idea that tends to create zealots out of its practitioners and it’s not hard to see why. Who wouldn’t love to be able to quadruple their rate?
Unfortunately, it’s not all sunshine and suitcases stuffed with cash.
I ran into this concept early on in my freelancing career and it was one of the more damaging changes that I implemented. It’s difficult to estimate my losses over time, but I would say that this approach probably cost me somewhere in the ballpark of $100,000.
How did this happen? What’s wrong with value-based pricing? It’s confusing and challenging to implement. And it’s risky.
What’s confusing or challenging about value-based pricing? The concept is a little unusual for people who have been trained their entire lives to punch a time card. However, it’s not too hard to grok once you’ve had time to mull it over. In practice though, it leads to some very murky conversations.
“How many sales do you expect to make with this new website this year?”
“I don’t know.”
“But you’re interested in investing in it, so you must have some sense that it will be successful, right? What does that look like in revenue?”
“Well, we know a lot of people in the industry and think it will do well, we just don’t have an idea of how well. It’s too early to say.”
As another example, imagine a scenario where your client wants you to add a new product page to an e-commerce site with several existing products. The value of doing so is very clear because it’s something that they’ve done before and they know that it’s going to bring them another $50k in sales this year. Now try and tell them that it will cost $10,000 to add a product page. Seems like the type of thing that might destroy their trust in you or make them question your ability doesn’t it? The fact that they will still get a $40,000 return on their investment doesn’t carry much weight.
The risk is the worst part of value-based pricing. It’s damaging in two ways:
Managing scope is a perennial challenge for any web development project. Value-based pricing takes this already challenging aspect of project work and makes it harder. When you work with a fixed bid, there is no incentive to a client to respect the boundaries of the scope. And when you’re charging on value and the price is high, the incentive is actually the reverse, where they feel pressure to get the most that they can out of their investment. This tricky situation is compounded when there is a real need for work that is outside the scope.
For developers who work in open-source markets like we do, you have to work with other developers’ code. That code is of a wide spectrum of quality, but generally not great. Regardless of what due diligence you do in advance of a project, this type of environment is extremely risky and fixed bid projects will punish you on a regular basis when some difficult to anticipate problem rears its ugly head. Under a fixed bid, your client has no need to be flexible in this situation because they’re not on the hook – you are.
The risk of project/flat fees pricing are what ended up costing me all that lost revenue as a freelancer. At one point, I calculated I was coming out ahead 1 in 8 times and then only with a small margin.
After reading all this, you may think that I believe value-based pricing is dumb. Actually, I think it’s an outstanding tool. It’s just not for everyone and certainly not for beginners. It’s sort of like taking someone who knows first aid and giving them a scalpel. Yes, it’s very effective for surgery, but something that is unwise to use for someone who has a sprained ankle.
Value-based pricing is a poor approach for technically oriented contractor/freelancers like I was. This is especially true as risk grows. For example, if you have to build a plug-in between an API and a legacy database on an under-documented technology it is incredibly stupid to try to price on value. (And least you think that if you add a big enough price tag everything is going to fit within it in the end I can tell you based on first-hand experience that your imagination is lacking.)
Value-based pricing is an excellent approach for consultants, consultancies, or products where the problem is valuable, well-defined, and within your control (low risk.) For example, if you know with a high degree of confidence that you can generate between 5,000 and 10,000 unique’s using your SEO skills in a certain market and that if your client in that market currently converts at 1.2% they stand to gain $300,000-600,000 annually and $5 – 10 million in lifetime value then a per engagement fee of $100,000 is a no-brainer.
There is a lot more to value-based pricing than the points I make here and this isn’t a post on when and how to do it well, more of a counter weight to the “value pricing as a panacea” that tends to exist on the subject.
However, I must add as a final point that it is hard to go wrong when using value-based anchoring and still having a flexible unit based rate. In other words, try to identify the value and anchor your higher than average hourly, daily, or weekly rate against it. You get 80% of the benefits of pure value-based pricing and none of the drawbacks of flat fees. (Credit where credit is due! I was introduced to this approach by The Godfather, Brennan Dunn.)