
Why I bill hourly - cwan
http://orestis.gr/blog/2010/11/06/why-i-bill-hourly/
======
tptacek
Why you should _never_ quote prices in hours: because it provides prospects
with a frame of reference for price negotiation in which (a) you always sound
very expensive, and (b) price movements that seem reasonable to the prospect
can end up being very painful for you.

If you're going to end up haggling over your price, far better for you to be
doing it over numbers like $15,250 which are tied to the _specific project_
than over numbers like $125/hour which are affixed to you for the rest of your
relationship with the client. You should never, ever be budging on your rate
anyways. Give an inch on your rate and you will never get it back; companies
hire whole departments to ensure that rate concessions, once taken, are never
surrendered. Negotiate over _project scope_ , not rate.

The question of whether you should go fixed price or time-and-materials is a
reasonable one (and it's a negotiating point), but if you're going to bid
time-and-materials, price in billable weeks, and estimate the number of weeks
up front. Save the details about billable phone call minutes (and,
_seriously?_ ) for your S.O.W.

~~~
abalashov
You are absolutely correct about this. People at all ends of the market
spectrum have a very strange psychology about hourly rates; for some reason,
if you hand them a quote that foresees 10 hours at 175/hr and is expressed
that way, that strikes them as an eye-poppingly high number. They start
comparing your services to the prices to those of high-end attorneys and
accountants and so on, exercising prejudices about how programmers should be
paid less than that because they are more like plumbers or electricians than
litigators, and general wheel-dealing, bargaining, nickel-and-diming, etc.

In addition to that, the large-scale body shops serving the enterprise market,
the ones we all know about that darken the skies with individually-billed
people and squeeze as many hours as they can without the impression of
efficiency, have left such a bad taste in the mouths of many people who no
longer work in enterprise that you invariably have to fight against it every
time you sell your services.

But if you hand them a quote for 1750, _even with the 10 hour estimate baked
in for their mental math to operate on_ (but especially if it's not, and once
you quote an aggregate price itemising the time apart from overall delivery
time frames for the most part ceases to be necessary), some switch flips in
their brain. I cannot say what it is, or why -- it just does. Somehow, the
combination of shifting the risk for overages onto you and the more opaque
number causes them to start evaluating the overall sum more in terms of
business value and less in terms of whether anyone should be making "that kind
of money." It's really odd, but it has been overwhelmingly the norm in my line
of consulting trade.

~~~
hasenj
If you quote the rate, and the project takes more time, it becomes their
problem; they have to pay more now.

If you quote the overall price, and the project takes more time, it's not much
of a problem for them; they won't end up paying any more than they would have
otherwise.

~~~
tptacek
Stop! There is no reason why you have to assume the project risk just because
you chose a more sensible metric to quote the price with.

Provide a top-line project cost number _as an estimate_ , and then add an
"additional time can be added to this project as needed at a rate of $XXX per
day" clause.

The question of who assumes project risk is orthogonal to the question of how
you choose to break out project cost.

~~~
hasenj
I'd rather that part of my service is to give my client a sort of guarantee on
the cost, given the requirements[1]. How many hours I work? What technologies
I use? What OS do I work on? What's my text editor? What version control
system do I use? These are things they shouldn't have to concern themselves
with -- I'm a black box.

Do you ask Apple how much it cost them to make that iPhone? No!

[1] If the requirements change, then of course, my price will change (most
likely increase).

------
pan69
I tend to bill on a daily basis. I will present my clients with my hourly rate
and then explain to them that I bill per day instead. My daily rate is
slightly slower than 8 times my hourly rate. The reason I do this is to
prevent nitpicking on time sheets etc and to be accountable for every single
hour of the day. The last thing I want to do is have a clock sitting next to
me measuring my every single move. Some days I do some overtime (1 maybe to 2
hours max) and other days I find myself working slightly less. In the end it
all works out fine. The estimates that I give my clients are based on days,
not hours. If they want me to do a 4 hour job, cool, I still charge them for
the entire day. Most clients are cool with that. Since most projects I do tend
to have time-frames that go into weeks it's much easier that way for everyone
involved.

~~~
tome
Do you force yourself to work on only one customer's project on any given day?

~~~
pan69
No I don't and it depends whether I work on-site or from my own home office.
To work as a contractor has both benefits and downsides, which are typically
the reverse of being full-time employed. My hourly (daily) rates are based on
the fact that I might not be able to fill 40 hours of work week after week.
So, in a sense, my clients also sort of pay me for the time I'm not working.
That's why my rates are set to a certain level, and it's also the reason
contractors are more expensive than full-time employees. If I happen to be
working from home and I do work for 2 clients and both jobs take me 4 hours,
than in that single day I earn twice as much. However, the next two days I
might not be able to bill anything. Pros and cons of contracting I guess.

~~~
jimbokun
Do you make this clear to your clients? If I was told I was being billed for
"one day" of your time, I would expect that you were spending about 8 hours
working on my task. To find out otherwise, I would feel that I had been lied
to.

~~~
pan69
Yes. I make this perfectly clear to my clients. If they give me 4 hours worth
of work I still charge them for 1 entire day. And to be quite frankly, what I
do with those other 4 hours is none of their business.

------
bambax
I sometimes would like to be able to bill hourly, but find it impossible:

1) When I'm thinking about the project in the shower (where all the real
thinking is being done) shouldn't the meter run? Apparently from the original
post, the only billable time is the _typing_ time, which is a little bit
funny.

