
5 reasons why hourly rate is better than fixed price - iktorn
http://blog.netguru.co/post/55074277381/why-hourly-rate-is-better-than-fixed-price
======
marcomassaro
Good article but it fails to address two huge issues with hourly pricing and
why I don't price by the hour.

1) Something that use to take me 10 hours to design may now take me 2 hours.
Should I discount the knowledge and skill it took to learn that? I'd be
earning a fraction of what someone else gets because I'm more efficient.

Raise my hourly rate you may say? You can really only go so high with your
hourly rate until clients will look at you funny. $100, $125, $150, $200 -
anything above that as a freelancer and you'll have problems landing clients.

2) Hourly rates also limit how much you can bill - there are only so many
hours and days in the year. I prefer fixed pricing as well as calculating in
variables to increase the price. So if I can tell a client takes long to
respond or give feedback, I add on 10%. If there are 3 or 4 people who are
giving feedback, I add 5% - etc.

~~~
lifeisstillgood
This is exactly why you might want to consider moving to weekly billing. Bill
for a weeks work, as long as the deliverables come in does it matter if the
week was only a few hours long?

You can either charge a lot per week, or less per week _and still fit in more
clients_

However there is still a lot or marketing to do

~~~
marcomassaro
So are you essentially telling the client that you are billing them for the
week - which means you are dedicated to their project for the week?

~~~
lifeisstillgood
no, you are saying that next week I will work on the deliverables we agreed
for the week. And I will deliver them. And they will bring you this much
benefit.

If I need to go and hire two guys and work nights to do it, I lose. But I only
lose a limited amount.

SO, I guess I _really_ am saying work fixed bids of one week projects.

~~~
marcomassaro
So if you finish them in one day - you don't send them to the client until
Friday?

I imagine if you did them in a day or two the client would be asking why they
paid for a week of work and if they can use the rest of the time somewhere
else

~~~
lifeisstillgood
Why not keep them till the scheduled Friday meeting?

The client is expecting it Friday, probably does not have time to talk to you
on Tuesday afternoon.

Its not lying, its not cheating, its saying I will build X and doing it in a
professional manner.

~~~
porker
Are you sure?

> Bill for a weeks work, as long as the deliverables come in does it matter if
> the week was only a few hours long?

"Hello Mr Client, this job will take a week to do, so I need to bill you for a
week of my time". 4 hours + 1 meeting on Friday, job done.

That sounds like lying and cheating to me. Which is a nuisance, as I'd like to
do it.

~~~
MetaCosm
It is lying and cheating, and it is illegal.

Generally 'standard weeks' are done under the assumption that you will work at
least 40 hours on the project (often more, I average 44). The concept is that
the project is significantly more than 40 hours, and accounting for every
moment is overhead that doesn't serve anyone. Client doesn't care and it
simply wastes your time to do it.

~~~
bdunn
As he said, he's selling a fixed bid project that is scheduled for a week.

The client he's looking to work with is looking for results, not how long he
spends sitting in front of an IDE.

~~~
porker
Brennan, I respectfully disagree. He said:

"This is exactly why you might want to consider moving to weekly billing. Bill
for a weeks work, as long as the deliverables come in does it matter if the
week was only a few hours long?"

What you sond to be advocating is fixed-price bidding/value-added pricing; but
that's not the same as the OP.

If he'd said: "This is exactly why you might want to consider moving to
billing on value. Bill based on what it's worth to them, as long as the
deliverables come in does it matter if it only took a few hours?" I'd have had
no qualms.

~~~
lifeisstillgood
I reserve the right to mis-speak. Especially if I clarify in later posts ;-)

~~~
porker
Mis-speak accepted :)

~~~
lifeisstillgood
[https://www.youtube.com/watch?v=EkqrI3IibYI](https://www.youtube.com/watch?v=EkqrI3IibYI)

I took my inspiration from this man.

------
dclowd9901
And here's one reason that overrules all 5: because the customer doesn't like
surprise pricing.

Their business is knowing how much something is going to cost. This isn't
exclusive to the project I'm working on with them. This extends to every
aspect of running their business. Whenever I see a business owner angry about
a new government policy being considered that would impact their business,
they're rarely upset about the policy itself and more upset about the vagaries
that come with being affected by the enigmatic legislation process. Small
businesses and even medium sized businesses flourish under consistent
understanding of their costs.

Even if I'm not as big a shop or even as talented a shop as the next guy, I
know almost any company is going to go with me because I will give them a
number and I won't deviate from it unless they, themselves, have deviated so
far from the scope that I have to forewarn them that the project needs to be
re-estimated. At which point they understand because they're a business owner
too.

Moreover, it just _feels_ sheisty. It feels like a bait-and-switch. If I
severely underestimate my costs on a project, I shouldn't be passing that
mistake along to the customer. It's not their fault. It's mine. I'm the expert
here. I'm the professional in this field they hired me to be the professional
in. How can I go back to them and ask for more money because I didn't prove
myself to be professional? It's not their concern how I run my business, nor
should it be.

~~~
iktorn
Our "response" to this is radical transparency. Client should be able to track
the progress in almost realtime.

The problem is that usually the business is not sure what it wants then the
project starts - the scope is not well defined. And it's ok. This is something
that all stakeholders learn along the way.

~~~
dclowd9901
And my response to this is that if you don't have a scope clear enough to
accurately figure out your project's pricing, that's your fault. The second
part of this is a mutual understanding that scope is gospel. This means the
client has a clear understanding of the end product and what problem it's
going to solve, and you're going to have the same understanding. Changes to
the gospel mean changes to everything else.

Obviously running a business is part philosophy. If you don't mind a customer
looking over your shoulder throughout an entire project, second guessing your
time usage, then sure, I can see how an hourly situation might work. I despise
that, and so I've found fixed pricing to be my preferred approach (which has
the apparent added benefit of being very appealing to most clients).

~~~
porker
> And my response to this is that if you don't have a scope clear enough to
> accurately figure out your project's pricing, that's your fault.

How do you get around companies wanting a fixed price without knowing entirely
what they want? As a freelancer I can't spend 2-3 days of meetings and spec
writing only to lose the project because they preferred an agency/another
supplier.

If I had clients who would pay for a 'Consulting' phase of producing a spec
(which they could then send to other agencies/freelancers) then I could see
this working, but those are like unicorns.

~~~
snowwrestler
Adjust the way you think of the word "scope."

To people who build websites, scope means technical scope--the features,
functionality, design, backend etc. A precise technical scope makes it easy to
calculate a price.

But to people who buy websites, scope means financial scope--a "$100,000
project" vs. a "$20,000 project." They don't know precisely what they
want...because they don't know what is possible. That's why they are hiring
you!

So you learn as much as you can in the RFP process and propose your fixed
price based on that. Unless the client or RFP is a terrible lie, you should be
able to get it in the ballpark.

From there, closing the sale depends on your ability to convey that your
expertise will help the client get the best possible product for this "scope"
(i.e. price). If you want to cover a few more bases, you can provide some
optional levels of effort for the riskiest items, or "nice to haves."

------
tptacek
The problem with this post is the word "hourly"; the author means "time &
materials". It's fine to bill based on your time, but unless you're a
furniture mover, you shouldn't be doing it in hour increments.

This is a hobby horse of mine, so I'll spare you the retread:

