
Ask HN: Is value based pricing always better than hourly billing? - aarkfeld
It seems to be a common consensus that value based pricing is better than hourly billing.<p>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.<p>However, at what point is someone able to offer value based pricing? For newer freelancers or business owners, is there a &quot;pay your dues&quot; period where hourly billing makes sense until you&#x27;re more established? Should someone get a really solid handle on their hourly rate before they start pushing into highly profitable pricing strategies?<p>I&#x27;d be curious to hear perspectives from newer freelancers being told they should perform value based pricing. I&#x27;d also be interested to hear about the path more experienced freelancers have taken from early freelancing days to very profitable pricing techniques today.
======
ChristopherM
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.

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

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

~~~
zerr
> 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!

------
psyklic
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?

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

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

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

~~~
galfarragem
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.

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

~~~
cpncrunch
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.

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

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

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

