I do some consulting on the side and I won't charge by the hour if I can avoid it because:
1) I hate keeping track of time.
2) hourly rates aren't how my customers think of the issue. They think: "this product will make (or save) me $20,000/year" (making up numbers here). If I tell them that I can do the job for $5,000, that sounds like a great deal to them. But if I tell them I can do it for $200/hour, and I estimate it will take me 20/hours, then I just look like an expensive consultant. Notice that in the first scenario, I made more money and still seem cheaper.
Yes, I've noticed this too... Many people have a visceral reaction to high hourly rates and never actually compare it to the value delivered. I think it's for a couple of reasons:
1) The average person gets paid $27/hour. Even the average software dev gets only ~$50/hour. Since many people interact with people getting paid around this amount, they see high rates as greedy/outrageous. Less likely to get this reaction from clients that are used to interacting with other high pay/skilled work. If you give them a flat rate, they get imagine you’re putting in more hours.
2) If they don't have extensive experience working in the space, I think there's a belief that someone cheaper will deliver the same value.. because they don't understand the variation in skill among those in the same field. Especially in a field like software development, and the client comes from a field that's more structured and slower changing (which is most fields).
There's also a delivery risk that could increase the bill substantially.. but it seems to me that there's more to the reaction than just analyzing the risk and value.
Agree. And on top of this, there's a value to predictability. If I go to my boss and ask permission to spend $10,000 to save $20,000, they can OK that pretty easily since it's simple math... they spend money and save more, so the purchase makes sense. When I go to them and say I want to hire a consultant for $200/hour in order to do a project that'll save $20k, suddenly the math is more complicated... how many hours is this person going to work? What if they go over? People pay more for assurance and predictability.
I had this argument with the CTO of a startup I worked for a while back. We had previous experience with a contractor that did great work, but charged the going rate for great work. We had a new job that required the same skill set, and the CTO wanted to shop around for a 'better value'. It blew my mind that he didn't see the previous guy as a good value. Instead he wanted to risk going with someone unknown, not the guy we knew did quality work. Luckily all of the development team was in agreement, and we convinced him that the guy actually was worth what he charged.
I think charging a $27/hour is quite low. That might be what an employee gets but they're going to get billed out at 3x that. A client sees like 75/hr for that 27/hr employee and doesn't have any idea of what their take home pay is.
200/hr for an independent consultant is someone making ~130k annually. It's a lot but not insane.
I explicitly do hourly when working on the side because of the lower overhead on my end to manage the process. As long as the trust is there on both sides, its a much more pleasant relationship to manage. The client is never going to be surprised by my hours (because I've given a gut estimate and am communicating as we go), and we never have to worry about horse trading for scope. If requirements change we just do the new thing and don't even worry about it.
I will caveat that I also generally enter long term retainer style agreements (though I dont usually structure them as a proper retainer) to handle various issues rather than fixed projects per-se. Things like "we want to scale up and dont know how" or "we are growing and need a hired gun to handle a broad spectrum of miscellaneous requests". Scope is a lot more nebulous in the first place for these.
Isn't the incentive structure for hourly completely ass-backwards? If you're a consultant there is an implied information assymetry - the client doesn't know what you are doing and has a hard time judging the amount of work required/being done. How do you handle the inherent and justified suspicion of padding billable hours?
I just can't charge hourly because I just can't imagine trusting someone who charges hourly.
Thats what I mean when I say "as long as the trust is there on both sides". They trust that I'm honest and don't sandbag work, and I trust that they aren't going to ask for an itemized breakdown of my time. I keep a very coarse ledger of time and what I worked on, but the invoices are generally just a line item of
"Development: 30 hours"
Again, nothing is a surprise in my relationships because we constantly are in communication, and I've raised issues with them beforehand if anything comes up / diverges.
you nailed it, it’s about trust. i’ve had a couple clients for 9 years, all hourly, and never had an issue. i’ve had 20 or so clients that this didn’t work and one of us fired the other, most of the time amicably.
As the other commenter says, a retainer agreement for a "block" of time is common, but again for simplicity sake I just do it on the fly and we keep each other in the loop. They keep me informed of current/future things that are coming up and I keep them informed of sizing estimates (e.g. "thats simple", "thats pretty involved", "we should hold off on that and have a discussion to see if we can solve it with a hack then reevaluate")
billing weekly for things like this i’ve found works nicely. they basically get everything you got for a week. still requires some level of trust, and understanding of the work by the client.
Genuinely curious, how do you mitigate scope creep when you charge by product? What stops the client from pushing back when there's a bug in the future or feature request they think should have been included?
In the past, I have always only charged for the entire project all at once instead of by the hour.
Main trick to mitigating feature crap I have used is by first I add extra padding to cost.
Second i tell my clients that I provide free maintenance for 2 weeks after the project si delivered. Mostly this helps because clients want speed over reliability. So we push and the next two weeks is bug fixing - sometimes it's three.
However no matter what happens I would never build a new feature in the maintenance period
I do this very much part time and with recurring clients so I don't have a great generalizable answer. But for me, I charge a fixed price and then it's on me if there are bugs (actually, the incentives are nicely aligned here. Fewer bugs means less work for me and less hassle for my clients). As far as feature requests, I will throw in small things for free, even if not agreed upon. The assumption that I'll need to do extra little things here and there is built into my rate.
For bigger things, it's important that expectations are set upfront and are clear to everyone. That way, if someone wants a new feature, they can have it for a price.
Draw clear boundaries up front - "This is in scope, this is out of scope" - and make it an itemized list if possible.
First, it pushes that conversation to the beginning and can make it negotiable. Then it reduces surprises throughout. And finally, it gives you the ability to say "No, we agreed to.." when you need.
You agree on a very explicit set of deliverables upfront. Whenever the client attempts feature creep simply tell them that it's gonna cost extra time for you and extra money for them. If they persist give them a quote for it.
You have to be willing to lose clients is the real answer. They try to get you to do some extra bullshit not in the brief, you say no / offer a quote. If that doesn't sit well with them, so be it.
It's a good argument for specialization. If your job is "I design web apps" then it's gonna be new and unpredictable work every time. If your job is "I do software consulting for small businesses to migrate from excel to quickbooks, or quickbooks to an ERP", then you'll probably have a lot of reusable code and making predictions will be easier. Furthermore, you can probably do a better job in 10 hours than what someone else might take 30 hours to do. And the customer wins out too since they have quicker turnaround time and battle tested code/processes.
There is a benefit to specialisation but I think your example of migrations probably isn't a good one. Those projects have a tendency to stretch out because you can rarely get a handle on the data. The customer will tell you they've given you everything then a week later start complaining about something you haven't seen (but is still your problem).
Of course you could argue this needs to be tied down before you start work but often this is the bulk of the work. Even if you did get something in writing it's turned into an adversarial relationship once you start refusing work or demanding more money.
I hire freelancers sometimes and this is exactly right. We agree on scope, price, and timeline. Helps me budget, helps you know when the project is done.
Hourly fills me with dread as a client. I have no idea how much this is gonna cost or when you’ll be done and I can use it.
Retainers work well for ongoing work. Like when you need someone to do X, Y, and Z misc tasks every week.
Fundamentally I pay for results, time is an implementation detail. Why should I care how long it takes you?
As a freelancer, I honestly prefer charging hourly / daily / weekly. The type of project I do tends to have an ever-expanding scope.
Charging by project would put me in an adversarial position with my client; I'd be forced to always push back when the scope / situation changes.
By contrast, charging by the hour lets me say yes much more often.
Of course, if I were to do more "turn-key" projects, scope would be much more predictable so it'd probably make a lot more sense to charge per-project.
If you've hired someone who doesn't know how to predict how long the project will take and they suddenly stop development midway through, it is probably also your problem.
> Imagine paying someone an extra $10,000 because they missed the deadline. That’s how hourly works.
Yes it is.
You should probably ensure you only hire people who have experience predicting the costs of the projects you hire them for.
There is no way to know ahead of time what kind of contractor you are. And if you're not making an active effort to bill as much as humanly possible for the minimum amount of actual work, you are bad at business.
I won't go into details, but my experience from the past year of trying to minimize the chances of losing my home and work visa has provided ample evidence that this also applies to human mental health.
> There is no way to know ahead of time what kind of contractor you are.
Which is why any strategy that resembles "fire and forget" is a poor one for anything that hasn't been repeatedly tested before with mostly the same components.
It's better to have a process where you repeatedly get visibility into a risk than to imagine that you can wall yourself off from it.
Unfortunately, without having done the same job, it's hard to evaluate the time, even if you pad. And for lots of complex jobs you have skeleton in the closet, meetings upon meetings, extra management to contact for approval.
I'd rather charge by day/week to discourage those unproductive things and have the company get its act together in terms of scope/approvals so that there is no blocker (or they get expensive).
You might (think) you know how long it will take you; we don't. We don't even know if you're being honest, or deliberately underestimating/overcharging for work. Because an hourly rate means you have every incentive to do so.
A relationship without well-founded trust is often a worse alternative to no relationship at all.
* A contractor who insists on an hourly rate for a project with unknown timeline does himself and the client the favor of killing the deal.
* A client who insists on a total-cost pricing for a project they need budget-certainty on does himself and the contractor the favor of killing the deal.
The work I do is fairly specialized and takes me a relatively predictable number of hours. Sometimes I'm wrong and it takes me more, but a good amount of unpredictability is baked into my charge.
If you charge more for a fixed cost, then it doesn't really matter if you are off 3x one time. Yes, it's annoying, but you make up for it with the majority of times where you work the estimated number. If you are consistently underestimating, then you need to up your estimates.
1) I hate keeping track of time.
2) hourly rates aren't how my customers think of the issue. They think: "this product will make (or save) me $20,000/year" (making up numbers here). If I tell them that I can do the job for $5,000, that sounds like a great deal to them. But if I tell them I can do it for $200/hour, and I estimate it will take me 20/hours, then I just look like an expensive consultant. Notice that in the first scenario, I made more money and still seem cheaper.