When you are just starting out charging by the hour and starting with small stuff is fine. But your goal should be to transition to charging by the week as soon as you can afford it, because you can't afford to charge by the hour for your whole career.
Keep in mind that those that have 'arrived' tend to take their life experience and then condense it down to bullet points without nuance, after all, unqualified statements sound so much better than qualified ones. But it's all about the balance and to get to charging by the week you may need to start by charging by the hour.
Service > product > weekly rates > daily rates > hourly rates.
The further you are to the left the more money you'll make but you have to start somewhere.
It will be the same as charging per half day, but it can help you and your client to accept that charging daily will be the next step.
Basically, I figure out what I would be happy with for 5 hours for work and then give them 4 hours plus one FREE hour for that amount.
This has the added benefit of nudging my hourly rate higher, since I always have a hard time raising my rates.
Maybe the correlation between hourly billing and bad projects is not causal.
If that's true, there is only time-based billing, and project-based billing. I've done both types, and project-based billing has been much more dangerous for me due to the need to accurately scope (or eat costs), usually for a client that has no idea how difficult "simple" additions can be (and often when you yourself cannot). Software scoping is effectively impossible to do accurately, and I've found the only way to get close is when you have already built the system in question before (or better yet, have a codebase you can reuse to hit 90% of the features in the first ~week of "work").
Hourly billing (whether you roll it up into a day/week/month) provides a way to cover myself from bad estimation, but limits you to charging for time to build and screws up incentives.
Project billing means I eat costs from bad estimation, but with the possibility of reward from over-estimation, along with the fact that you can charge for what the deliverable is worth (i.e. the value you deliver, not the time it took you to build the product).
As far as weeding out clients who aren't serious -- you can do that with a high-enough hourly billing (and generally you can get a feel for this from the client themselves)...
Could someone explain how I'm understanding the avoid-hourly-billing ideas wrong? It seems reasonable but it just doesn't seem to work for me in practice with the estimation thing, never mind the fact that clients need regular updates and rarely value good software development practices (so may seem like you've spent a week doing nothing if they can't immediately see the result/how it will save them time over the lifetime of the project).
[EDIT] - Another thing that I've realized when I was last thinking about this that I didn't include was that as complexity unfolded (and I realized my estimation was wrong), I did not increase prices/communicate this effectively to the business -- maybe that's where I'm getting it wrong? It feels like it would chip away at client trust to do so.
For those who are wondering what I actually do when I take projects on these days -- I just set a high hourly rate, possibly bundle it into weeks/months, and avoid project-based estimation because of the difficulty of scoping and the likelihood of scope changes. This also gives me an edge when the scope changes -- it's no longer "can this fit", and it's more "sure we can fit this in, it will take longer though".
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.
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.
Having a net 10 or 15 with a ~3-4% discount is also a motivator to get paid sooner than a net 30.
Furthermore, you need someone good at collecting receivables and collections, be it you or someone else, especially dealing with education, healthcare, government, nonprofits or the military... because it will happen in spite of your selectiveness and client rapport, because some large orgs think it's cool to not pay their bills.
As far as collecting receivables, I've been either incredibly lucky or smart -- it's never been a problem for me (I am also no longer in the US -- I'm in Tokyo for now) -- clients have been big enough that this wasn't a huge problem, and whenever I sense it might be I demand a certain amount up front.
I agree with what you've said, but how do you combat the estimation problem & scope creep? Discrete milestones are great but it's very rare that requirements don't change half way through a project -- what is the best way to handle that? The problem is that you often have to make the estimate with absolutely no idea what the existing conditions will look like, there's the never ending stream of "little fixes".
That comment describes building a small consultancy (= multiple people), which is the opposite of going solo.
Sure, if you want to start up a consultancy, hire people and run the risk of "you don't eat", do that, but that is a very different trajectory to going, and staying solo.
patio11 is a seasoned HNer who has done this in a fairly public way.
Please take his [no doubt interesting] recommendations about how to do consulting -- with a grain of salt.
Prior to that patio11 had been running a Bingo Card Creator and Appointment Reminder.
Corporate Consulting - is a small part of patio11 career. He managed to burn himself on that consulting path. If you want to get similar result - you are welcome to follow patio11 advice.
I think he was in the process of jacking up his rates to $50k a week, but then he mysteriously stopped consulting. I’m curious about why. He has alluded to it before, but he was was very circumspect about the whole issue/experience.
Keep them apprised of progress, manage expectations, issues and demonstrate progress consistently... toiling away head-down doesn't mean anything on its own. You want to deliver as fast and with quality as you reasonably can... non-blocking, get-it-done, tempered impatience work-ethic.
Also, a master agreement is a good idea. And then each contract is a short and simple diff off that. Makes it less painful for both parties.
Here's the post most people will direct you to for an explanation of why you'll want to avoid hourly billing, and how to get to a place where you don't need to bill hourly:
https://news.ycombinator.com/item?id=4247615
For what it's worth - all of the people I know who have been able to do software-related consulting successfully over the long term don't bill hourly. They'd actually agree with you that having a minimum billable period of a week lots them lots of clients - but it lost them the clients that would try to nickel and dime them to death and complain about every invoice no matter low the hourly rate was.
It sounds like your experience has been different though, so I'm happy to hear you've found something that works for you.