
How to charge clients: flat fee vs. hourly rate? - Concours
http://watilo.com/how-to-charge-clients-flat-fee-vs-hourly-rate
======
ekidd
An hourly rate is easier, because you don't need to worry about scope creep.
But your total bill should _never_ surprise a client—you need to communicate
at each step of the way.

A flat rate, on the other hand, allows you to charge for the value you
provide, and gives your clients a predictable budget. By charging a fixed
rate, you're saying, "I can do this work quickly and well, and I'm sure enough
of my estimates to take on all the schedule risk."

On the other hand, fixed-priced projects can explode horribly when the
requirements inevitably change. I suspect that _somebody_ usually walks away
unhappy.

I use a hybrid system: I break the project down into features, and offer a
quote for each feature. The quotes are measured in "points" (as in XP or
Pivotal Tracker), and I charge a fixed price per point. My clients choose
which features they want. And if the spec changes, we just scrap some existing
features and draw up new quotes.

If you're a highly-productive developer, and you're good at communicating with
your clients, you might find that this system offers something for everybody:
Your clients get predictability and flexibility, and you get a strong
incentive to become a better developer.

~~~
dennyabraham
This is definitely my favorite system when I can get clients to sign on to it.
It manages expectations, defines scope, and ensures communicative development
at the same time.

I also worked for a firm that sold sprints whose point velocity would
automatically adjust to account for point value fluctuations.

~~~
nickmolnar2
We have tried just about everything at our shop, Thirdi.

Fixed rate quotes are dangerous because they make all the pricing decisions at
the point where you know the least about the product. They lead to waterfall-
esque development, since your only shot at avoiding scope creep is to catch
everything up-front. Plus, change requests feel like nickel and diming to the
client, slow the project down, and are just generally bad service.

Hourly billing is difficult to sell: would you buy a house, knowing that the
sale price might increase by 30% after you moved in? Plus, you run into the
problem of those hours not being tied to a productivity level.

We've started giving high-level estimates of projects up front, but not
committing to a specific scope or price. Instead we invoice for each 2-week
sprint with set deliverables. This way, the client is paying for features, not
time. We start a feature backlog at the beginning of a project, but add in
much more detail right before each sprint starts. The client always knows what
they're buying, and we can quickly tell if we're running ahead or behind on
the project based on whether we are finishing sprints early, and how many
features we are knocking off.

By not getting married to one feature-set at the beginning of the project, it
also allows us to throw in 'nice-to-haves' that might be easier than expected,
or scale back less important features if they turn out to be more complicated
than we thought. It does add time for communication and managing the backlog,
of course. We have a dedicated project manager and a QA lead to keep this
stuff away from our development team, otherwise they might have all gone mad
by now.

------
patio11
Tips from Thomas, which I have used to the benefit of clients and myself:

1) Any worthwhile developer sounds expensive when you break it out as an
hourly rate, so don't. Charge a weekly rate tied to specific business goals
which you think you can accomplish within one week, two weeks, three weeks,
etc. If your client wants to dicker, dicker over scope, don't dicker over
rate. Dickering over rate will hurt all your further business with that
client. If e.g. $21,000 is too much for the budget, tell them what they can
get for $14,000 and let them make the call on whether $7,000 is worth not
getting $DIFFERENCE. Whether it is or isn't, it doesn't chisel anything out of
your _next_ engagement with them.

An amazing truth about the world: $X00 an hour is a lot of money, but $X00 *
160 for something which makes a meaningful difference to the bottom line of a
real company is cheap at the price. Their pricing anchor will be other
strategic initiatives rather than e.g. "You make more than I do!"

2) You bill on a time and materials basis. Basically, my best estimate is that
one week of work gets you $FOO and $BAR. What you actually have at the end of
the week is what you are due at the end of the week. If you change your mind
on scope for $BAR in the middle of the engagement and it doesn't get done in
the week, that's OK, subject to availability you can buy another week.

