Ask HN: Is value based pricing always better than hourly billing? | Hacker News Reader

Ask HN: Is value based pricing always better than hourly billing?

25 pointsaarkfeld15 comments

It seems to be a common consensus that value based pricing is 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.

View on HN

I have always billed hourly, daily or weekly. I would never offer a "project" price. The client never really knows what they want, they just think they do. In order to properly estimate a project you have to know everything that needs to be done, then you have to draw up an iron-clad contract that prevents the client from claiming something new was, or should have been included in the price. It also gives the client no incentive to be economical with your time. By billing hourly their incentives are aligned with yours, they will want to waste the least amount of time possible in order to keep their billable hours down, they will drop features they really don't need, they will be unable to deny payment claiming the project wasn't completed. After all they are paying for your time, not for the result. The caveat of course is that you really have to deliver, and as you do they forget about the hourly billing. As long as they have problems and you keep solving them, they will just focus on getting their pain points taken care of.

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.

I completely agree that clients respond to you differently when you're a real business instead of a freelancer, contractor, etc.

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.

One question: before offering a gig to you, do clients offer you to take a technical interview? And do you agree to take it?

I have never been asked to do a technical interview before being offered a gig. They ask about my experience, from there they tell me about the problem they need solved. So far I've always been familiar with their problem, I will immediately follow up with a high level description of how I will solve their problem (this is during the meeting and without doing research).

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).

> As for doing a technical interview? If asked I would never do one, I am a professional. No one asks a Lawyer...

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!

Many of the responses seem to misconstrue "value-based pricing" with "fixed-bid pricing".

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?

For context, I have owned a couple of different consulting firms since the late 1990's, and have made a ton of mistakes and learned a great deal (still am).

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.

At my job, they hired a contractor to do a wordpress site on a fixed-bid contract. The contractor stopped answering our calls and now I'm stuck maintaining the POS.

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.

My experience freelancing is as an architect, drafter, and designer over more than 20 years. Both approaches have their advantages when proposing on projects.

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.

While a freelancer architect I will always bill value based and fixed-fee. IMO the extra costs that you might have to support are less relevant then the peace of mind of having clear numbers since the beggining. The client knows how much he will pay and will not be suspicious of your billing.

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.

Both have a place. If a project is fixed in scope before the job starts, value based pricing seems to be the best to maximise profit. But what if a job is undefined? I sometimes offer a hybrid model where I do fixed pricing + and hourly spillover rate. This way things are upfront if you have a client asking endless changes or other non-agreed tasks. And it's really important to scope what is included so this is agreed upfront. If the clients whim changes its easy to point out this isn't in the scope and will go to agreed hourly rates without discussions about what is expected happening half way through a project.

I find the the "extra" changes can usually be nailed down and put into a new quote.

Another 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.

It depends on the service being offered mostly. Often, in b2b sales, its up to you to understand how much value your service will generate for the client, and how to correctly price that. For instance, offering a service that could double a clients revenue would be very interesting for them, and you could try to sell it as such. However, you will have to compete for others who may simply offer service based pricing.

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.

Not entirely relevant, but want to offer a different perspective on the topic. As a recruiter, I also used to try out different pricing strategies. It's tough and the winner has continually been contingency (only pay if you hire my candidate). So there are multiple forms of "value-based" pricing and the sky's really the limit in certain forms.

I charged hourly for the first 10 years or so. Eventually I reached the point where quoting hourly made me sound like a crazy person and derailed most negotiations (because my number was so high), so I started quoting by project. Never looked back. Got most of my tips from Brennan Dunn's podcast. Worth checking out.

Reply on news.ycombinator.com