2) How do you know if you're fast or slow? Are you even consistent? Sometimes
a stupid feature takes me half a day; sometimes something really complicated
snaps together in an instant.

3) Even more so, _the client has no clue_ of what time it takes to do
something (and how could he, given that I haven't got many clues either,
beforehand). If I tell him that it took me 3 hours to do X and 5 minutes to do
Y he will be shocked! He will think I'm crazy, or bullshitting him, or that
I'm trying to convey some other message that he'll spend the next week trying
to decode.

4) What about warm-up time? When I get back to a project I left a week ago, it
takes about an hour to get up to speed; how should this hour be billed?

Besides, every theory of pricing tells us that price should NEVER be based on
costs. Price should be based on value because that's what it is: price ==
value. The problem of course is that the client won't tell you what the value
is.

What I end up doing is:

\- if I can get an idea of the client's budget, and I find this budget
acceptable, then that's my price

\- if not, my personal rule of thumb is (maybe counter-intuitively) to bid low
on things that are new for me (and interesting), because I really want to
learn the skills and get the reference on my portfolio; and to bid relatively
high on things I know well, because I don't really care to get the project or
not, and if I do get it I expect it to contribute financially to all the other
stuff.

(So if you want to hire me cheap, make me do something I've never done).

Also, it's been my experience that clients care about the price before the
project begins, but never after.

~~~
tptacek
If you're finding yourself worried about being able to bill for phone calls,
or for shower thinking, or ramp-up, your rates are too low. Stop trying to put
price tags on tiny scraps of your time, and instead put an appropriate price
on the _value_ you're providing to clients.

~~~
bambax
> put an appropriate price on the _value_ you're providing to clients

My point exactly...

Actually, my whole point was that I try to bill:

(value to client) div (my willingness to do this particular project)

------
mattwdelong
tptacek hit it dead on. Don't bill hourly; bid on a project basis. Why? First
of all, you can end up doing work for a client and you know how you can save
them $2,000/month by fixing something they can't. It only takes you five hours
to complete the project, so what, you bill them 5 * hourly rate? You just
saved him $24,000 year. That`s worth much more to him than an hourly rate.
Know what you want per hour, ALWAYS get that, but quote what you're worth to
your client and nothing less.

Secondly, tptacek is right again. Once you bid $125/hour, you're stuck at
$125/hr. Even if you save your client that $2,000 month for 5 hours work,
they`ll expect to pay you $625 and nothing more.

Be warned, this post is spot on if you always want to earn the same amount of
money but you will never grow a company with this billing method.

~~~
davidw
> Be warned, this post is spot on if you always want to earn the same amount
> of money but you will never grow a company with this billing method.

OTOH, if you want to do fixed bids, you better have a really good idea of
exactly how much time it's going to take you. This means that you should
concentrate on doing only things you've already done, or that are very similar
to them. Otherwise you'll run into something you didn't even know you didn't
know and blow your estimate and eat the losses yourself.

~~~
alnayyir
There's a trade-off to be made here and it can be compensated for by knowing
really good people.

------
geekdesigngirl
I have to agree with a lot of the posters here that fixed bids are better than
hourly. I've been doing the freelance thing for a while, as well as working
for another company, and have a very good understanding at how long it takes
me to complete task X.

When looking at a new project, I can usually estimate the time it will take me
to within a few hours and then I always add an additional 25%. I don't ever
bill a client for phone calls or emails and even when the project is completed
will answer emails/phone calls from them to assist. Yes, my prices are a bit
higher than average but my clients don't mind paying it and don't mind passing
my name along.

When dealing with a new project that I haven't a clue as to how long it will
take me, I give an estimate about how many hours I believe it will take me
and, if it gets close to that, the client is immediately told and we decided
together how to move forward.

My contracts are also pretty detailed. I learned early on that specs that
aren't spelled out in a contract have a way of coming back to bite you.

------
ora600
I find that billing hourly can make for a more pleasant relationship with the
customer. Provided that you give good justifications for the hours you bill.

On fixed price contracts there is lots of haggling over the exact scope,
requirements, changes and meaning of words in the contract.

Hourly billing lets me smile and say "sure thing" to more requests, something
that I actually prefer doing.

------
nfriedly
Here's a faster loading coral cache link:
[http://orestis.gr.nyud.net/blog/2010/11/06/why-i-bill-
hourly...](http://orestis.gr.nyud.net/blog/2010/11/06/why-i-bill-hourly/)

(The site took > 60 seconds when I first tried to load it.)

------
juddlyon
Fixed bid gives you a greater incentive to be efficient in my experience. If
you're significantly quicker than your peers (e.g., have your own processes,
frameworks, macros, etc.) then you can have large margins and happy clients if
you can estimate decently. Another reason: you only have so many billable
hours.

------
Tichy
One reason why I think hourly works better than fixed price: might help
getting priorities right. For example, suppose the budget is 20000$, and you
have 2000$ left to spend on the almost finished software. With hourly, the
money could be spent on useful enhancements, or on the most useful features
still missing. With fixed price, you probably agreed up front on some stupid
things like "all source code has to be documented", so you probably spend the
remaining hours on writing crappy documentation everybody will hate to read
anyway. Since you agreed on features x,y and z up front, you might end up
doing a hush job on features x, y and z, rather than doing a good job on x and
negotiating that y, z will better be scoped.

------
gte910h
I find iterative fixed fee kinder to people hiring out their first few times.
It gives them strictures on what they can do so they don't shoot themselves in
the metaphorical foot.

However, hourly definitely has it's place as well. I find offering both a good
compromise.

------
rapind
I agree whole-heartedly this is a great way to work if you're client is cool
with it. In my experience that's a big if though.

If you can always afford to walk away then this could actually work.

I always give my client's the option of fixed or hourly and really emphasize
the benefits of hourly. However I've only been taken up on the hourly offer a
few times with recurring clients.

I think it's a great thing to strive for but my advice to freelancer's
starting out is not to flat out refuse fixed quote unless you can afford to.
Fixed, while not quite as accurate, is still workable once you get a feel for
defining requirements on smaller projects. And any larger project can be
broken down, so long as you're getting paid for the spec.

Whatever you do don't spend a riculous amount of time specing out a large
project without being compensated. I've gotten so many RFPs that are obviously
the product of spec work and I'm positive most were unpaid. In fact I
guarantee there are forums dedicated to tactics and advice for getting spec
work done for free.

~~~
warren_s
I know it sounds trite, but if you can't afford to walk away from a project,
you probably shouldn't be contracting to begin with.

I say this from hard experience, the jobs I've taken against my better
instincts are the ones that have bitten me badly.

Another thing that's important is to know WHO you are pitching to. I charge
predominantly T&M, and my ideal clients are existing dev teams that are
looking for an extra pair of hands for a particular project. Matching your
billing model with the kind of clients you want to work for greatly increases
your chances for success.

~~~
rapind
I may not have been clear enough. When I say _if you can always afford to walk
away_ it's meant within the context of the post. Meaning that if you can
_always_ afford to walk away from clients who are only interested in fixed
quotes, not just one job. Which in my experience anyways has been about 90% of
the time (of actual contracts, not just leads). I can't afford to turn down
90% of my work... yet.

After reading some of the other comments I've decided to stop even giving them
the option of an hourly rate. Works been very steady (too busy ATM) and like I
said there's been very little uptake on the hourly option anyways.

I agree that it definitely makes sense to change your model to reflect the
type of client.

------
hippich
I am doing hourly work. But this is for clients I have high level of trust.
They believe me.

Most other clients are more concerned to know fixed amount of time and if
project took less - they want to get it back, although I negotiate that
successfully so far =)

The worst case is - estimate in hours. =)

------
three14
We would love to bill hourly. We tend to work for large companies, and they
need to figure out how much to budget, so we then end up saying, "this will
take between 10 and 12 hours," and then being forced to swallow the costs when
it takes us 14. And of course, if it takes 8, they win. If anyone has
suggestions other than "just tell them it will take what it takes," we'd
really appreciate hearing them.

Edit: Usually, just stopping when the hours run out isn't a good choice
either, because most of the projects we have won't provide a partial solution.
It's all or nothing. Example: converting data between two formats. We discover
a quality issue when we've run out of time, so the converted data is unusable.

~~~
warren_s
How are you "forced" to swallow costs, unless you're contractually bound to
deliver in 10-12 hours? If your client wants an estimate, by all means, give
them a non-binding estimate. If you find yourself over-running your estimates,
then it's either your fault or the client's fault - why should you have to
bear the cost in both cases?

~~~
three14
We do have a "non-binding" estimate, but they can't turn the wheels in their
large organization to get payment for more than the high end of our non-
binding estimate. And no one takes us seriously if we say "probably 10 to 12
hours, but this kind of work occasionally has problems that will balloon the
costs to 20 hours."

~~~
warren_s
Why would you not just say 10-20 hours then? If you _know_ that you're going
to wear any overrun costs, you owe it to yourself to give the estimate based
on the worst case, NOT the average case.