3) The basic offering is "A contiguous block of my time starting at a mutually
convenient date in the near future." Things which add business value on top of
that cost extra. Want to start working next week? Sure. Costs extra. Want to
split the engagement into two parts? Doable. Costs extra. Want support?
Wonderful. Costs extra. Want support with an SLA better than "Best effort to
answer emails within a day"? Costs extra. Travel? Extra, and you reimburse
costs as per your company's usual travel policy. (If I had heard that line a
year earlier I would be five figures richer to the detriment of exactly no
one. Doh.)

~~~
biot
It sounds like you prefer fixed scope of work for a fixed price? How do you
adjust when your estimate of delivering a specific objective is off? And how
do you factor that into your schedule if you have commitments with other
clients?

I can see this being a lot different for someone providing a week of SEO
consulting vs. a week of software development, for example. Two hours of
keyword research always takes exactly two hours. But if $FOO and $BAR are
software features which involve third party integration or dealing with race
condition bugs that are difficult to pin down, one week can easily turn into
much more.

------
berkes
After almost ten years of contracting work as webdeveloper, I have set some
simple rules for myself:

* If project is described, specced and scoped well: fixed price.

* I can spec, scope and describe the project _with_ the client; never _for_ the client: most simply don't read piles of specs, misunderstand wireframes and so on. We then have a specced project, which allows me to offer it fixed-price.

* In all other cases, I won't ever work fixed price, because one thing is guaranteed: the noneexisting specs will shift, the wireframes in the head of the client will be "different then you understood them" and you will go over your allocated time, on your own money.

* A middleground solution would be to give a fixed price for the well-known territory (setting up a set of servers, installing, say, Drupal with some wellknown modules) but move over to hourly rates for all the (as yet undefined) custom work.

To sell this to clients, I simply give them a vast discount on hourly rates:
after all, the client is carrying the risk. If a client does not understand
this, then I bail out of the project: I can simply not afford to carry the
risk of a) Not getting payed for several months, because of a delay of several
months. b) With every additional 100 hours, seeing your "wage" drop another
few dollars. I have had projects, where in the end, I worked for less then I
would have made, had I spend these hours working in the MacDonalds. You can
explain a client that having their developers carry such a risk, will bring
themselves the risk that at a point the developer will simply quit (without
pay): leaving the client with a huge amount of wasted time and still no
releasable project.

~~~
andrewflnr
I really like that middle-ground solution. I might do something like that if I
get another free-lance job. Thanks.

------
tptacek
Any time you hear yourself thinking "I'll quote this part of the project based
on my hourly rate", please at least use a _daily_ rate. You're a sought-after
professional in a white hot market. You don't do partial days.

A customer that's worth bending that far backwards for is worth a couple hours
_gratis_. Everyone else can just pay your daily.

Every quantum of time higher than "hourly" is more favorable to you. Data
entry temps might look attractive at their hourly rate, but developers have
frightening hourly rates. Even just doing your quotes in chunks of eight hours
frees your client up to think about how much you can get done in a day.
Nothing gets done in an hour.

You have a 1-day minimum. Think of it this way: there is _no way_ you can
expect to be effective working for two different clients 4 hours each in a
single day. It takes too much time just to get back into flow. So any time you
quote less than a day, you're either giving the client the rest of your
availability that day _for free_ , or you're stealing it from another client.

~~~
jules
In my experience working on one thing for 8 hours isn't the most effective way
to work. I find myself more effective when working on multiple tasks in one
day if they require thinking effort. A lot of the thinking doesn't get done
when sitting in front of your keyboard, but rather when you are taking a
shower or taking a walk. But passively thinking about a single thing during
those activities doesn't exploit your thinking potential fully. You can't
think that far ahead.

If you have two projects you're working on, you can think a bit on one, and
when you're stuck you think a bit on the other. When it actually comes to
working, you have enough new material to work for a couple of hours on each
project. This working will uncover new things to think about. If you instead
work for 8 hours straight on a single thing, then after a couple of hours
you'll hit things that require thinking before you can proceed, and doing that
in front of your computer doesn't work but taking a walk or taking a shower
isn't billable -- and even if it were I'd still get more work done when
working on more than one project.

