It seems inevitable that clients wonder/ask why you can't get X, Y, and Z done in a "week", when they hold a definition of what a "week" means to them. If you're billing for a week, they're going to assume you're billing for 5x8 hour days -- is the idea just to let them assume that, but you actually work however many hours it takes to get the deliverables for the week done? If so, that's basically forcing you to over estimate, or work a full work-week anyway, and then you might as well be pricing by hour (whether you show them or not).
What I've done recently is charge for X days/week, with a written agreement specifying what constitutes a "work day" for me. Clients normally don't care/micro-manage (there's enough mutual trust), and when we meet to show/discuss progress, I let them know how how "on schedule" we are (so at "based on how quickly I'm working at the current clip of 3 days/week, it looks like everything will be done in 4 weeks"). This formula would be wrong according to the usual HN advice though -- it's way too easy to translate X days/week w/ a set amount of hours that constitute a work day to X-per-hour billing.
Why do you need that "written agreement specifying what constitutes a "work day" for me."? That sounds like it's just encouraging the client to micromanage; you don't want a client that doesn't trust that you'll do a decent week's work in a billed week. And it gives you the disadvantages of a conventional job: you're now tied to working X hours/day Y days/week rather than taking a long lunch some days, working late some days, stopping early some days, and trusting that it'll all average out.
Also, I do maintain flexibility in how I work the hours -- I don't say when those hours will be worked, just how many "days" are being billed per week. Sometimes I split it up over several days, and I almost always split it up into multiple chunks on a single day. This is the part I like most about the arrangement and my current lifestyle. Eventually you have to do some work, and the number of hours/day is the number I'm comfortable with working (it's less than 8).
Now this completely goes out the window for project based pricing jobs -- If I am charging for project/milestone completion, then I do not mention "work days" because they're irrelevant, there's only the deadline and whatever scheduled checkups/sync meetings, doesn't matter if I completely ignore the project for a whole week.
This comes back to my point before -- it seems to be the only real dichotomy is whether you charge for 1 unit of time (before/after the project deadline) or whether you charge for some derivative of hourly wages (due to the preconception of what a "workday" means in most people's heads).
Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one? I guess this could work, but it feels more to me like project based pricing split up into milestones that happen to have weekly delivery dates -- not what everyone is saying to "charge by week". And the problem there is the same -- how do you avoid/deal with bad estimation?
I think in part it depends on the type of client you're working with and the type of relationship you're building.
Non-tech/software clients (ie a business paying for custom software they're going to use themselves) care a lot about the total cost of $features, and often try to manage risk of cost overrun by treating estimates as part of the contract with the developer (even if it wasn't a fixed bid contract), and will hold you accountable to the project milestones: eg they don't care why things are taking longer - 'you should have considered that risk in the estimate - it's your fault'.
Tech customers (ie a software licensing or sass company) that use contractors to supplement their internal workforce usually understand the variability better, think of the contract more as buying the (expertise and) time of the developer, and they're managing more of the project and risk themselves. When things don't go to plan, they understand that many/most times this isn't the 'fault' of the developer, it's simply the inherent risks in the task being uncovered.
It's much simpler to arrange weekly rate contracts with the second type of customer than the first.
I end up just assuming that I just don't have the tooling/skillset just yet to handle the former set of clients well yet.
No. There is a huge difference between counting hours and counting weeks in terms of how much overhead it imposes on you, and how much opportunity it gives a client to nickel-and-dime.
> Assuming you understood my previous point, are you suggesting that I should just leave the definition of "work day" vague? and treat a weekly contract as a project based one?
No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to.
We really do mean what we're saying. Charge by the week, not by the hour, really does mean charge by the week, not by the hour. No more and no less. It really does make a difference.
> No. I'm saying charge time-based, but by the week rather than the hour: that is, do not quibble about the difference between 39 hours and 41 hours, and do not work for clients who want to.
Yeah but both of these things are what bad clients do, who we agree are weeded out (usually) with higher rates.
Also "not quibbling" about the difference between 39 and 40 hours means that there is an expected amount of hours you're supposed to be working -- how does that get set? Is the answer to just not talk about it? Why wouldn't a good conscientious client ask how much time you're dedicating to the project per week, if they find your per-week scopes to be lower than what they think could be done in their idea of a work-week?
To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing. When businesses have enough headroom to not worry about whether they're maximally extracting value from you, that's when they don't care how long your work week is/what scope you set for a "week".
The legal profession seems to have no problem charging by the hour, why should we?
One could say the same about minutes in an hour - if a conscientious client thinks you're not getting enough done in your billed hours, wouldn't they ask how much of that hour you're spending writing code versus coffee breaks / bathroom breaks / sitting thinking? And indeed bad clients will ask such things, but the clients you want will accept that an hour means only that the only work you did that hour was on their project (or at least, that if you bill n hours across your clients then that corresponds to n hours of clock time on which you worked on no projects outside their collective set) and that you made a good-faith effort to work for that hour. A good client can certainly decide that you're not getting enough done in the billed time and ask you to revise your rate, or ultimately stop working with you. But good clients won't ask e.g. whether you were taking too many short breaks during a billed hour, because that conversation can't ever go anywhere worthwhile.
> To reiterate, I think the real kernel of advice here is "charge more to weed out bad clients", and the "charge by the week" to be a red herring. Charging more is doing the hard work here, weeding out clients that might attempt to micromanage, not changing to weekly billing.
Not my experience - indeed I'd say a high rate billed hourly gives more encouragement to micromanage as the client tries to "get their money's worth". For my money you get less micromanagement when billing weekly even if you charge a (slightly) lower overall rate - how much precision you bill with sets an expectation for how much precision is appropriate in all your interactions. YMMV I guess.
> The legal profession seems to have no problem charging by the hour, why should we?
As per the other reply, it's a real headache there. The legal profession has lost a race to the bottom in how billing is done. I'm sure we will too in time, as developers reach market saturation. But make hay while the sun shines.
This is not true. The "billable hour" in the legal profession is a huge source of headaches for individual lawyers and the legal profession at large. The incentive is to work more, rather than work smarter, which is often in the client's interest.
Surely the fact that the legal profession uses (begrudgingly or not) hours as a proxy for work (whether or not they actually work X hours, or who at the firm works those X hours) means something. The legal profession seems similar enough to ours (as far as this issue is concerned at least) and has been around long enough that they should have adopted a better way of doing things by now.
Specifying what a week or day is, is up to you. In regards to time as well as money.
As much as I like the 'per week' idea, there's often stuff I can't get done because someone is sick during a week. Client's don't particularly like that. If they wanted to be paying someone $x/week regardless of work output, they'd hire more employees - they're often using external contractors for multiple reasons, but efficiency is usually one.
You'll have happier clients as well, because with experience, the buffer in project-based estimations needs to be large enough that no possible hidden complexity can deplete it (barring complete show stoppers). Clients will usually be better off with time-based billing when the per-project cost estimate would come from an experienced provider.