51–60 of 137 posts
Billing hourly is bad, but you don't have to give up time & materials billing altogether. Just charge a day rate, or a weekly rate.
I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
I charge by the hour and will never change. It forces the customer to focus on getting the requirements right instead of hand waving it like "oh yeah, that's just what I want" and then come back later "I didn't want that, what I meant was" repeat ad infinitum. You see they are paying for my time, not results. If they choose to waste it... doesn't matter to me, it's all billable just the same. I will do my best to ste…
The other place I disagree strongly with the author is about the utility of flat-rate projects. I've had good luck with flat rate, but it was never the project structure we'd have used by default. Rather: for any project we did, we'd have quoted a full project, broken out into billable weeks, with a final sticker price and a paragraph below the pricing table with "additional work needed will be billed at our pro rata day rate".
I think the attitude that says "all the risk should be borne by the client, not the struggling independent consultant" is bad business (for high-end tech consulting, you should start seeing your practice as being in part in the risk mitigation business!), but that doesn't mean you need to take on extra risk just for the hell of it.
That said, there are clients who are so valuable, because they're going to be repeat-business house accounts or because their reputation is so strong that they'll bring in word of mouth business automatically, that you should definitely consider just doing flat rate projects for (if that's what they want) and just eat the overages.
Professional business people are familiar with different business models, and when to apply them. For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk. Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. Being a pr…
What about fixed price makes the client happy in this situation? It's definitely not the fact that the contractor billed "waaay more than hourly".
The upside of fixed price is that it's more predictable and it aligns incentives. With hourly, the hidden incentive is to take as long as you can get away with because every additional hour you take is an additional hour you can bill.
With fixed price, the contractor has an incentive to finish earlier.
That's the part that I find many contractors miss: They treat fixed price as an opportunity to extract more money from the customer. As someone who has been on both sides of this (I've been a contractor and I've also hired a lot of contractors) I lose trust quickly when I spot contractors inflating fixed price bids because they think I won't be able to recognize what they're doing.
Well, I found this article insightful, even if I've no plans of going freelancer (though of course... "life, uh, finds a way", so who knows). I think my most immediate objection is one that is raised in the comments from TFA: customers don't know what they want. For a flat rate to apply, you have to work to an initial set of requirements set in stone, and we know these requirements are almost always wrong (except for…
It's not always like this. I've used contractors to take on extra work that we were familiar with, but didn't have time for. We knew exactly what we want because we'd done it multiple times before and had already written a clear spec.
The eye-opening thing was that this actually scared a lot of fixed-bid contractors away. As soon as they realized that we knew the task and had the option of doing it internally (on a longer timeframe) they became less interested in working with us.
When I started playing dumb and pretending like we didn't have the experience in-house, I got some wiiild bids for how long it would take. Some of the contract shops who had clearly done this before tried to pretend that we were doing something new and novel that would require a lot of R&D.
It was a very disappointing experience. Once of the worst contract shops was even the recommended support partner from one of our vendors.
Earlier quoted context omitted.
> when the client has a specific, measurable problem that they don’t know how to fix (but you do) Then the client tells you that wasn't their problem in the first place. In the 10 years of contracting I've never done fixed rate for the reason the client never knows what they exactly want. It's not like installing a tiled floor or drop ceiling. Being a professional means a lot of things, but fixed rate contracting is…
Which is why you have clear boxes on that fixed-rate, and stepping over those bounds means you're back into T&M billable. The legalese on these contracts needs to be quite tight, but it's a one-time expense to set that up, and it's best done properly (and updated as new edge cases show up).
That being said you need a good spec to do this, and that definitely isn't normally the case in software.
Earlier quoted context omitted.
I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
In one case, you bill for each hour you work; in another, you bill for any day in which you did work.
It seems to me there's no fundamental difference for the context of this article; it's still flat rate vs unit-of-time based work, isn't it?
Professional business people are familiar with different business models, and when to apply them. For instance, hourly billing makes a lot of sense if the scope is vague - the client carries the scope risk. Fixed price is amazing when the client has a specific, measurable problem that they don’t know how to fix (but you do). You can solve it cheaply, get paid waaay more than hourly and have a happy client. Being a pr…
Earlier quoted context omitted.
I'm genuinely curious: what is the difference between hourly and daily/weekly rates?
Mostly that you don’t have to haggle over hours or 30mins here or there. If you do daily or weekly you don’t register time in 15mins increments to later argue with the client.
Earlier quoted context omitted.
In one case, you bill for each hour you work; in another, you bill for any day in which you did work.
Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? It seems to me there's no fundamental difference for the context of this article ; it's still flat rate vs unit-of-time based work, isn't it?
I've written a lot about this on Hacker News over the years; like, a lot a lot. Here's a starting point:
https://news.ycombinator.com/item?id=6105004
I don't think anybody in our field should ever be billing hourly. Day/week/month/quarter vs. flat rate? We can go back and forth on. Just don't do hourly.
This comment is I think too subtle to lead off with, but it's the essence of where I'm coming from on this:
https://news.ycombinator.com/item?id=4103207
(I have had some moderate success with this approach, which makes this a rare case in which my confidence in arguing something here has at least some colorable basis in reality.)