~~~
tptacek
I don't want to touch this developer workday thing with a 20 foot pole. Work
however is productive for you to work. But don't communicate to your customer
that you are billable in increments smaller than a day.

------
pingswept
I've worked as an engineering consultant for 10 years. Here's the best
algorithm I've come up with.

1\. Guess how many hours you think the project will take to complete. (This is
hard.)

2\. Guess the highest number the client will agree pay for the project. (This
is also hard. I find that saying things like, "Do you see this as a small
$5000 project or a more substantial $50,000 effort?" is useful.)

3\. If that results in an acceptable hourly rate for you, propose this as a
flat fee to the client. Otherwise, figure out how to make the project smaller
or leave.

4\. Do the project and bill the client with an invoice that makes your hourly
rate clear. (If the project takes longer than you expected, give the client
those hours for free. If the client tries to add more stuff to the project,
refuse to do those things under this contract.)

5\. Now you've established an hourly rate with that client. If you did a good
job and the client is reasonable, you can now do future projects on an hourly
basis.

Eventually, you will want to raise your rates, which is hard to do. I've found
it easier to just make higher flat estimates, and then finish them faster,
making my effective hourly rate higher. The key here is that people balk at
$XXX per hour, but they'll often pay $XX,XXX at that rate if it's for
something they need.

There's definitely the risk with this algorithm that you will charge too
little and work too long. I think the hard truth is that even "hourly"
projects are usually charged a flat fee, plus or minus a few percent, because
most clients aren't lying about their budgets. If you estimate a project at
100 hours at $150 per hour, they will expect you to complete the project for
something very close to $15,000. If you end up saying, "Well, that was just an
estimate. It actually took 200 hours, so you owe me $30,000," they might pay,
but they won't hire you again, which makes your hourly rate terrible because
you have to spend free hours finding a new client.

I think the right knob to tweak in doing work on a project basis is often
quality. If you've agreed to do X for $XX,XXX, the price is defined with great
precision. The project is not. You should strive to deliver the best results
you can, but you can omit the engineering polish you'd like to put in--
finishing on time and on budget is its own kind of polish, and one that people
who hire consultants particularly appreciate.

Edit: I should add that putting free polish on a project is often the best
sales work you can do.

~~~
T-hawk
> If you end up saying, "Well, that was just an estimate. It actually took 200
> hours, so you owe me $30,000," they might pay, but they won't hire you again

This bears repeating. Has anyone else noticed how the business world has
redefined "estimate" into exactly the opposite meaning? Now it means, more
often than not, an exact number etched in concrete for the beancounters to
lock in their costs. In my previous job at a financial software consulting
company, we developers learned to fear any call for an estimate. We even
frequently had conversations from management that went "give me an estimate
for this development, and the client has already approved a ten day work order
so your estimate needs to be exactly ten days."

~~~
dan_manges
It's helpful if you let people know as early as possible if you're going to go
over the estimate by a substantial amount. In the example in the grandparent
comment, I can understand why the client would be unhappy paying $30,000 for a
project that was estimated at $15,000 if they didn't find out until the very
end. Imagine if you had to get your car fixed and when you went to pay the
bill it was twice as much as the estimate, and compare that to the experience
of getting a call part way through to inform you that the fixes will be more
expensive than originally estimated.

------
ForrestN
I've found that by far the best strategy has been coming up with a flat quote
for the rough draft, and then billing the revisions phase by the hour.

This way, the incentives line up: the part that you have total control over,
you are incentivized to go as fast as you can, to work as efficiently as you
can, etc. Then once you've delivered a rough draft, the client is incentivized
to be as clear as possible and not to endlessly change his mind. And even if
they do, you're happy because you can bill for more hours.

I think splitting the difference in this way has worked very well for me in
several years of client work.

------
rick888
I think a better idea is to charge a flat fee for the project (you get it
nailed down before working on it) and then per/hour for any additional
changes.

------
dools
I use an hourly rate to calculate my fixed prices based on estimates.

It's rare that on a large project a client will accept an hourly rate (hourly
rates usually occur on maintenance agreements in my experience with a cap over
which extra approval is required).

