How I learned to charge my customers
idiallo.com
How I learned to charge my customers
1–10 of 85 posts
Re: How I learned to charge my customers
#2Ahh yes I've charged $100/hr and I have gotten almost no work despite being both an engineer and programmer.
I can make half that with employment.
If I have a sales team, maybe we can split the $100/hr labor once I find a company willing.
Re: How I learned to charge my customers
#3Those 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?
Re: How I learned to charge my customers
#4I 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.
Re: How I learned to charge my customers
#5I 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, time is an implementation detail. Why should I care how long it takes you?
Re: How I learned to charge my customers
#6I 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…
This. Clear requirements/expectations in addition to concrete costs help reasonable people on both sides stay on the same page and avoid surprises.
Re: How I learned to charge my customers
#7I 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?
Re: How I learned to charge my customers
#8Very 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.
Re: How I learned to charge my customers
#9I 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.
Re: How I learned to charge my customers
#10I 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?
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.