Hacker News new | comments | show | ask | jobs | submit login

Justifying your costs by basing what you charge against the costs of a similar employee is a good start, and in my experience it's how most of us start (the old "divide by 2000" trick). I like that Andy makes note that you need to include overhead (prospecting, writing proposals, ...), which a lot of new freelancers tend to miss.

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.




Bingo. Thanks, Brennan. Part of the epiphany I had was "wow, I did a lot more than programming on that project". I managed it, taught other developers, and "consulted" quite a bit. I also read your book right before I had this moment. I hadn't quite bought into it yet, but this was the first step.


Can you give an actual example of some problem that one of your clients had and how did you consult him/her?


Sure. So I had a client who wanted us to rewrite their 10 year old MS Access app as a web app.

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.


> While he paid me a premium, he received a much better prodcut

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.


This makes sense, but unfortunately not all clients are inclined into accepting propositions like these. Some clients do the research and design internally and then they hire a "consultant" to do the development part of the project.

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.


THOSE PEOPLE AREN'T YOUR CLIENTS.

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.


> 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.

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.


I really think the idea that "consulting" is some special thing that "contractors" and "freelancers" can't do is harmful. In the sense we all mean it, "consulting" just means "being smart about what services you provide and at what price". It's the equivalent of product management in a product company. If you're serious about being independent, you have to do it. Now.


> I really think the idea that "consulting" is some special thing that "contractors" and "freelancers" can't do is harmful.

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".


See, now I think you're using the term in a subtly different way than Brennan is. Brennan couldn't have sold that Access to Web conversion deal as a pure consulting project, in the Arthur Anderson "split up implementation and consulting" sense of the term.

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.


Interesting. What do you do if the client is not interested the value-add but only in a rewrite for the web, say? Decline the project?


Sounds like their only goal is the rewrite which is in and of itself valuable.


Thanks for the great example.

Did you charge an hourly rate for your "consulting time", or did you charge a flat fee?


Those aren't the only two options. In fact: they are both bad options!

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.

https://news.ycombinator.com/item?id=7850335


Charging by the day is better than charging by the hour, and week is better than day.

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.


I was going to bookmark the linked comment, and found that I had in fact already done so. It is a very useful, actionable piece of advice. Thanks for writing it.


I bill by the week. At the time, my agency rate on this project was $10k a week, which included the full time attention of a senior developer (~4 full days), plus part time Q&A and PM oversight.


I bill by the week

<3


Also, I think there is a lot of focus on pricing (fair, it was the point of the article). But you simply need to back it up with what is your differentiator. It's just like any product: you need to be articulate as to why you cost your rate, and also have an idea of the value of your work to customers (different customers value the same work differently).

So, know what makes you different, find the customers that value that work more, and set your price according to that.


In my experience, differentiating from competition wasn't really a factor in how much I charged or how much I made. For a lot of businesses that would hire a solo consultant, there is no consideration of the competition.

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.


I am currently struggling with a method to raise my rate with a current client and your comment has crystallized the problem I've been having in writing the email, but not the way you think.

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.


Sounds like, "Actually I take the idea of a 'rate' off the table, by becoming an equity cofounder with a cliff, and leveraging my connections at fortune 500 companies to sell the entire company for $60 million. This nets me about $20M based on the way I structure my contract, and takes approximately 800 days of work, so that works out to about $25,000 per day or something like $3125 per hour. Really, if the business is in a big market with good growth and good margins and some kind of proprietary lock-in or moat, $60M is quite a reasonable figure for many Fortune 500 companies to acquire for. Then I just make whatever needs to happen for that to happen, happen."

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?


It has everything to do with freelance web development, because I (a 1099'd freelancer) am still doing web development. I've just come to realize that clients don't pay me for lines of code, therefore I don't sell lines of code :-)

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"


In my fictitious example if you're still personally coding the things that need to happen, then by your argument you're still a "programmer", just one who is earning $3000 per hour. (Which certainly stretches the meaning of the term.)

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.)


Real clients don't do this, but it wouldn't matter if it did. When a prospect values your services too low, you simply say "no" to them. It's called "deal qualification", and it's a Sales 101 skill. Your job is to find the clients who value what you're doing enough to be worth working for.

This isn't theoretical. Lots of people on HN execute this strategy successfully.


Thomas, and do you think "freelancer" is how they should title themselves? It's not so much about increasing your negotiating skills and rate 'as a freelancer' but expanding what you're doing so that it's quite a poor title at that point.


A great comparison is the patio11 story about the expensive engagement ring vs extended honeymoon. If you can see what your clients care about, you can provide much greater value to those client (and have them write what seems like a ridiculously large cheque without even thinking about it) vs just delivering what they say they want without considering the larger picture.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: