
Hourly Billing is Nuts - calineczka
http://blog.arkency.com/2016/10/hourly-billing-is-nuts/
======
GavinB
The moment you agreed to a fixed bid, the incentives between client and
customer are directly in conflict. Any additional thing that the client wants
has to be renegotiated.

If your development is in any way exploratory or creative, my experience is
that hourly billing frees everyone up to focus on making the best product. It
also lets the developers and designers be creative and figure out the best way
to build something, rather than having to build exactly what was drawn up by
some idiot (usually me!) who isn't actually the one doing the work.

Yes, you have to trust that the hourly worker isn't wasting your time. Yes,
they may have to raise their rates as they get more experienced and more busy.

~~~
pmoriarty
A fixed price for the whole project is not the only alternative to hourly
billing. You can also bill by day, week, month, or some other interval.

~~~
kxyvr
As opaque and oppressive as it sometimes can be, I highly recommend that
people at least understand the kinds of contracts listed in the FAR (Federal
Acquisition Regulation):

[https://www.acquisition.gov/?q=browse/far/16](https://www.acquisition.gov/?q=browse/far/16)

These contract structures apply to more than just federal contracts and have
helped me dramatically understanding different contract structures. Anyway,
long story short, each contract type has a different amount of risk and reward
and it's extremely important that both parties understand and choose the
contract type most appropriate for the work. Even fixed priced contracts have
a lot of variation:

[http://www.acq.osd.mil/dpap/ccap/cc/jcchb/Files/Topical/Cont...](http://www.acq.osd.mil/dpap/ccap/cc/jcchb/Files/Topical/Contract_Type_Comparison_Table/resources/contract_type_table.docx)

Anyway, it does take time to learn this language, but the there are many local
chapters of the National Contract Management Association
([http://www.ncmargc.org/](http://www.ncmargc.org/)) that run seminars and
study groups that can help understand this kind of language.

------
dworin
>>> the change is mostly about moving this risk (and potential reward related
to it).

This is exactly right! And the theory behind it is actually one of the papers
behind this year's economics Nobel Prize.

Different billing models aren't about paying for outcomes - they're about how
to both incentivize and compensate when 1) there is uncertainty about the
effort and ability required and 2) there is uncertainty about the degree to
which effort and ability will lead to outcomes and 3) outcomes are costly or
difficult to measure.

Different ways of billing are really about who takes on the risk (and gets
both the upside or the downside), as well as how to align incentives between
the service provider and the recipient. Oftentimes risk-sharing and incentive-
alignment are in conflict with each other, which is why this isn't an easy
topic.

------
dagw
I've basically only done fixed bid work for the past two years and when all is
tallied up the end result is an hourly rate significantly higher than I've
ever gotten doing hourly billing. The 'trick' as it where is to focus on
offering set products where the scope is easy to clearly define (You will
deliver X, I will perform Y and deliver results in form of Z), and that you've
done enough times to have a streamlined pipeline to manage. The client
shouldn't care if it takes me 10 hours or 100 hours to do something, all they
should care about is if the work is worth $10k or not.

------
tboyd47
The author is right that increasing the time value of one's work is an uphill
battle. I entered the workforce right at the beginning of the 2008 recession.
It took me 6 years of bouncing from job to job, working late nights at times,
talking to armies of recruiters, negotiating small raises at each job, to
finally earn a salary that would be considered average in our industry.

I am very, very careful now to guard my rate as a software developer. As crazy
as it sounds, I would rather work for free than work for a low rate.

~~~
dancek
> As crazy as it sounds, I would rather work for free than work for a low
> rate.

That's not crazy at all. Most of us help other people in many ways, and that's
ok. I'll be glad to spend 6 hours to help a friend move house, but I'd
certainly not do it for $20. Similarly, I develop FLOSS for fun, but would not
do it for $10/hour.

------
heisenbit
"And that’s only a fraction of my thoughts after reading Hourly Billing Is
Nuts."...

and only a fraction of the thought that needs to go into a balanced risk-
reward consideration.

\- Risk of cost overrun.

\- Risk of completion.

\- Risk of delivering a result vs. a service.

\- Risk of claims being enforced against you or your legal shell. Money at
risk.

\- Risk of customer willing or able to pay.

\- Ability to enforce contract terms from your side.

\- Risk of badly managed change.

...

There are clearly opportunities out there. Also some carefully considered
hybrid models can work. But it takes more than a fraction of thoughts.

------
mgkimsal
> Of course, you might argue that when you get 2X better, you can charge 2X
> more per hour. I agree, assuming you know how to convince your (new or
> existing customers) that you are now two times better. This can be hard.

Based on the example scenario given, it shouldn't be _that_ hard. You just
give a lower time estimate.

For _small_ stuff, the hours may be negligible. For larger stuff, they may not
believe you. This is where marketing, referrals, testimonials, etc come in.

From my perspective, I want to work on your project as little as possible,
because it's likely tedious and boring, so I'll charge a higher rate and plan
to get done ASAP. Clients see high rate and think "ah... he's going to run up
as many hours as possible" (well, some do).

With most projects I'm involved in, there's some reasonable upper limit on
budget regardless of hours or rates. They may have a few months to get
something done, and $x. When I can to the level of knowledge and trust, we can
prioritize the work and scope. Those engagements end up a bit more like 'fixed
bid', but the bid is "best effort on these items, in this order, by this date,
for $x". Everyone's expectations are known up front, and they have the "gotta
haves" and "nice to haves" prioritized. Doesn't mean nothing ever changes, but
that approach - when I can get there - has been great.

------
amorphid
Having done consulting work, I've found that any business model that involves
sending someone the bill is a big pain in the butt. When I worked up the
courage to ask clients to pay on retainer, that helped quite a bit. Cash flow
is wonderful, and having the ability to pay yourself from money you've already
collected is pretty awesome (if you can manage the retainer responsibly).

Here's a tip I learned for getting clients to pay a retainer. Have an hourly
spot rate, and a discounted retainer rate. I charged $100/hr for the service I
provided as the spot rate, and $85/hour on retainer. Almost every client
switched to the retainer, because "Hey, 15% off!"

------
davemel37
Its really quite simple. As a seller, you want to frame your price in terms of
value created. As a buyer, you want to frame the discussion around the cost to
deliver the product or service.

Hourly pricing revolves around cost to deliver, not value created, so it's
usually going to be better for the client and worse for the developer...

The only time this balance changes is when the developers opportunity cost
nears the value created...so the hourly rate captures most of the value...

of course both sides can mitigate their risk by giving up this advantage.
(i.e. if a developer charges hourly, they can make sure they dont end up under
water on the project but in exvhange they wont capture the full value and vice
versa.)

------
debacle
I have a junior dev on my team that brings this up all the time. I don't
disagree with him, but as soon as you've worked on the client accounting side
of things, you see that hourly billing is the absolute best, most transparent,
and easiest way to bill for work.

------
leepowers
> What if by being a better developer, using the proper technology you can do
> the project in half the time it would take other companies?

In my experience it's rarely a technical challenges that negatively impact
project timelines. Usually it's changes and revisions coming from the client
side (though all parties can and should submit changes). The randomness (and
hence risk) in a project doesn't come from the initial scope agreed upon. It
comes from the fact that people are dynamic, and the act of building software
is dynamic. A feature that appears complete at origin will almost always
accrue changes, tweaks, and revisions.

These dynamics are difficult to map to a fixed cost project.

Additionally, as a worker, you are always measured by hourly rate, whether or
not you charge by the hour. A $5000 project that takes 500 hours to complete
values developer time at $10/hr. If you can get the job done in 50 hours, the
labor is worth $100/hr. Your technical acumen is not the sole determinant of
this time variance, instead it depends on the behavior and temperament of all
the project stakeholders.

------
joeblau
I remember working for a government contractor in Washington D.C. We had
1/10th of an hour building. You were literally supposed to build down to 6
minute increments. Fun times.

~~~
mgkimsal
Have had a couple of those over the years. The time keeping people never liked
seeing ".1 hours - waiting for crappy timekeeping forms to load and save"
entries

------
rl3
What about billing daily?

If memory serves, I've read of positive experiences with this right here on
HN.

------
erroneousfunk
I've always billed hourly, I've read the arguments against it (including this
one), and I have't changed my mind about it. Occasionally, I'll sense that a
client needs more or less hand holding, or that a particular project will be
super fun, or a huge drag, so I'll adjust my hourly rate up and down, but this
method of billing, overall, works really well for me.

Keep in mind though, I'm not a full time contractor. I do a few hours of
freelance work a week (10-20 hours a month, for 1-3 clients), in the evenings,
mostly on small projects that just take a few hours.

In addition, I'm unusual because I focus in a small specialty: web scraping,
data collection, and data sourcing. I write web bots and design data
architectures, basically. This is great, because I do variations on the same
thing over and over again, it means that I very very rarely run into hidden
problems and can very accurately estimate how long it will take me to collect
a set of information from a particular source. I've actually walked away from
work that was outside of this scope (even though I have a master's in software
engineering, have done it for 10 years, and was perfectly capable of the job)
just because I knew it would be a higher risk to bill for accurately, and
didn't want a potential headache for the client or for me.

So I strike a middle ground between hourly billing and "fixed cost" that I
believe benefits both sides: "This will take 3-4 hours, the deliverables will
be <blah>, I bill $x/hour. If I find something that proves to be a huge
blocker that, for whatever reason, I didn't see before, I reserve the right to
revise this estimate upwards and ask for your approval on the revised
estimate, but, in that case, you will not be obligated to pay for any work
done up to that point, until you accept the revised estimate, if you choose to
do that."

It's not uncommon that I discover that there's a method of collecting data
from a site that I didn't see before, that is drastically faster than I had
originally anticipated. Of course, I _could_ do as the author suggested and
bill for the original estimate, reveling in my loads of cash and free time,
but here's the rub: I don't.

I actually really enjoy telling the client: "Hey, check this out! It only took
half an hour! Anything else you want me to do?" and clients appreciate it. I
get paid fairly for my time, and fairly for the difficulty of the project. In
theory, I figure, if the clients were to shop this project around on the open
market, someone else could figure out the "trick" and underbid anyone pricing
based on "value to the client," and, of course, there's the danger that
clients could figure out that this was NOT a 3-4 hour project at some point
down the line, and I'd like to maintain their trust.

In addition, I've found that clients who get a "surprise bargain" are more
likely to recommend me through word of mouth, they're more likely to add on
extra work/features to meet their original budget anyway, and I feel good
about myself. Is "feeling good about yourself" worth an extra few hundred
bucks here and there? Maybe not, but, like I said, I'm getting paid exactly
what I wanted to get paid my time, so it doesn't bother me too much.

But I am also billing based on value, and always keep that in the back of my
mind. Over the last couple years, I've actually doubled my hourly billing
rate, as I create tools, shortcuts, develop better techniques, and even add
more value as a consultant for the client.

I've certainly toyed with the idea of creating web scraping tools that I can
monetize as software (although it's a crowded space), moving towards the
"fixed cost for the value this adds to your life" model, but for my freelance
work, I just really enjoy sitting in my pajamas in bed, Netflix playing in the
background, mindlessly cranking out some code and exploring new techniques
while getting paid to do it.

I'll be the first to admit that hourly billing doesn't make sense for
everyone, and every project, but I think I've found a good balance of risk for
myself and the client that's appropriate for my skill level, specialty, and
financial needs, and I'm just fine with that.

~~~
goeric
You sound like an awesome developer. Would love to keep you in mind for
projects down the road. Would you ping me at the email in my profile so I can
have your information? Thanks.

------
tormeh
Some things are infinite time sinks. The customer always argues that the
contract implies more features or that they should have higher quality. Or
even worse, you're in the unenviable position of working on a legacy project
where each bug fixed creates a new one (or close). Fixed-cost can be a drag
sometimes. And it incentivizes the sloppiest possible implementation.

------
GoToRO
Bill by value if you already have the product/feature, bill by hour otherwise
because the client never knows what he wants/needs. This way you put some
pressure on them to make up their mind.

------
grenoire
Contract schemes are still being discussed extensively as principal-agent
problems in ecomomics. Communication between the principal and the agent to
understand the needs of both parties matters a lot.

------
swap32
This is such bollocks. When I increase my skills and speed by 2x in a year, I
increase my hourly rate from $100 to $200. Simple.

~~~
dagw
And your clients never blink at this?

~~~
swap32
Yes they do. Then I convince them why I'm worth that much. My clients tell me
that my price is 2x higher than the highest they've paid for the same job and
yet they happily pay me.

~~~
CosmicShadow
So do you think you can get to 500 or 1000/hour with this strategy? I don't
think charging much over 200/hour is that doable as a dev unless you are very
specialised and well known. Value based Billing allows you to do this. I've
been stuck at 200/hour, and that is still hard to get, but just did a Value
based deal that was an effective hourly rate of around 1000/hour. I'm trying
to figure out how to go to the next level because at some point no one will
think you are worth 10-20x their hourly salary no matter what you say so you
need to frame it differently. I don't want to hire more people or work more
hours, I just want bigger, more profitable deals.