The trick to staying profitable is to iterate in very small chunks, the
earlier in the relationship, the smaller the iteration.

Deliver discrete value with each iteration so if they're not happy, they can
walk and reasonably expect another competent contractor to finish the work
(this means using popular tools and good documentation).

As you get further along in the relationship and on each project you get a
better idea of how long things typically take and can provide higher fixed
price quotes with less risk. Also as the relationship improves and your client
trusts you more, you can do things like give "best case" estimates with the
proviso that it may be revised upwards if a task turns out to be more
difficult than you'd thought (in exchange for this, you can charge the client
less money because you don't need as much "padding" to absorb the risk
yourself).

Eventually you move into the maintenance phase where you bill by the hour and
by that point the client generally trusts you enough so they know you're not
trying to screw them.

------
peteretep
Consider charging a day rate. Only you know how many hours it takes you to do
a 'day' of work.

~~~
dan_manges
I think it's misleading to quote a day rate and then work less than a
typically expected number of hours. The client will make an assumption that a
day is approximately 8 hours and wouldn't be happy if he/she found out that
you were only working 4 hours per "day."

~~~
Dove
I disagree. The client is much more interested in what you get _done_ in a day
than how much time you spend doing it.

------
teyc
Your overall fee should always reflect competitive pressures.

Your competition are:

1\. Other local developers who have the same domain expertise

2\. Other local developers who don't have the same domain expertise

3\. Outsourcers

4\. Alternative technology stacks

Each of the alternatives have their own risks and advantage. If you are
dealing with portions of technology where you are not familiar with, then you
have to ask yourself whether it makes sense to charge more to cover for the
additional time, or incur the cost of learning on yourself. In which case,
whether it is a technology you wish to master. You have to remember it only
takes one little problem for things to blow out.

There is another aspect to consider: pre-built components and your own IP. You
can command a higher hourly rate if you tell them that you will include
software libraries that you bring to the table, or alternatively bring the
overall cost down. In some countries, there are taxation differences between
selling licenses and selling labour.

It should also reflect timelines. Some people are prepared to wait, other
people need this immediately. Your charging should also reflect this. For
instance, when people have an urgent need, you should put more effort into
providing confidence that the project will be delivered on spec and on time,
and charge accordingly (i.e. don't try to compete on price).

In addition, your cost should reflect the number of attempts the customer has
made in the past. For example if he had two failed attempts, you have to ask
yourself what is actually wrong, and perhaps he is unable to communicate the
requirements properly.

------
joelrunyon
Bill on value not costs.

Whether you're billing hourly or a flat fee, you're still probably billing
hourly (factoring all the hours that you can plus the amount of risk you think
you can handle).

Figure out how much value added this project with add to their bottom line in
the next 3/6/9/12/36 months. Bill them accordingly.

As long as it's not obscenely out of the market range and you can PROVE the
value of what you're doing, people are happy to pay.

------
csomar
Well, I found the best thing for me is to create an estimate based on my
hourly rate. Clients generally don't care a lot about the hourly rate but the
global cost.

Since it's an estimate, I draw the client attention to the following facts:

\- If the requirements change the estimate will change too.

\- I work on an hourly rate. If I think that the project will cost more, I'll
notify you why and by how much.

------
nesbot
It boils down to who wants to take on the risk, you or the client. In all my
years, I have never worked on a project that didn't change in scope (smaller
or larger) ... even my own. It's almost inevitable in fixed price that one of
the participants always ends up unhappy.

After having run a services business for many years and experiencing the
issues with fixed price, I am definitely in the hourly rate camp. As for the
argument that it punishes the speedy, well it's up to you to sell an
appropriate rate that you are happy with. That way you can't lose no matter
what the client requests or changes and it keeps your personal PM part of the
job to a minimum. I can hear the "what about AAs/CRs" already but we all know
it's a hassle going back all the time asking for more money if the project is
changing a lot.

It's much easier to take each new decided feature, say yes and charge for the
time it takes.

 _"Time is money"_ and that's how you should charge for it.

