However, I think the big takeaway is realizing that the formula presented establishes a minimum threshold. It shouldn't be used to figure out what you charge. My rates are way north of what the a developer/marketer would command on the open market, but I don't contextualize my costs against the equivalent costs of an employee; instead, I anchor my costs against the upside that a successful delivery of a project would yield for my client.
The single best way to substantially make more money consulting is to stop selling commodity services (web design, Ruby programming, whatever), and to truly consult. Provide your clients with a way to bridge the problem they face with the solution they desire, and charge accordingly.
The engineer in me would have immediately jumped into "OK, how do I migrate this database into Rails and recreate the functionality and UI of this app?" I would have priced the going rate for web development, and tried to gauge how long it would take to complete.
The business owner in me realized that this app is critical to their business. It's the tool they use to manage and close sales, and about 20ish people use it all day, every day. I also knew that the CEO was currently the maintainer of the app, as it was started when the company was a home business and the owner picked up a "Learn MS Access in 21 Days" book.
Knowing this, I went to work learning how I could not only modernize the product by making it web based, but I wanted to leverage my experience in usability to optimize how their team uses the app. How can we not just rewrite the app, but also optimize it? Is there a clear path to adding an hour or so a day of additional productivity per employee, and what would 100 hours of combined additional productivity a week mean (financially) for the business? And how much better would it be if the CEO of this small company wasn't needing to maintain the app himself, but could focus on what he does best — growing his company?
What I sold wasn't software or a rewrite. I ended up selling a better tomorrow for his business, and a more profitable tomorrow. This "decommoditized" what I was doing, and while he paid me a premium, he received a much better product at the end of the day.
n.b. That's how good business owners will look at this transaction: in terms of ROI. Sure this client paid a lot of money, but it was an investment in his company. It paid off. When you start framing offers like this, you don't have to feel bad about the price you'd like to charge because both parties come out further ahead.
Edit: Of interest to HN, I had a conversation with a business-owner friend of mine earlier this week. In trying to come up with a business ideas, I'd asked her if there was any software she hated using. This sparked an interesting conversation. When we got to the discussion about pricing, I asked:
"How much would you pay for something like this? $500 a year?" Her response was, and I quote: "I would do it on a monthly basis. Anything between 20-49/month is easy to sell. People <I think she means business owners here> don't even notice it."
tl;dr When you save a company money or time, they will hand you money accordingly.
I consider that the term "consultant" is used to freely and most of the time clients advertise that they are looking to hire a consultant when they actually want to hire a freelance developer.
If you want to work with them as "life support" for your practice while you figure out how to find the (innumerable) real clients that pay for business value, fine. But don't kid yourself. Call them "life support", not "clients". And just like a ventilator, staying engaged with life support is going to screw you up.
You cannot, cannot, cannot earn true market rates if your default position on incoming prospective business is "yes". You're going to say "no" a lot, and you're going to hear "no" a lot.
Fear of "no" costs more tech consultants more money than DOTA2 and Imgur ever will.
For some bizarre reason, "consultant" has taken on in common use a meaning approximately equivalent to "contractor", which has nothing to do with whether the work being contracted for is consulting or not.
Most consultants are contractors (whether they are also freelancers or not depends on whether they are individual contractors or are contracted firms), though there are some cases where internal employees job function includes consulting for some other internal group than the one to which they directly report.
But not all contractors (freelance or otherwise) are contracted to consult, and those that aren't contracted to consult shouldn't be called "consultants", in the same way that people that are contracted exclusively for tasks (including consulting) that don't include developing software shouldn't be called "software developers".
Everyone working independent needs to think of the business value they're creating; they need to think about their services the way product managers think about Feature/Function/Benefit charts. We call the people who are good at this "consultants", even when most of what they actually do is (say) Rails apps.
Did you charge an hourly rate for your "consulting time", or did you charge a flat fee?
Here's a much better option than either. I'm sure it's not the best way either, but the fact that "what came off the top of my business partner's head" is so much better than hourly or fixed is a good indication of how bad hourly and fixed are.
Better than each is to stop valuing your time as "just" time. You'll never have those moments again.
Value your work product. Don't value your work effort, and definitely not your time.
Actually, don't value your work product. Figure out how your customer values your work product and charge that price.
Once you start to realize that your time is the most valuable thing you'll ever have and simultaneously completely worthless as a unit of currency, you'll begin to trade with what you have that is truly of value to the person actually paying the bill: that thing you haven't created yet.
So, know what makes you different, find the customers that value that work more, and set your price according to that.
Most of the businesses that I've dealt with are intimately familiar with the problem/objective, but really don't have much knowledge of what is required to get there. This is where the consulting part comes into play. Many times it's been as simple as "let's talk about what you're trying to accomplish here" and from that I am able to formulate a solution in my mind of how that can be solved with custom software (or in some cases, an out of the box tool). I make the recommendation, and boom, a sale is made.
This is where making the business case for what the client stands to make comes into play and why what another developer might charge is highly irrelevant. If you can convince a business owner that he'll make $100,000 with your solution, convincing him to pay you $30,000 is not too difficult, regardless of whether he could technically find a high-school student who would do it for $15/hour.
To me, the key word is trust. Once you prove that you have good ideas and know how to execute on them, making sales is really more about just repeating the process than undercutting the competition. It goes without saying that you must deliver, though.
Another way of differentiation is to take stock of what you provide over and above basic work. That is, not to differentiate from any perceived competitors, but from what the client thinks you're doing (their perception of your role to them). If they think you're just doing web development, but also rely on or defer to you for system administration, UX/design, content, and/or hosting decisions, et al, those are all things that comprise your value. This is a roundabout of repeating tptacek's elements-of-value lists linked elsewhere in these threads.
Well, good for you - but I don't think it has much to do with freelance web development! (the 'commodity' you mention).
In particular, what makes you think OP could do the same?
Figure out WHY a project's being commissioned and then propose what your clients actually care about (hint: not code), vs. doing the usual "here's a proposal with a bunch of technical line items, a quote, timeline, and a signature field"
What I'm saying is that it is not quite fair to assume that every 'freelance programmer' (OP or your readers) can do that to the extent that you can. Business requirements analysis is simply a different skill from programming.
Consider the example where the person buying your services is on to your pricing strategy, and misrepresents the value of the business downward (or hides it from you), so that you are left only with the process but no good idea of the value of it.
Can you still do your business analysis, and price it as you suggest? Not nearly as well. Even though as far as code goes, you could still write all of it.
So I would say that what you advocate goes well beyond the idea of a freelance programmer, to include aspects of a business consultant. (Finally, really good proof of this is that in some cases you may well be able to hand off the actual coding to someone who will follow your instructions at a low hourly rate. The fact that this is even a possibility suggests that the value you're describing and capturing may not be in the specific programming at all, but a different layer entirely.)
This isn't theoretical. Lots of people on HN execute this strategy successfully.