[_lc1i]

If I am regularly working onsite at a client, and I leave early on my own accord, I am not going to bill a full day. How would that be fair to the client? Sure, billing for a full day is optimal for my business, but I don't see how it's optimal for the client.

I do not use hourly increments because my clients are awful or because I am low on the food chain. I choose hourly because it's the most straightforward way for me to provide my clients a hired hand while retaining flexibility on any given work day.

[tptacek]

Your definition of the word "fair" is broken.

You've defined it to mean "extracts from the relation, at all feasible cost, the maximum amount of value for the client".

That's not what "fair" means. "Fair" means that both the client and the consultant agree that the terms of the engagement are equitable: that the consultant is being compensated in accordance with the value they're generating.

The clients you want to work with will universally agree that, absent some other arrangement, it is "fair" to establish a minimum billable increment of a full day. That full day increment accounts for the cost to you, the consultant, in terms of lost flexibility and opportunity to serve other clients for the remainder of that day; it also accounts for the amount of time you're inevitably spending "ramping down" from one project before "ramping up" to the next, and for the complexity that client is adding to your schedule. It also acknowledges the fact that virtually anything you could be doing for them is worth at least one billable day.

What I find most amusing about discussions like this is the stridency of opposition to 1-day minimums. Freelancers on HN are, frequently, proud of the fact that they're screwing themselves, and proud that they're leaving money on the table.

[follower]

> being compensated in accordance with the value they're generating.

I think the above phrase is the key to understanding "per-day" vs "per-hour" billing thinking.

I suspect most developers don't think in terms of value they're generating--partly because they don't know the value they are generating.

It's easier to think that you're billing based on "how long I'm sitting in front of the computer typing" rather than "how much value I'm generating" because then you don't need to think about how much value you are generating.

From a client's point of view, they're never paying for you to sit in front of a computer, they're paying for the value you're providing to them.

I suspect part of the issue is that "per-day" still seems like a measure of time not a measure of value.

[_lc1i]

Don't be smug and insinuate I am screwing myself. I am also not against daily or weekly rates. I think they are great. But so is hourly.

Working in a development role, the amount of time I put in on a project is highly correlated with the amount of value I add to a project. If I work every day for a year on a project, I will likely provide more value than if I worked a month. If I work every day for a month, I will likely provide more value than if I worked a week. And so on.

The amount of value added for the sake of compensation gets really tricky, but that's why freelancers have a best guess hourly/daily/weekly rate.

Therefore, over a period of time for a given client, I find it silly to assume a day where I show up, change a line of code, and go home is of the same value where I put in a full 8 hours of work. Equally silly would be a client suddenly finding themselves in a tough spot and needing some extra hours put in and me going uncompensated for the extra value added.

A daily rate works great when all days are relatively equal in productivity/time or your necessary threshold for showing up for a client is much higher than an hour or two of work. Mine is not. And it's not because the client is screwing me or I'm accidentally leaving money on the table, but because sometimes I just want to go home and not work a full day. A client should not pay for that.

[tptacek]

If it is possible to be smug while telling someone "you're worth more than you're charging clients", guilty as charged.

You're not against weekly billing. Ok. I am against hourly billing. The logic I perceive in your argument is, "the client is paying me for X amount of code". I'm telling you that that's not all they're paying you for.

[_lc1i]

The client isn't paying me for lines of code added (I would often lose money if that were the case!), but they are clearly looking for me to add some sort of value. Otherwise I could just show up every day, give out some fist bumps, and go home while billing my daily rate.

Since directly measuring value added for the sake of compensation is not so straightforward, freelancers use rates (for better or worse). My argument is, the more <measurement of time> I work, the more likely I will add the value the client is looking for. Since I like a lot of flexibility in my schedule and want to still bill fairly (for both the client and myself), I use hours as my <measurement of time>.

[lawnchair_larry]

Note that most labor laws require workers be paid for a 3 hour minimum. If you get called in for 10 minutes, you get paid for 3 hours. If you get called in at certain inconvenient times, your wage skyrockets. This applies to unskilled labor jobs. Think about why that is. There is much more to "value" than the total number of minutes you warm a chair.

[chc]

If you work for 7 hours and 58 minutes, do you give them a two-minute discount out of a sense of fairness? Probably not. patio11 and tptacek's point is that for the kind of clients you probably want, a three-hour discount is not significantly more "optimal" than a two-minute discount. If the client agrees to a minimum billing increment of a day and you are doing the work you're paid to do, then it's fair. If you give them more than that, what you're being isn't fair, it's generous.

[tptacek]

Actually, "generous" isn't even the word I would use.

The clients you want are paying for (a) determinism and (b) flexibility. They can't achieve (a) and (b) with full-time hires; they'd either face uncertain expenses in ramping up people (and possibly hiring bad people), or they'd be locked in to paying for a particular basket of skills full-time for a year.

If you are providing determinism and flexibility, real clients don't care whether the number of hours you bill is 1 or 8. For most projects and most values of "hours" below, say, 40, the end result is cost effective compared to full-time hires. The client is happy to have a slot into which they can push dollars and have a predictable amount of working software come out the other end.

So, back to "generous": when you set yourself up for sub-1-day billing, you're doing a bunch of stuff that doesn't generate value for the customer. You're giving them "loose change" invoice amounts that don't impact their budgets. You're forcing them to think about the amount of loose change you're giving them. You're setting yourself and your client up for potential disputes --- any dispute is going to cost the client something commensurate with a billable day anyways. And you're burning yourself out by working harder for less money, which the client doesn't want; they want to know that 2 years from now, the same slot will still be there, accepting dollars and spitting out working software.

This discussion obviously stumbles across some nerdthink neural tripwire. "I worked for an hour, I should bill an hour!" That's perfectly understandable nerd reasoning. If it helps to translate nerdthink into business language, think about the minimum 1-day billing increment as a way of expressing your bill rate properly; you're not "billing for time you didn't work", you're just doing a variable bill rate in which a 1-hour project costs 8 times as much as an 8-hour project. Or something like that.