------
jeffreymcmanus
This dilemma is where an iterative approach to development can really come in
handy. Charging $200/hour for an open-ended project is challenging to get any
client to accept. Charging $x/hour for a 3-4 week iteration (where the
deliverable is a functional, but not necessarily complete, piece of software)
is much easier.

I have been burned so many times by fixed-rate projects that I generally turn
the work down every time the client insists on it. It throws the alignment of
the developer and the client completely out of whack, takes away the paltry
amount of leverage that the developer has over the project, and it basically
assumes that you won't run into unknown unknowns. This means it's terrible for
the developer, but it's actually quite a bad deal for the client as well.

Fixed-rate coding assumes that software development is at the same general
level of predictability as having the oil changed in your car.

------
kristiandupont
I have had good experiences with what we call "Collaborative Contracts":
[http://www.zealake.com/2010/09/26/pay-less-for-your-agile-
pr...](http://www.zealake.com/2010/09/26/pay-less-for-your-agile-project/)

Basically, you charge an hourly rate but a rather low one. A bonus is added
for reached milestones. This gives you the best of both worlds. The buyer is
not tempted to "sneak in" more features or argue over some spec because he is
still paying per hour. However, the developer is interested in working as
efficiently as possible as the bonus is a fixed amount which will mean that
his effective hourly rate goes up with fewer development hours.

------
gte910h
When you're starting out, just DON'T start with flat fees. Your rates aren't
high enough, and you won't have the leverage/experience to successfully
navigate the issues with requirements changes.

But once you get it, they're pretty nice to offer to people.

------
harichinnan
Alternative Fee Arrangements used by law firms could be adopted for this. The
following are most commonly employed. 1\. Fixed Fee 2\. Capped Fee 3\. Volume
Discount 4\. Early Payment Discount 5\. Fixed Rate 6\. Blended Rate 7\.
Retainer

The idea is you have a lawyer draft a complex agreement with multiple fee
arrangements, most involving some math. And provide an invoice with pre-agreed
work descriptions. Lawyers use UTBMS. You should be able to come up with
something that you and your client agree. This makes your invoice look more
"professional" and easy for the accounting departments of your clients.

------
sorbits
I recently switched to invoicing per commit (current rate being €40).

A flat fee is risky for you and charging per hour is risky for the client (and
tedious for you to keep track of) — the commit is less risky because he won’t
be charged for half the day you spent tracking down a stupid bug you
introduced in an earlier commit or work you threw away because your
understanding of the involved API was immature when you started it etc.

~~~
phunehehe
Then you'd have to explain to non-technical clients what commits are, and then
it comes to the problem of big and small commits. Some enjoys "commit early,
commit often", other enjoys squashing commits into a big one. This solution
reminds me of invoicing per line of code.

~~~
sorbits
Naturally if your commits are not fine grained, as I thought most agree is the
recommended style, then this scheme would not be in your favor.

As for explaining it to the client, I’d probably just call a commit a
“feature”, but something like “move button to the left” or “make it darker” is
also a feature if the code is already written, and “making the code nicer” (to
ease future maintenance) is a feature as well (and if he thinks this is not
worth paying for, you can hold back on the refactoring, but when he wants you
to extend the project beyond the initial goals, you can then point to him
opting out on “clean code”, so the rate for the extensions will be set higher
due to the less flexible code base).

Anyway, if you do disciplined fine grained commits, try look at some of your
past projects and see how many commits you did and what the rate per commit
would be given your estimated value of the work that went into the project — I
found it surprisingly consistent.

~~~
mattmanser
This just doesn't make any sense to me as a developer, I can't imagine what a
client thinks of it, incredibly opaque.

And you seriously charge €40 to move a button to the left or change a few hex
codes? You must have some desperate clients.

~~~
sorbits
Moving a button or changing color was to exemplify for a hypothetical client
what a commit is, if said client was “non-technical”.

------
robjohnson
I've always been a per-project type of person. If the requirements are clearly
defined up front, you as the developer don't need to worry about scope creep.
Obviously, this is a double-edged sword if you find yourself in a position
where something takes you longer than expected. But if that's the case, that's
really your own fault - not the client's. It seems to be the most equitable
basis IMO.

------
vaksel
the problem with flat fees, is that clients tend to want extras, so you can
end up working for minimum wage.

~~~
tptacek
The problem with your business is that you take projects that don't have
formal statements of work.

Professional consultants always work under a SOW, either as an exhibit to the
standalone contract they have with their clients or, for major or longstanding
clients, as the "per project" contract that accompanies a master (MSA)
contract.

The whole reason you write a statement of work is so that the client can't
reasonably claim that an "extra" they want is actually within the original
scope of the project. If you chronically say "yes" when your contract (and
good sense) says "no", then the problem isn't with how you quoted the rate;
it's that you're unprofessional.

I'm sorry to be harsh about it, but the histrionic tone of your comment
("working for minimum wage") seemed to justify it. If you're even coming close
to working for the rate your expected full time salary would back out to,
you're doing something so wrong as to warrant shouting.

------
rafski
My preference is to scope well, give the client a per-project quote and then
charge hourly for out-of-scope work.

This way, the client knows what to expect to pay from the start and if he
introduces changes on the way he knows it is going to cost him extra.

------
foxit
I liked Steve Friedl's thoughts on this. (Skip to the Billing heading.)

<http://www.unixwiz.net/techtips/be-consultant.html>

------
sathishmanohar
Clients always have varying project scope and specs, so in my experience
hourly rate works well.

------
TheHunter
watch the Mike Monteiro FU Pay Me Speech. <http://vimeo.com/22053820>

~~~
stevengg
Business bad? Fuck you, pay me. Oh, you had a fire? Fuck you, pay me. Place
got hit by lightning, huh? Fuck you, pay me.

<http://www.youtube.com/watch?v=0c3bhh8fqYs>

------
ansy
I don't have good citations for these figures, but I'm pulling this out of
Stephen Fishman's book "Working for Yourself."

In one informal survey of self-employed people it was found those who charged
fixed fees earned on average 150% more than those who charged by the hour for
the same services. In another survey by a trade journal it found that self-
employed people who charged a fixed fee earned 95% more than similar people
who charged by the hour. I believe these surveys were across industries and
not specific to software.

Make that what you will, but it seems to suggest on average you're much better
off charging a flat fee. I can conjecture a few reasons why.

1) If you're good enough to have the confidence to charge a fixed-fee, you can
estimate based on the normal hourly rate and add a healthy amount of
contingency. Because your estimates will be accurate you will almost always
come out ahead compared to going with a straight hourly rate.