[https://www.hnsearch.com/search#request/all&q=tptacek+hourly...](https://www.hnsearch.com/search#request/all&q=tptacek+hourly+day&sortby=points+desc&start=0)

~~~
iktorn
good point. Weekly & daily rates are probably better as few commenters
suggested.

------
mbesto
Down side to hourly rates:

1\. Clients hate them. Very rarely do you they understand the difference
between paying for your time and paying for the finish product they are asking
for (and it's correlation to your effort/time).

2\. I much prefer day rates over hourly rates. If something can be done in a
few hours, then it should be free.

3\. If you are a good developer and can develop quicker than most than doing a
fixed price has a huge upside to it.

4\. The number one reason for hours/days going longer than expected isn't
based on developer/designer competency, but rather project management and lack
of clear requirements (or changing requirements). Pinning commercials against
the root cause of most delays can cause really messy situations.

If you're working with startups specifically, I typically do the following:

1\. Give a rough estimation of what their project will cost.

2\. Tell them that with this estimation they get X number of
designer/developer days to build their project. They get to see an update of
the project every 1-2 weeks and can decide how they want to use their budget
accordingly.

TL;DR - I tell my clients that they are paying for my team's time and not for
a web project. Otherwise, I do a fixed price and massively buffer it.

~~~
iktorn
Very good points. One thing I don't really get though: "2\. [...] If something
can be done in a few hours, then it should be free."

Why so?

~~~
tptacek
Because a client who is reliably paying you for days of work is worth a free
hour or two now and then, and because the precedent that you will work for
hours instead of days will come around to bite you in the ass later on.

~~~
piotr_b
This approach is great - giving small things for free, but isn't working for
every clients. It's horrible for you when your customer is't paying a lot
(small projects, low prices etc.). They are overdemanding, don't like your
work, put a lot of changes and thinking that you should't do it for free.

~~~
noahc
The idea behind this is that you bill in weeks and deliver real business value
so you don't have clients doing 'small projects' or low prices.

The approach is self selecting and self correcting.

~~~
mbesto
Exactly. No _real_ projects are small. Anything less (IMO) is a favor and
should be considered a marketing/sales event.

------
rfugger
I agree with everything in the article. However, my experience as a coder has
been more positive on fixed-price contracts than on hourly contracts. On
hourly contracts, which I started with and have done more of, I tend to feel
like I'm bleeding the client with every hour I spend, so I rush. The quality
goes down and my stress levels go up. I don't spend time figuring out the best
reasonable way to structure my code, and I don't play with interesting corner
cases for my own amusement. With fixed-price contracts, I know the client
isn't paying for my desire to write the nicest code I can come up with on that
day, nor for flights of fancy onto tangents that may be more about my own
enlightenment than about delivering value for them.

I realize that I should be able to fix my issues with hourly billing by
separating my work into "value for client" and "my own enlightenment" for
timekeeping purposes and only billing for the former. In reality though, the
effort required to be constantly making this kind of judgement about
everything I'm thinking about seriously disrupts my flow, and seems to be just
as much effort as estimating a project ahead of time.

When I have a good relationship with a client, I can try to get the best of
both worlds by giving them fixed-price-style estimates, and then asking for
more money if the project ends up being more effort than I thought.

------
TamDenholm
As a counter point, i would argue that if you're billing on an hourly rate,
you're limiting your earning potential as there's only so many hours in the
day and a client will compare you to others in your industry if you charge by
the hour. I'll continue to beat the drum of value based pricing as patio11
does too. Deliver a project that brings the client £10,000 worth of value and
charge £1,000 for it and they wont give a shit if it takes you 1 hour or 1
week.

~~~
filozynka
When you are developing the project further how would you like to value adding
new functionalities to the project using the value based pricing model?

~~~
lifeisstillgood
How much value does the new feature bring to the client ?

Easy one: increase their conversion rate for google searches of keyword "blue
widget" (ie google -> landing page -> credit card charged) by 5%. YOu just
made them 5% of their annual turnover. Charge them a lot

Harder one: (Anything away from sales is always going to be harder to measure)
Implement a simple custoemr support online chat featuire (you know the kind) -
allows their support to deal with >1 person at a time, and reduces the
"waiting" queue on the phone system to zero. Value? Dunno. Feel around by
talking to the VP of customer service or make a judgement call like "not
having to hire another five custoemr service people"

~~~
iktorn
This makes sense when you have a well established business that's tweaking
it's processes. Impossible when building an MVP and/or experimenting.

------
obviouslygreen
At least in the web world (which is the only one I have a whole lot of
experience working in), there seems to be an interesting progression that
developers go through if/when they leave the corporate world and try things on
their own. Recognizing that fixed price development is very often a nasty trap
is where many developers and organizations start to actually wonder about how
their business model could change.

1\. Fixed bid projects. Attempting to offer custom development as a package
deal seems like a great way to undercut the competition; in reality it's
anything but, and (among other things, including those mentioned in the
article) reduces the perceived value of your work, which hurts in the long
run.

2\. Hourly consulting. Better, and works well for quite a while, allowing you
more flexibility in your engagements and with your rate. This might even be a
good long-term strategy for individuals; however, it requires very good
planning and workload management, which are more difficult than many people
think. It also does limit your earning potential, but this is much more of a
factor if you expand into a consultancy, in which case your expenses will drop
your margin.

3\. Product/subscription service development. Often the subject of HN
discussion (and rightly so), the prospect of recurring revenue is obviously a
powerful one. However, even more than when selling development services, this
requires a solid understanding of your target audience(s) _and the ability to
market to them effectively_ , in addition to understanding end-user customer
support.

Where do we go from there? I personally have no clue; I've been slowly
climbing this ladder myself.

~~~
bdunn
This is pretty much the exact path I took. It becomes _really_ interesting
when it finally dawns on you that there's very little difference between
building and selling a 3 to 4 figure / mo SaaS and offering a value-oriented
consulting retainer to a few clients. (See
[http://draft.nu/revise/](http://draft.nu/revise/))

While retainers aren't exactly turnkey (they'll generally require human effort
per account per month), the same positioning, marketing, and pricing rules
you'll encounter selling software apply.

------
tick113
My experience has been the opposite, and I think fixed price benefits both
sides. Of course, it depends on the circumstance. Fixed price and hourly each
have their place. I will say that a fixed price contracts can be tricky.

My primary point of reference is a medium sized fixed price project that was
delivered early, and the customer loved the solution and came back for more
business. I've also worked countless hourly contracts from both the customer
and consultancy side.

1\. Assuming a fixed price project requires a big up front spec is wrong.
Follow lean/agile principles, iterate and refine. The contract should specify
high level basic functionality and the problem being solved.

2\. Hard to quantify, but hourly is plenty risky having worked both sides of
the relationship. I've seen hours and hours burned building things that are
not at all necessary. A fixed price helps everyone focus on building precisely
what is needed.

3\. Hourly rates put customer and consultant's priorities in line? From a
short term view, if I'm paid hourly I'm going to milk the deal. If the
consultancy is taking a long term view, everyones priorities are in line.
Consultancy delivers fantastic product on time, it's a win by bringing the
customer back, and word of mouth.

4\. Again, it's how you structure the contract. If a giant spec is written up
as part of a contract, you're doomed before you begin.

5\. I'd argue the fixed price is a risk balance between the customer and
consultancy. If the consultants finish early, they're rewarded. If they are
late, they are penalized. This is in contrast to hourly, where it's win-win
for the consultant.

------
jonathanjaeger
If you don't know the contractor well, you don't know how hours worked
translates into productivity. The programmer could be a 10x programmer or
string you along saying things took longer than expected and suddenly your
budget is bloated. I like a happy medium of fixed price with variable scope or
a budget range with variable scope and finer details discussed in the
contract.

------
rmrfrmrf
The model that works best for me is a fixed price based on initial scope with
additional fixed or hourly billing for 1) tech support and 2) additions to
scope or changes that occur after sign-offs.

Hourly billing is great until it comes time for final payment, which is when
the client comes back and says "ok, why did x take you 3.267 hours and y took
you 4.535 hours. Can we shave off some of this and that, oh, and this, too?"
"Ok, this total is a little more workable, but I'll tell you right now that
our billing department won't pay a dime more than $z, so you better adjust
your rate or take off some more time."

Then you end up getting screwed out of money. This happens even when you do an
estimated cost and have clients pay you 50% of the estimate up front. Fixed
billing sets the expectations of how much work will be done and what the
client should expect ahead of time, so it's a much easier pill for them to
swallow when it comes time to pay up.

~~~
lifeisstillgood
1\. Weekly sprints, weekly billing. No cash delivered after 14 days, down
tools and call them to say why.

------
snowwrestler
There's a big misunderstanding here, which is that fixed price implies a
waterfall methodology. This is not true. All a fixed price does is cap the
financial scope of the project.

But the tradeoff is that you need to vary the technical scope. For this
reason, agile methodology is actually the best way to do a fixed-price
contract. Every sprint is an opportunity to reconsider the technical scope to
stay within schedule and budget.

This does reduce risk for the client. Most companies have much more serious
limitations on budget and schedule, than they do on their imagination for what
an ideal site should do.

And even if the client does decide they want to spend more money to get more
functionality, they can just execute a change request or amendment--a process
that is much more controlled and transparent (from the client perspective)
than just working a few more hours.

------
fvox13
Any project has a defined scope and set of requirements. If you start the
project before these are defined, you're dumb, because you have no idea what
you're working on.

I always draft a requirements document for my freelance customers, and spell
out exactly what I will do for exactly how much money, by a deadline. This
document also says in no uncertain terms, that any deviations will result in a
new set of requirements, and thus, a new price.

Hourly rates punish you getting better (why shouldn't I charge the same I did
last month for something, despite having found a way to do it twice as fast?)
and they open you up for all kinds of "why is this taking you so long" or "I'm
paying you X per hour! That's more than I pay my shrink!" comments.

~~~
iktorn
One of the points in the article is that it's impossible (and impractical) to
scope out everything before you start.

~~~
fvox13
I'll admit there's a certain "fudge factor" but the more experience you get
with requirements gathering, the less of an issue it is. Ultimately, this is
the difference between a "Developer" and an "Engineer".

~~~
iktorn
It's not about the lack of skill on the supplier side. It's usually the client
that is not sure how exactly the project should look like. And that's ok - he
does not need to scope out every detail - it can be worked out along the way.

------
j45
15 years of consulting left me dreading reading this article a little.

There is no set formula that I've found. I'm open to finding it. Until then
better I get at business, the better I get at all these different ways of
"earning" formulas.

You exist to help the customer get the result they want, who usually don't
know what they want.

If you don't know what you're doing, or worse, don't know how to help the
customer find what they need, the meter can be run up hourly, or lose your
shirt fixed price. Both are poor delivery of value for the customer in
retaining a sustainable, no-surprise-giving, stable business partner.

The second we are in consulting, we're in business, not an hourly employee.
It's a comfort net to say otherwise of not having to learn business skills.

Still, businesses are great customers. They're a lot more logical than
consumers. They especially listen to anything that adds value to their
business.

What's this hokey "add value" thing?

One definition is:

Saving or making your customer money, or time.

Time? Yes. The cost of their employees is the #1 cost in their business.

So, if person x spends 5 hours a week generating a spreadsheet at $15/hour,
and there's 50 working weeks a year, this spreadsheet cost them $3750 in 1
year.

That's just $15/hr!

If I spent 10 years learning to do something in 2 hours, should I charge the
customer the 2 hours, for the 10 years it took to learn, or say.

"This is costing you $4000 a year, I can get rid of it for $1000 permanently".

If it's a large company, you can even look at the savings over 2 or 3 years.

See? You're saving your customer money. Get the sign-offs on any solution from
the ground up to the signing authority and put good decisions in front of
them.

One reality is you end up doing a bit of both fixed and hourly. The better you
understand your clients business, data and processes, the more fixed you can
go.

With new clients, for example, I do small fixed price projects to minimize
risk for the client and to build small momentum building wins.

When customers see the value themselves, instead of trying to trick them into
liking you, what they pay me becomes far less of an issue. Some still prefer
hourly so I just quote the total number and let them imagine what the hourly
rate is. Some still want to know the hourly rate and I let them know we work
extremely fast and have 15 years of experience each.

Regardless of hourly or fixed, if at the end of it they look at it and say
"yes, they built what I asked but it wasn't what I wanted", customers will
start doubting good decisions in the future because your inability to guide
the canoe better. This is a bigger threat to your business than anything,
especially if you want to stay in consulting.

Help your customers spend their money with the care as if it was your own, and
you'll find yourself with as many long term consulting customers over the
years that you can handle.

~~~
iktorn
Mentioned it before in another thread here: This makes sense when you have a
well established business that's tweaking it's processes. Impossible when
building an MVP and/or experimenting with a new product/service.

~~~
j45
Disagree. Absolutely possible.

I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a
lean practitioner for over 10 years starting in manufacturing.

You want to help your MVP's become long term customers by helping them grow
and make money. If they don't get this, it's a real risk to their business,
let alone your relationship with them.

For MVP's: You have to invest in understanding your tools and how long it will
take to identify and build only the features that customers can't live
without.

My original consulting business is for established businesses, but they were
all smaller 4-7 years ago.

~~~
iktorn
"build only the features that customers can't live without" \- who makes this
call? What if you disagree on this? What if the customer learns something new
after 2 weeks and needs to change the scope?

~~~
j45
Who makes the call?

If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no
one is getting out of the building and talking to customers/users before
designing or writing a line of code?

Completing the problem solution fit, product market fit, and engaging in
customer development prior to writing a line of code has to happen if we are
wanting to be honest when using a term like MVP.

If you feel this is a binary issue: ultimately the person signing the cheques
make the call, and you have a choice on whether to accept said cheque for
managing said potential headache.

The grey area in between:

If the customer wants to do whatever they do and call it an MVP by sprinkling
the lean dust on it to justify it, you have to recognize it for what it is and
either adjust your approach, or decide if that kind of work is something you
can live with. No process can correct development pagentry, management/design
by committee, and failing to get out of the building.

Building an MVP requires getting through the build - measure - learn loop as
quickly as possible.

Interrupting you mid-cycle if it's that ground breaking (customers are saying
I'm trying to find a way to give you money) requires answering "Did we really
understand anything before hallucinating an MVP ourselves"?

It leaves a few options:

\- Change the scope

\- Change the deadline

\- Change the budget

\- Trade features -- something that was important can no longer be important
as a result of what was traded.

Avoiding this is the business skills development we all constantly need that I
mention to in my initial post.

For me, I try to make sure I understand, and the customer understands why
we're doing the things we want first and hopefully minimize the above.

I don't rush customers into building something, but rather rush into
understanding what our experiment is, and why we're testing those things. It
helps create a checklist to test our assumptions/discoveries against when the
next great insight comes in.

~~~
kubaf
Dont you think that what you are describing sounds like a huge overhead.
Rather then tweaking the product you have to "trade features" with customer.

It's also something that is very difficult to scale. It's hard to expect that
every person who is good on the job is also good in negotiating with
customers.

~~~
j45
Project management is a real part of software development.

I make no statements about whether the developer should do the project
management -- only when a good process happens, results are good.

The developers who can manage a process that they're a part of is a skill that
we should all aspire to, though, because people aren't hiring us for just our
technical prowess, but rather, our ability to interface those skills to
finding and completing business goals.

I do agree that avoiding the scope changes while doing an iteration is
essential, and can be often lessened or deferred until the next .. sprint.

------
MattBearman
I think a lot of freelancers (myself included) go through the following
process:

1 - Start out with fixed price estimates based on time (I think this will take
10 hours, so I estimate £1000)

2 - Develop good relationships with clients and start just charging hourly for
work done (This took 12 hours, so here's a bill for £1200)

3 - Take patio11 (et al)'s advice and start charging based on value (this 10
hour job will increase your profits by £100,000 so I'll charge you £10,000)

In short, hourly IS better than fixed price time based estimates, but fixed
price value based estimates are even better.

~~~
iktorn
The problem with no 3 is that not every job can be measured in $$$. Especially
when you are building an MVP and/or experimenting with features.

I think your approach is definitely valid for "traditional consulting" but a
bit less so for more plain webdev work.

~~~
j45
I disagree. Every job can be measured in terms of value. Especially mutually
agreeable value. These though, are business skills and not tech skills.

~~~
iktorn
But than you are introducing overhead of deciding this. For obvious reasons
this is something that needs to be negotiated with a client and documented.

------
wikwocket
There are a lot of counterpoints here saying that fixed-price is better for us
as consultants.

But this article is saying hourly-billing is better for the _CLIENT_.

I think this is an important distinction. Obviously there are advantages for
us to doing value-based fixed-price billing, but that says nothing about the
merits to our clients. If you don't do hourly billing, you should be aware of
these potential gotchas, and be aware that some clients won't work with you.

------
lnanek2
If you are ten times faster than other developers, fixed price per milestone
lets you charge ten times as much. If I'm writing a custom map screen for the
first time it is going to take me all day. If I'm writing it the 12th time it
is more like an hour. I can charge a lot more for a custom map screen than an
hour, however, even an hour at the highest hourly rate the market would bear.

------
marknutter
5 reasons? Why not 4, or even 6?