Edit: If you think that 20 is a real outlier, and 12 is your average case, use
something like the PERT formula: ( [Optimistic] + [4* Realistic] +
[Pessimistic] ) / 6

If O=10, R=12 and P=20, that would give you an estimate of 13 hours.

------
kristiandupont
For larger projects and clients, I recommend you look into agile contracts:
[http://www.bestbrains.dk/Blog/2009/06/03/CollaborativeAgileC...](http://www.bestbrains.dk/Blog/2009/06/03/CollaborativeAgileContracts.aspx)

------
mattiask
Well, there's two sides to that coin. By having the client pay hourly you put
the "risk" of the project on his shoulders, but you also limit yourself to
earning _only_ a hourly rate. Why is that bad? An experienced programmer might
accomplish a task/project quickly due to having done similar projects and have
an arsenal of code/examples/tools at his disposal. An experienced programmer
might be able to get 20%-30% markup on his hourly fee but he might finish the
project five times as fast as another less experienced programmer might.

You won't be able to leverage your gray hairs and the time they save you as
efficiently with an hourly fee.

If the project is well-defined you might be tempted to accept a fixed price
and crank it out quickly which will net you more money per hour. I'd advice
holding of atleast a week even if you do it in a day or two or the customer
will start questioning your price ;)

If the project/customer is fast and loose with the spec and functionality (as
most projects are) you're in dangerous terroritory where constant changes
keeps eating away at your time.

If you can get a high hourly fee and the project is fuzzy, go for it, meetings
and stuff like that will earn you a bunch anyways.

Another strategy is to split the project into discrete parts and charge a
fixed price for each (negotiating each one), that way it's easier to define
the scope of the project and it eliminates risk both ways. It also gives you
and the customer have a chance to get to know each other before committing to
the project and helps avoid being in the clutches of a psychopath customer.

------
quizbiz
For those that bill hourly, do you go off of a monthly retainer and sort of
use that as a budget for hours? If I am starting to outsource (not off shore,
just with partners, specific tasks), I'm just struggling about how to approach
that from a billing perspective. I would like to make a small margin.

~~~
mark_l_watson
For active projects/customers, I bill 1 hour minimum per week. I also bill a
minimum of 15 minutes a day if I do any work at all. This is fair since there
is some "context switch" cost for me, even when I just answer an email or take
a short call.

------
loewenskind
What about using Scrum and billing by the story point?

------
thibaut_barrere
I find that using acunote to lay down the estimate (then remaining work with
burndown) and freckle to track the hours and remaining budget works nicely.

~~~
joshfraser
I've done both hourly and fixed price contract work and found that fixed price
works better for me.

In an industry that is known for software taking 10 times longer than
estimated, clients have good reason to try and protect themselves with upfront
pricing. The fixed pricing forces me to become better at planning ahead and
giving good estimates. The trick is to document every detail of what they get
for $XX and agree that any changes to that will cost extra.

Software development depends largely on inspiration. Sometimes I'll crank out
a weeks worth of code in one day. Others I'll stare at a screen all day and
produce very little. In the end it all averages out, but I do feel bad billing
for the unproductive hours even if I know it's fair in the end.

