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

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.

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.

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.

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?

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.