6 ms·

I believe you'll find that overall consensus on HN will strongly disagree with you on this point. Here's the post most people will direct you to for an explana

by rpeden 8y ago

I believe you'll find that overall consensus on HN will strongly disagree with you on this point. 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 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.

hardwaresofton 8y ago
One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week is a measure of time. 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".
- groestl 8y ago
  > avoid project-based estimation 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.
  - hardwaresofton 8y ago
    OK, so then in my head the advice is now: "do time-based billing but avoid hourly increments, instead opting for weekly/monthly but never disclose how many hours per week you work". 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.
    - ascar 8y ago
      I think the important point is not that it can't be broken down to a hourly rate, but that the smallest incrememt is 1 week or a day. They simply can't book you by the hour. Specifying what a week or day is, is up to you. In regards to time as well as money.
    - lmm 8y ago
      > 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.
wizardforhire 8y ago
This! One of the hardest things to learn on your own is how to say no and why. Learning how to identity problem clients and being able to say no to them in my opinion is one of the most valuable skills to attain. Not only for your sanity but also your success.
- newnewpdro 8y ago
  Learning to say no and set boundaries in general is a life skill, part of being an adult, and one many often never develop.
iceninenines 8y ago
I've been doing client-facing Fortune 500 and startup tech consulting for about 30 years. If you're good, be choosey about clients and only work with the ones who will pay by the week, or preferably, by the milestone. You want to know your time is going to good use and that they're not going to get resentful or have any question about delivery. 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.
hobofan 8y ago
> https://news.ycombinator.com/item?id=4247615 https://news.ycombinator.com/item?id=4247615 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.
- csa 8y ago
  Solo consultants can and have successfully followed the advice in your linked post. patio11 is a seasoned HNer who has done this in a fairly public way.
  - dennisgorelik 8y ago
    Patio11 is a full-time employee at Stripe. Please take his [no doubt interesting] recommendations about how to do consulting -- with a grain of salt.
    - grzm 8y ago
      'patio11 has been at Stripe for 2 1/2 years and was solo for many years preceding. I think his reputation is pretty solid, and have a hard time imagining how being fully employed at Stripe for the past couple of years should now make his past advice require seasoning. Have conditions changed so much recently? Would you care to expand on what you personally are concerned about (as opposed to vague aspersions)?
      - dennisgorelik 8y ago
        Prior to being a full-time employee at Stripe patio11 and tptacek tried to launch a startup [unsuccessfully]. 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.
    - 8y ago
jacquesm 8y ago
The HN consensus has simplified things in such a way that any shades of gray are tossed out. 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.
- bermanoid 8y ago
  I agree with all of this, but I'd warn that unless you really know what you're doing and what can go wrong, jumping from weekly billing to project billing can be super dangerous and you're taking on a lot of risk. Most people aren't great at locking in scope for projects, let alone estimating the work it will take once the scope is locked; once you agree to per-project billing, you've committed and are on the hook for errors on both fronts.
- j1elo 8y ago
  I don't understand this comment as a response to your parent one. The condensed bullet point that it linked shows that dropping hourly rates wouldn't happen until step 5. As I understand it, all you describe would fall under the period of time one takes to get through 1-4
- lukego 8y ago
  Having any rate helps to do algebra too. Clients can suppose that $x/hour ~= $8x/day ~= $40x/week ~= $1760x/year. So even if you quote an hourly rate the discussion can still be "how much should we budget for a team of ten people next year." Maybe the correlation between hourly billing and bad projects is not causal.
- pasta 8y ago
  To add: you can even charge by the hour in blocks of 4 if you feel more like it. 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.

by rpeden 8y ago

hardwaresofton 8y ago

One sticking point I rarely see discussed with the prevailing line of thinking (noted by tptacek, patio11 and others), is that a week is a measure of time. 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".

groestl 8y ago
> avoid project-based estimation 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.
- hardwaresofton 8y ago
  OK, so then in my head the advice is now: "do time-based billing but avoid hourly increments, instead opting for weekly/monthly but never disclose how many hours per week you work". 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.
  - ascar 8y ago
    I think the important point is not that it can't be broken down to a hourly rate, but that the smallest incrememt is 1 week or a day. They simply can't book you by the hour. Specifying what a week or day is, is up to you. In regards to time as well as money.
  - lmm 8y ago
    > 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.

wizardforhire 8y ago

This! One of the hardest things to learn on your own is how to say no and why. Learning how to identity problem clients and being able to say no to them in my opinion is one of the most valuable skills to attain. Not only for your sanity but also your success.

newnewpdro 8y ago
Learning to say no and set boundaries in general is a life skill, part of being an adult, and one many often never develop.

iceninenines 8y ago

I've been doing client-facing Fortune 500 and startup tech consulting for about 30 years. If you're good, be choosey about clients and only work with the ones who will pay by the week, or preferably, by the milestone. You want to know your time is going to good use and that they're not going to get resentful or have any question about delivery. 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.

hobofan 8y ago

> https://news.ycombinator.com/item?id=4247615 https://news.ycombinator.com/item?id=4247615 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.

csa 8y ago
Solo consultants can and have successfully followed the advice in your linked post. patio11 is a seasoned HNer who has done this in a fairly public way.
- dennisgorelik 8y ago
  Patio11 is a full-time employee at Stripe. Please take his [no doubt interesting] recommendations about how to do consulting -- with a grain of salt.
  - grzm 8y ago
    'patio11 has been at Stripe for 2 1/2 years and was solo for many years preceding. I think his reputation is pretty solid, and have a hard time imagining how being fully employed at Stripe for the past couple of years should now make his past advice require seasoning. Have conditions changed so much recently? Would you care to expand on what you personally are concerned about (as opposed to vague aspersions)?
    - dennisgorelik 8y ago
      Prior to being a full-time employee at Stripe patio11 and tptacek tried to launch a startup [unsuccessfully]. 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.
  - 8y ago

jacquesm 8y ago

The HN consensus has simplified things in such a way that any shades of gray are tossed out. 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.

bermanoid 8y ago
I agree with all of this, but I'd warn that unless you really know what you're doing and what can go wrong, jumping from weekly billing to project billing can be super dangerous and you're taking on a lot of risk. Most people aren't great at locking in scope for projects, let alone estimating the work it will take once the scope is locked; once you agree to per-project billing, you've committed and are on the hook for errors on both fronts.
j1elo 8y ago
I don't understand this comment as a response to your parent one. The condensed bullet point that it linked shows that dropping hourly rates wouldn't happen until step 5. As I understand it, all you describe would fall under the period of time one takes to get through 1-4
lukego 8y ago
Having any rate helps to do algebra too. Clients can suppose that $x/hour ~= $8x/day ~= $40x/week ~= $1760x/year. So even if you quote an hourly rate the discussion can still be "how much should we budget for a team of ten people next year." Maybe the correlation between hourly billing and bad projects is not causal.
pasta 8y ago
To add: you can even charge by the hour in blocks of 4 if you feel more like it. 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.