[deleted]
How I learned to charge my customers
11–20 of 85 posts
Re: How I learned to charge my customers
#12I 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 estimat…
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, tim…
If you are hiring someone who does not know how to tell how long it will take them.
Re: How I learned to charge my customers
#13Those rates seem low. 20 years ago consultancies were charging $150/hr + materials. Their employees might see $30-50 depending on how much unallocated time they had. For a solo, the average including down time (sales) could reach $80-100, charging that same $150 to the clients. Have rates fallen so far?
People are trying to pay minimum wage or below, always have always will. That’s why I’m unemployed.
Re: How I learned to charge my customers
#14Very interesting that the author doesn't address outcome-based pricing. The rule of thumb I use is 10% of total value - if it's less than I want to make, I decline. It doesn't make sense for them to pay me, so it doesn't make sense for me to work. "Urgency" strikes me so much less compelling of a pricing conversation, but I guess it works.
So if you help someone build a $3M empire the fee would leave them with $2.7M ? Not bad. Seems to be a more astute way to charge for services rendered because the client will actually have revenue to pay you, and the cost/benefit is fairly clear from the get-go. Do you typically both [client and creator] agree on how much value the work will bring in, and is it based on time? (This much in the first year, etc)
Re: How I learned to charge my customers
#15I 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 estimat…
I've done a few fixed price jobs but only where the scope was very narrow and well defined and I had done something very similar before. In general though my experience is most customers won't know what they want until you put something in front of them. I've also found that the more they push you for a fixed price the more likely they will be causing problems down the road.
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.
Re: How I learned to charge my customers
#16I 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 estimat…
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.
Re: How I learned to charge my customers
#17Earlier quoted context omitted.
I've done a few fixed price jobs but only where the scope was very narrow and well defined and I had done something very similar before. In general though my experience is most customers won't know what they want until you put something in front of them. I've also found that the more they push you for a fixed price the more likely they will be causing problems down the road.
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 someo…
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.
Re: How I learned to charge my customers
#18I 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 estimat…
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
Re: How I learned to charge my customers
#19That explains why all the recruiters on LinkedIn are trying to low-ball me so much. The actual rate they charge is double!
Re: How I learned to charge my customers
#20I 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 estimat…
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?
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.
Nothing is perfect but it mitigates some risk.