How Much to Charge as a Freelancer: Why Almost Everyone Gets it Wrong

“How much should I charge as a freelance designer/developer/programmer?”

This is one of the most commonly asked questions by freelancers (both newbies and veterans alike.) Well-meaning responses posted on messageboards often include a link to one of several online calculators. The inputs include questions like “how much is your monthly Internet bill?” and “How many vacation days do you take each year?” The final question on the of most popular of these calculators is “How much profit do you want?” What a curious question… For anyone trying to grow a business, there is only one correct answer: As much as possible. These pricing tools are broken at a basic level because they’re asking the wrong questions.

The most valuable class I ever took in college was ECON 101. It fundamentally changed the way I viewed business and has had lasting influence on how I make decisions. One of the lessons that has stuck with me is that the price of something has almost nothing to do with it’s cost. Neither the cost of a beef patty or the hourly wage of the cashier affects what McDonald’s charges for a Big Mac. What matters is the price of the Whopper down the street and what a customer is willing to pay to avoid having to pack his own lunch. Businesses seek to maximize revenue; they will always charge what the market will bear, regardless of the product cost. The price the market is willing to pay is a function of the available alternatives.

Quite simply, your clients don’t care what you pay for Internet access so it has no bearing on what you can charge them. Your overhead does affect how much money you have leftover at the end of the month (profit). It’s important to be mindful of costs, but they don’t belong on a spreadsheet used to figure an hourly rate.

The problem with the question “how much profit do you want?” is that getting the answer wrong means that you’re either undercharging (thus missing out on income) or overcharging (and losing business you could profitably undertake). And, unfortunately, there’s no way to arrive at the correct answer by examining your costs.

Getting to the right answer

Figuring out how much to charge as a freelancer means understanding the price of the client’s alternatives. This tends to be more of an art than a science, thus does not neatly fit into an online calculator—and “price” isn’t always purely dollars. There’a IBM WebSphere partner here in Michigan that bills $750/hr for what is largely Java development. Yet, I can find someone similarly skilled via ODesk.com for less than $40/hr. Additionally, anyone who has been in the business for even a short amount of time knows that talent has very little to do with how much you earn. So, your costs and your skills have nearly no influence on your income as a freelancer. What gives? The two most important factors to consider are: a) the size of your client and b) the probable value of your work.

Size matters

The size of a client affects their buying decisions and what rate they’re willing to pay. Starting a business is a very risky endeavor, thus when talking directly to a small business owner, buyers tend to be very risk-tolerant people. They’re also being persuaded to part with their own, personal money. Most small business owners are willing to tolerate a higher risk of project failure in order to save on costs. For freelancers just starting out, this is why smaller clients are ideal: as someone with an unproven track record, it’s an easier sale if the price is right.

Larger businesses operate very differently. They tend to be more sophisticated buyers who are working with an allocated budget. Their primary concern is ensuring that a project is done correctly and on-time because its a component of a much larger initiative or strategy. The decision makers are often much more risk-averse than small business owners because it’s their reputation on-the-line, not their own pocketbook. Freelancers with a roster of proven successes can frequently charge larger businesses an hourly rate matching those of a well-paid lawyer, yet would struggle to get a fraction of that from a smaller client for very similar work. People who provide social marketing or online lead generation services often see this massive divide in rates.

Quantify your value

We tripled pageviews and increased annual sales by more than $1.2 million dollars.

This is a pretty powerful statement that is listed directly on my company’s website. It was the result of work we did over a few months for a client that dramatically increased the SEO of a SaaS application and streamlined some e-commerce operations. Unlike a typical portfolio piece, I don’t have a screenshot of the client’s website (which we didn’t design anyhow), I instead explicitly quantify the value of our work. Crunching the numbers takes a whole lot of guesswork out of figuring out what a similar client might be willing to pay for similar services. I highly recommend that this process be done after the completion of every project.

While it does get simpler with hard numbers, there’s no magic formula because it depends on the size of the prospective client, the size of the opportunity, and a multitude of other variables. Most importantly though, it’s dependant upon your ability to communicate the value of your services. In other words, your ability to sell yourself is one of the most important factors in determining what you can charge as a freelancer. For the readers who’d rather gouge out an eye with a spoon than consider themselves a “sales person,” this sounds like a raw deal. However, it’s not all that scary once you really understand what “sales” actually entails. Most technical people have the potential to be way better at sales than they realize. I will expand upon this topic in a future article (follow me on Twitter and stay tuned.)

Where to start

Okay. What if you’re a new freelancer and don’t yet have any proven, quantifiable successes? Where do you start? Return to considering the price of the client’s alternatives. Predictably, this would include the rates other freelancers in your industry. But a common mistake is to confuse your alternatives with the client’s alternatives. If a small web design client doesn’t know about oDesk.com (and wouldn’t consider it even if she did), then you don’t have to pay mind to price of your competitors there. US-based workers frequently complain about the prices their Indian counterparts charge via the online marketplaces. However, unless both people are bidding on the same jobs posted on these sites, they are not direct competitors.