2) Customers are willing to pay a premium for cost certainty even if that cost
ends up being higher.

3) By putting a cap on the cost of a project, the developer is less likely or
unable to exploit that so the project may actually get completed faster and
more efficiently than if a payment ceiling wasn't over his head.

Controlling a fixed price project is difficult and simple at the same time.
It's difficult because it's so easy to hang yourself if you're not careful.
It's easy because all you need to do is define the scope ahead of time and
agree up front that the price and time needs to be adjusted when the scope
changes. So whenever the client asks for something outside your mutual
understanding of scope you have a provision in the contract that states you
must amend the contract for the difference in cost and development time. It's
called change control, and can be as simple as "hey, that feature is way
beyond what we agreed upon. I can do it but it will cost an extra $4,000 and
the delivery date needs to get pushed back two weeks. Sign this contract
amendment to that affect if you still want me to do it."

Likewise, if something that was assumed in the contract turns out to be
untrue, that can be revisited with a contract change. For example, assume
there is an open source library for barcode scanning. If it later turns out
there isn't one suitable for the task, you're completely within the contract
to say, "Hey, I know we were hoping to save some time and money by using this
library. But we agreed it was a risk and after I used it more it has too many
issues and this endangers the success of the project. We can buy this
commercial package for $4,000 but I will need to redo a lot of my work. I'll
give you a break on my labor, but it will still cost $6,000 and add another
week if you agree to it." Something like that.

