Don't believe that shit. I worked through an agency once where I was the subcontractor for several projects. One time the account rep was lazy and sent me the customer's contract and failed to remove the rate he was charging for my work. I was charging $150/hr. He was charging the client $400/hr.
People will pay a premium for something they value. In that instance I actually won out eventually. It turns out the agency was really shitty at managing projects and that particular client got in touch with me directly. He agreed to pay me $400/hr if I gave him priority. I did, and he started referring me to other businesses who would also pay that rate.
So don't kid yourself about how much people will pay.
The naive answer I would have given at time was: "I'm a software developer who builds ecommerce and CMS sites."
And it's funny that you ask "What do you do?" At the time I had starting taking on projects from a friend who had been doing development contracting for about 4 years. One time when a client told me my proposal was priced too low and passed on my bid I was baffled.
I told my friend about it and he asked me the same question, and I gave the above answer more or less. He corrected me and said "No! You're businessman enabling a national sales channel for a local or regional business who wants to increase their revenue."
So never define your price by what you do, rather define it by what the value of thing is you're delivering to the client. This requires some research on your clients and a realignment of your thinking. When you're contracting as a developer, you have to start considering yourself as becoming a successful businessperson and not (just) a successful software engineer.
I started charing on a per week and per month basis, which was good because I stopped getting bothered with tiny projects.
Also I could choose how much hours per week I was willing to work, as long as the clients are happy they don't care if it took me 40 hours that week or 20. This also increased my effective per hour payment and my work life ballance.
It is also important to sell yourself with a higher value proposition. If you say "I'm a freelancing front-end dev who does JavaScript" they won't pay you as good as when you say "I'm a mobile consultant, who designs and implements apps", even if you do basically the same thing, people suddendly realize that you are a specialist and not some code monkey...
> And I'm not kidding myself. Most companies know they can get good devs for significantly less than 400/hr.
You can get a great dev for much, much less than $400/hr. You're right. However, should I charge less than that to do a few hours of work for you? Absolutely not.
If I'm doing a small project for a few hours for you I have to charge a lot to cover the business costs.
Yeah, the projects I'm pricing out are usually 200-1400/hrs. I can totally see that rate for smaller projects. I imagine utilization rates are a lot harder to keep high with work that granular.
Yes absolutely. If I have a client that's going to drop a thousand plus hours into the project they're getting charged a quarter of what someone who just needs me to log in once and a while gets charged.
I know there's an international tax lawyer in SF charging $1250 hour. If you want the big bucks, law's one of the places to get it (provided, presumably, you work hard and are very smart).
I think they mean that that's the estimated time allotted for the project. What they're implying is that they charge less because of it, but if they worked shorter projects, they would likely charge more.
At the beginning of my contracting career I neglected to think about all the time I'd spend on non-coding tasks. It wasn't insignificant. I also found that the 4x full-time hourly wage is about right. A few other things I learned:
Almost never take a fixed bid contract. They're pretty much always a net negative.
Give clients discounts for paying early. Everyone loves a discount. Never discount your hourly rate though, because once you do that once for a client they'll never stop arguing with you about it. There's a line on Schedule C for recording discounts.
If you turn over raw source code to a client, stress (in written, contractual form) that if any other contractor/employee changes the code, then you will charge them a premium rate for any changes or fixes.
Almost never take a fixed bid contract. They're pretty much always a net negative.
This is not the best approach, honestly.
No one would pay me the effective hourly rates that I make off fixed rate projects, and everyone is happy. Clients almost always prefer to know what they’re going to pay upfront.
Additionally, hourly seems simpler and low risk, but it’s all downside for you. If you’re way more efficient, you get penalized. But if it takes longer than your estimate, clients get pissed. At extremes, they may just refuse to pay. Tell a client your estimate is $10k and then try to bill $30k, tell me what happens :)
Just like value-based pricing, flat rate takes a bit more skill to learn, but it’s dramatically more profitable in the long run.
I did some fixed software dev contracts many years ago (1994-1995 time frame). I cobbed the agreements together myself and put in late penalties; as in, I get paid less for being late, with an increasing scale by the day.
In some industries, you cannot avoid flat pricing. E.g. bidding on any sort of construction or renovation project. You may have workers under you who work by the hour, but that's your problem.
The flip side of never taking a fixed bid contract is when it turns out someone really just didn't RTFM, and it takes you 15 minutes of real work to fix their problem. Thousands of dollars of benefit to them... and one billable hour to you.
Exactly. The most recent work I shipped was on a fixed-rate retainer. I based it on the value and not time. Internally, I knew how many hours it would take and was pleased with the ROI.
I only do fixed bid projects (plus expenses). In my experience, clients want to know up front what they'll be paying (or a very tight range, with expenses). Hourly, they get nervous they'll end up with The Never-ending Project, it's impact on their budget, and start haggling over hourly rate vs project value.
The last sentence strikes me as sort of old school and somewhat client-hostile. Unless you're working on an embedded system that will ship physically and never be opened again, your code is going to have to change--if for no other reason than to accommodate changes in the underlying technologies. This is especially true considering the libraries and dependencies that are baked into software projects today.
If a critical security patch requires a change in the code, your client is going to have to either change it themselves or get you on the job pronto... and do you really want to set the expectation that you will be available pronto, forever?
I think the days of write the code, launch, then ride off into the sunset are over. Code should be considered temporary and perishable, and IMO consultants should acknowledge that upfront and help their clients plan for it.
People will pay a premium for something they value. In that instance I actually won out eventually. It turns out the agency was really shitty at managing projects and that particular client got in touch with me directly. He agreed to pay me $400/hr if I gave him priority. I did, and he started referring me to other businesses who would also pay that rate.
So don't kid yourself about how much people will pay.
Edit: These clients weren't in the Bay Area.