Why I bill hourly

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.

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.

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

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.

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.

Here's a faster loading coral cache link: 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.)

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.

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.

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.

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.

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. =)

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.

For larger projects and clients, I recommend you look into agile contracts: http://www.bestbrains.dk/Blog/2009/06/03/CollaborativeAgileC...

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.

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.

What about using Scrum and billing by the story point?

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.