Alright, alright… a lot of readers are going to be disappointed if they’ve read to the end I never lay out exactly how to figure out how much to charge as a freelancer. Here is what I’d recommend if you’re starting from zero:

  1. Ask around and get five rates for competitors. Match them as closely to you as possible: age, years of experience, location, size of past clients, portfolio, etc. This is going to require a bit of legwork and feeling like you’re being nosey. Do it anyhow.
  2. Drop the highest and lowest hourly rates, average the three remaining and reduce by 10%. This will put you on the slightly cheaper side of the average.
  3. Continue to charge this rate as until you get too busy. Getting “too busy” can be tough to spot from down in the weeds. It generally manifests itself as feeling overwhelmed, not caring about your work as much as you used to, and increased irritability with clients.
  4. Increase your rates by 10% on existing clients and 20% on new clients. This should slow the stream of work coming in. You want to occasionally hear “you’re too expensive.” If you never hear that, keep raising your rates until you are. If you always hear it, reduce your rates (slightly).
  5. Rinse and repeat until you have enough quantifiable successes that you can use the more sophisticated, “value add” method of determining what your services are worth.

Your mileage will likely vary. Keep a close eye on your market and make sure you’re listening to clients. Good luck to you.

Share

Tips for Passing Amazon’s New AWS Certified Solutions Architect Exam

Today I decided to take Amazon’s new AWS Certified Solutions Architect certification exam. The exam is 55 multiple choice questions with a time limit of 80 minutes and a minimum passing score of 65%. I completed it in about 35 minutes with 85% of questions answered correctly. I went into the exam cold, without any preparation, because I wanted an honest assessment my knowledge. It actually surprised how challenging I found it to be–it’s a really good, comprehensive exam.

What I appreciated most about the exam is that there weren’t any “gotcha” or filler questions like: “How many Compute Units does a m1.medium instance have?” or “What is the proper syntax for configuring an auto-scaling group using the command line tools?” The exam was obviously authored by someone who has real world experience working with AWS and not just combing through the online docs looking for factoids. This is a worthwhile credential to have on your resume and for hiring managers to consider.

Some key items you should know before you take the exam:

  • how to configure and troubleshoot a VPC inside and out, including basic IP subnetting. VPC is arguably one of the more complex components of AWS and you cannot pass this exam without a thorough understanding of it.
  • the difference in use cases between Simple Workflow (SWF), Simple Queue Services (SQS), and Simple Notification Services (SNS).
  • how an Elastic Load Balancer (ELB) interacts with auto-scaling groups in a high-availability deployment.
  • how to properly secure a S3 bucket in different usage scenarios
  • when it would be appropriate to use either EBS-backed or ephemeral instances.
  • a basic understanding of CloudFormation.
  • how to properly use various EBS volume configurations and snapshots to optimize I/O performance and data durability.
Share

Serving compressed (gzipped) static files from Amazon S3 or CloudFront

It’s generally a good idea to serve gzipped versions of plain-text static assets (primarily CSS and JavaScript files) to web browsers. This can significantly reduce file size, which increases perceived website speed. All modern web browsers can transparently decompress gzipped files, thus the only real downside is a bit of additional CPU overhead.

Most default installations of Apache take care of this automatically via mod_deflate (Nginx uses the equivalent HttpGzipModule). Files are compressed on-the-fly and a Content-Encoding: gzip HTTP header is added to the response. However, since Amazon S3 is just a place to store files it lacks the ability to gzip files in real-time before delivering them. When using a website speed test application like WebPageTest, this can result in informational warnings that look like this:

Use gzip compression for transferring compressable responses: 90/100
FAILED - (52.1 KB, compressed = 40.6 KB - savings of 11.5 KB) - http://mybucket.s3.amazonaws.com/css/awesomeness.css

To resolve this, files have to be compressed before being uploaded to S3. From Linux or OSX, this can be easily done with gzip -9 awesomeness.css, which creates a new, compressed version of “awesomeness.css.”

This new file is then uploaded to S3 and the following metadata is set on the bucket object:

Setting content-encoding and content-type on S3 bucket objects

The Content-Type header informs the web browser that the actual contents of the file is CSS markup while Content-Encoding specifies that it’s a gzipped file. Both HTTP headers (“metadata” in AWS-speak) are required for the browser to correctly interprete the file.

Gettin’ fancy

Manually gzipping each file and setting the correct metadata can get very tedious, very quickly. I would recommend that this process be automated as a build step on a continuous integration (CI) server (at RBN we use Jenkins): a post-commit hook on the source repository fires, triggering a build. The CI server performs a SVN export or Git clone, executes a shell script that gzips the files, and uploads them to S3 and sets the proper object metadata. If you’re not currently using CI in your development workflow, a more basic version of this process can be hacked together using only commit hooks. Though I would argue that this would be an opportune time to dip your toes into continuous integration.

Share