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.
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.
I charge hourly and I wouldn't trade it for the world (unless I change the general concept on how I want to freelance).
When I freelance, I want freedom. For me that often means taking off the rest of the day spontaneously after lunch, or just ending the day early. When you are billing for a whole day/week that becomes much harder.
I also don't bill per-project, unless I have the ability to bring a trusted project manager onto the project as well, to provide me with some security against mismanagement, for the usual reasons like scope creep.
Charging hourly also makes it much easier to juggle multiple clients at the same time. For some reason, a meeting with all the stakeholders was set up on a day I am spending most of a day with another client? No problem, I just scoot right over, bill both client hourly accordingly, and nobody has any reason to complain.
As for clients being more prone to haggling over invoices with hourly rates, I haven't had that happen to me yet (~20 clients in 2,5 years). On the contrary, for project-based billing, there is usually a lot of time spent(/wasted) up front negotiating over pricing. I always send over a timesheet with my invoice, and if I had to guess I would guess that none of my clients ever checked that.
In the end, hourly billing gives me a much more relaxed life, a much more stable income stream, a much more stable growth in income, with far fewer headaches.
Daily/weekly are billing increments, not working increments. I still track hours internally; I billed a client last year for "one day" of work that took me a week due to other commitments. Made it clear up front that I was pretty busy at the time. He had no issues with it.
Do not overcharge or be dishonest about it. But, what is this result worth to them? I'd think of it that way. I have seen people pay 250k for a months work. But, the impact was massive for the company. I am positive this is on the small side as you work up the food chain. There is some free work up front in scoping things out, but then I would sell time in blocks or packages, and do not really get into what you are charing by the hour. They must have some budget for this project, the timelines, a general scope, etc. Make your proposal around that in the context of the impact to the company.
This depends on your field and clients too. But, I'd look to move as quickly as possible from hourly to package deal. There is risk but there is also big reward.
If someone pays you 250k for a simple project. Either you got a REALLY good deal or the project is complex and it will require you to hire people. On the latter it's not about solo anymore.
> You do not want to be some charge me by the hour consultant where they can just find someone cheaper, they will start to think of you like that, and will find someone else.
I can make the same argument about hiring someone else who charges less per week or full project. Simple.
The amount you get payed is highly dependable on the client. For most freelancers, charging for a week is a terrible mistake unless you've a proven track record and some reputation.
I'm assuming the vast majority of freelancer are software developers. The location has a major impact on how much you get payed. If you live in San Fran you can charge a lot because that place is terribly expensive. Don't forget Europe has good developers fluent in English. You'll face competition worldwide.
Also, it's easier to hire someone by the hour. The client can quickly see if you work great together and even give you bigger projects. It takes some time to build reputation and trust with clients.
> You do not have overcharge or be dishonest about it. From a moral point of view, hourly is fair.
The thread rpeden references is a really sound way to implementing this plan.
Sometimes it's about the value you deliver. I'll never forget walking into a pharmaceutical and them telling me they were loosing a million pounds a week because they couldn't get their compliance documentation out of the door. They had been looking for a solution for months and been unable to find it.
I won't repeat what patio11 and others always say here, but if you are a freelancer and charge hourly, I would encourage you try and follow their advice and see how it goes. I have, and it's been wonderfully successful!
simple is a relative construct, I've experienced project you could consider simple getting good money either because:
1. the client want to pay for the project and offset the risk of it to you (read as you make a few extra night if things go not exactly as initially planned)
2. the company tried things but didn't succeed, hence looking for outside help
3. you know the people making the decision and those will definitely not go on upwork.com to get cheap labor for the same reason no one ever question going to Oracle or IBM. Those people have the wallet and simply want result with your track record
Weekly makes the management forget about you, and also you will be automating the paying process while knowing you will have a fixed income for a certain time.
Hourly = Inconsistency, unpaid invoices, constant arguments over hours.
As a full-time solo web developer for the last 8 years, I disagree and find your comment distastefully dismissive.
Hourly billing can provide flexibility, transparency and freedom. I have never had a problem getting paid for any of my hourly invoices and I have never had any arguments about my hours.
Different companies, projects and developers have different desires, needs and dynamics.
I totally buy that there are a large number of freelance developers who are billing hourly and would be better off switching to billing daily or weekly.
However, to claim that billing hourly is never the right choice is idiotic and naive. Hourly, daily, weekly and per project billing all have their upsides and downsides and work better in some circumstances than others.
One way I find very helpful in mitigating this is by getting a prototype of system, a detailed prototype made which goes a long way to clarify specs for the client and help me understand the scope.
I found transitioning to non hourly project billing extremely satisfying.
Look - in some industries, working 10 or 11 hours is one 'day.' As an hourly consultant I'm hedged against this, which is super common in financial environments. Maybe the experience you guys have is in less stressful, less demanding worlds.
Hourly is a hedge against exploitative clients.
Let me add something else. It depends on seniority and connections. If you folks are very senior-level software or systems architects, known in the business world or Twitter or through established experience, you can 'set the tone' and of course it makes more sense to, as mentioned above, charge weekly versus daily versus hourly and so forth.
In my industry (DevOps and Systems Infrastructure) it's incredibly elite to reach that level. I'd have to be blogging and doing presentations at tech conferences to be able to go to a Fortune 500 company and dictate project-level Scopes of Work. And perhaps one day I'll get to that! But my point is that this is an elite percentage of consultants.
This is bad advice.
Charging for a full week will make you lose a lot of clients. In the case of software development: The client never knows the full spec of the project and you'll have weeks were 10 hours is enough. Charging for those extra 30 hours is terrible deal for your client and he won't take it.
What you should be careful about is how much you charge per hour. You may set different rates based on context like: for a full time project project you charge X, for future maintaining (which is on demand ) you charge 1.5 times X.
Hourly also protects you agains scope creeping. Charging by the week/project/milestones requires a near full specification and it's done at an agency level where you've a team. I've been working hourly and I love it. You can try to spec out any project as much as you can, in the end you can't predict scope changes and/or unexpected problems: API is broken, missed an important email, build system is failing for no obvious reason, server went down, etc, etc.
You have to figure out when charging by the hour/week/month/milestones is reasonable. Just because someone is making 120K a year in San Fran, doesn't mean you've to make the same amount while freelancing. It heavily swings from client to client.