Ask HN: Is value based pricing always better than hourly billing?
I agree that pricing projects based on value is a better way to leverage your personal value to make more money and create an amazing product for your clients.
However, at what point is someone able to offer value based pricing? For newer freelancers or business owners, is there a "pay your dues" period where hourly billing makes sense until you're more established? Should someone get a really solid handle on their hourly rate before they start pushing into highly profitable pricing strategies?
I'd be curious to hear perspectives from newer freelancers being told they should perform value based pricing. I'd also be interested to hear about the path more experienced freelancers have taken from early freelancing days to very profitable pricing techniques today.
16 comments
[ 4.9 ms ] story [ 42.5 ms ] threadAnother advantage of fixed price quotes is that you don't need to worry about "do I charge for fixing bugs", or "do I charge for phone calls/emails/conference calls". All of that is included in the quote, making things simpler and fairer for everyone.
As a small freelancer, fixed-bid is a nightmare. If the client doesn't have a good spec, you'll be haggling whether it's done or not. You show the client your version, then the client realizes what they really wanted all along (which doesn't match what they originally told you), and now they're refusing to pay until you make the changes.
Having spent a couple of weeks on the project, when the client asks for more work, the incentive is for you to do it so you can get paid for the work you already did.
As a small freelancer, it doesn't pay to spend the legal fees to write and enforce a contract.
If you help the client write a spec before starting the project, then they'll just shop it on one of those elance sites and then they won't need to hire you at all.
So I've seen fixed-bid be a nightmare, both for the employer side (maintaining someone else's garbage) and from the client side (you'll do the work, and then spend most of your time arguing if it's done or not so you can get paid).
Fixed-bid pricing encourages shoddy work. You do just enough to get paid and no more. It's a race to the bottom.
The advantages of hourly pricing is that it clarifies that the client is paying for services not products. This is particularly useful when dealing with amateurs and anyone else with a "consumer mindset." It is also useful because on projects where the value I provide comes in discreet chunks - some preliminary design sketches have value that is different from a specifications manual is different from a report is different from comprehensive construction documents is different from reviewing contractor bids.
Hourly proposals are also easy for me to write...indeed I can quote my rate and get people who really should be off the phone off the phone quickly.
Fixed fee proposals are better when the potential client already has established some value for the work...i.e. the sales lead is a professional running a business and even if it is their first time at this rodeo, they've been to others that are similar. Fixed fee pricing works well when the potential client knows the sort of value I can provide already and has realistic expectations of their project.
The key to profitable pricing is not to buy jobs. Set your rate or come up with a price that's profitable and if the person writes the retainer great and if they don't you have to be ok with walking away from a job that doesn't match your requirements.
As an aside, I'd consider thinking about projects as services rather than products. Products imply something bought that is complete and can be returned if the customer isn't happy. Services are paid for as they are performed.
Good luck.
By the other hand, for a programmer (I have much less experience here), billing value based and fixed-fee is more risky. The specs are not so clear as in the architectural field and even (apparently) small changes that don't add a lot (if any) value for the client can multiply the time that you spend in a project.
Something else to consider, if you want to make real money you are a "consultant" not a freelancer and certainly not a contractor. Also create an LLC or corp, I have found that clients don't flinch at all when I am a real business, nor do they try to offer me a job instead of a consulting gig. For 5 years I could not pick up a single side gig because the potential client would always offer me a job, but refuse to offer me the gig they claimed I was coming in for. I would always explain to them that I needed to make "real" money, trading one low paying salaried job for another slightly higher paying salaried job did not help me one bit. I needed the ability to make 2-3 times what the typical senior software engineer makes. They would get offended, I would leave. Funny enough it wasn't until I quit my salaried job, with no gigs lined up, no plans to get another job that the gigs started to happen.
Once I started saying I owned a business and stopped saying I was a freelancer, I could immediately charge more and my referrals got better. I was no longer the "I know a guy that does development" person. I became the "I know a web company" referral and companies are expected to charge more than freelancers.
For example my most recent gig, the client, a start-up, had a product already in the field. However for development and manufacturing testing they did not have any tools to test the device. They wanted a tool to manually control the device, if possible they wanted a custom script environment added, and they had some device driver issues. Because they already had working code for all of the functionality of the device I explained that I could port the existing code over to the test application. Based on the scripting requirement I recommended using IronPython, Scintilla .net for a nice context highlighting text edit interface, and for their device driver problem it was a matter of walking the device driver stack to make sure the intended device was selected as they had multiple identical devices attached. The hardest part was that the device was written in C++, but they wanted the tool written in C# using .NET. So I had to translate the working device while I was creating the tool. They did not question my ability after I quickly followed their explanation of what the device was, how it worked and what they wanted. Within a couple of days they emailed me a contract, and about a week later they shipped their hardware as I work from home and in another state.
I have turned down gigs because I don't "work" in California, I refuse to pay the ridiculous taxes and deal with all the paperwork. I live in Nevada where there are no state income taxes, one less headache to worry about. Telephone, email and Skype are all that are required to communicate.
As for doing a technical interview? If asked I would never do one, I am a professional. No one asks a Lawyer to solve some legal problems and write example contracts, no one asks a doctor to do some sample examinations and provide a written diagnosis. I have references, I will talk about past work as long as I am not giving away any confidential information. If that is not good enough than I don't need to waste my time with the client. They are free at any time to have me stop working for them if they are not satisfied, considering that recruiters charge 15-20% of a years salary to bring someone on board it's quite a bit cheaper to have me do some work and decide I'm not living up to their expectations (that's never happened).
I'm thinking exactly this, just wanted to make sure this practice of refusing to tech interviews exists, and it won't be considered as being rude... Thanks for the detailed answer!
If the project's fixed bid is approximately your actual estimate (hours estimated x price/hr), then definitely do not propose a fixed bid. There is a lot of risk and ambiguity in lowball fixed bids that will cost you in the end. We all know that engineering estimates underestimate ... and that clients will always add/revise. So, why are you putting all of the risk on yourself for exactly what you would normally estimate? These situations are where freelancers get in big trouble with fixed-bid contracts.
On the other hand, suppose that your work is a huge value-add to the client. Suppose the client cares mostly about high quality, wants a good reliable consultant, and wants you. In this case, you can price your fixed bid in line with the value it will bring to the client. Meaning that now the risk is negligible -- even if your estimates are off and the client revises things, you will still be happy with the outcome. Now that you can relax, you can spend more time on delivering quality work and even give freebies if everything is on track!
Let me emphasize -- the only successful fixed price bids I've seen are where you know that even if everything goes wrong a developer still is happy with the outcome. After all, in most real-world pricing situations, the cost of the risk is part of the price (e.g. shoplifting losses), so why not for software engineering too?
The advice for value vs hourly, weekly etc is really highly dependent on the type of work you are doing. I routinely give this advice, but if you looked at the majority of our development work we get paid weekly per resource. Where we do value based pricing (and where I suggest it) is not generally on active software development projects where we are slinging code. Instead, we use it more where we are the experts brought in for training, education or business/technical reviews. In that way your risk is significantly lower but the value to the client is, many times, much higher than your hourly wage would dictate. For example, a business might easily pay $5,000 + travel expenses for a 3 day on-site training package that if you charged by the hour might net you $3k or so.
In some instances when we feel very confident of the project or the scope is extremely small, we will value price it so we can make a better margin. Although I do this less and less if there is every code being written.
Overall, the other comments are generally pretty accurate. Hourly/weekly pricing tells the client they are paying for effort not a specific result as it will likely change based on their input (although this can still get ugly sometimes). Additionally, any fixed rates generally lead to almost an unchecked scope creep that makes life unbearable for a small team.
Usually, the model amounts to becoming a preferred vendor or partner (value based sale) versus a contractor (contractor based pricing); more on that, if you value based price, often it means there is a symbiotic situation that needs constant communication and nuturing to ensure success, which brings you closer to the client.
Usually, the model amounts to becoming a preferred vendor or partner (value based sale) versus a contractor (contractor based pricing); more on that, if you value based price, often it means there is a symbiotic situation that needs constant communication and nuturing to ensure success, which brings you closer to the client.
It should be noted that some products are viewed as commodities, and value based pricing will be extremely difficult. This can be so with some services as well. This usually occurs with more well-developed markets with abundant competition, where it is easy for clients to switch between vendors. Value based pricing usually requires your solution to be somewhat tailored to their needs to work properly.