Today I’d like to, once and for all, answer a question that I’ve been asked hundreds of times.
“Brennan, how should I bill my clients?”
Hourly, daily, weekly, monthly, per feature, per project. There seem to be a limitless number of ways to charge your clients. In this post, I’ll overview the pros and cons of each, and end with my recommendations.
The majority of American freelance developers and designers bill by the hour. At first, it seems like the most obvious way to do things… divide your former salary by 2000, inflate the result to compensate for the administrative, sales, and time-off overhead, and you’re good to go. And because you’re billing by the hour, if the client decides to change course midway through the project, you’re protected.
You’re pretty much a faucet; you can be turned on, and you can be turned off. When you’re plugged in to your keyboard (or telephone) and doing stuff for your client, the meters running. Every few weeks you sum up your time logs, multiply them by your rate, and send them over to your client.
- It’s normal. Clients who have hired freelancers in the past expect to pay by the hour.
- You get to charge whenever you’re on the phone, in a meeting, or tapping on your keyboard or mouse.
- You can take days off or work half days without getting into murky discussions like you might with, e.g., weekly billing contracts.
- You’re penalized for your experience. If you’re 2x faster than a more junior person, you’re billing half the time they are.
- Clients tend to like to comb through invoices, and aren’t usually happy to see “non valuable” entries like meetings or bug fixes / design tweaks.
- For sizable projects, it becomes very tricky to accurately gauge a realistic hourly estimate.
- You need to be vigilant in how you track time, lest you undercharge. (Though tools like Planscope are meant to make this much easier.)
Daily billing is a step up from hourly, in that you can start obscuring “how the sausage factory works.” Meaning: When you’re billing hourly, an itemized invoice usually lists out what got done. An hour of development, followed by an hour of meetings, and then maybe another hour sketching out concepts. To a client, this gives them direct exposure into how their product (more on this later) is being built, which can inadvertently encourage some to micromanage and breach the client <-> vendor relationship.
I first came across daily billing when I noticed that a lot of UK freelancers billed this way.
- You don’t need to track time. Just invoice based on days you work.
- You obfuscate exactly what happened during the day. The focus is on the results.
- You can reply to emails and jump on quick Skype calls on “off days” without your client fearing that this will appear front and center on their next invoice.
- It becomes awkward to, say, take the morning off for an appointment. Do you roll over that time to… tomorrow morning?
- Your client may need to be conditioned. Easily fixed: “I dedicate my attention on any given day to just one client. You don’t need to worry about the overhead of context switching.”
If you want to price off of value, and the project’s scope is loosely defined or in flux, weekly billing is your best friend. You’re able to obfuscate the details and get your clients to focus only on one thing: the value you’re delivering to their business. Note: All of the highest rate consultants I know — those with an effective rate of $500-$1000 an hour — bill by the week.
- The focus is on the deliverables, not what it took to get there.
- You’re still able to shield yourself from sudden changes in scope. You’re still billing for your time, but at a larger increment.
- Did I mention that the focus is continuously on the product, and not the blows of the hammer required to make that product? This attitude shift can seriously affect what you’re able to charge your clients.
- Wait until Thanksgiving and Black Friday come around and society dictates you work a 3-day workweek. Your client will know this too, and insist on either a discount for the week or roll over two days to next week. First off: You probably shouldn’t be working 40 hours a week. You need to be building up relationships with future clients and doing other administrative work. You can skip those activities during short weeks, and focus on creating a consistent amount of value delivery each week.
I don’t know of anyone who actively works on projects and bills by the month, but for retainer agreements it’s pretty much standard. Here’s more information on how to setup your first retainer agreement.
Per Feature or Requirement
Ah, now we’re stepping away from T&M, or billing for your time. You’re now billing for some specific amount of scope.
Because you’re billing for a specific result, rather than a block of time, you’re able to price a particular unit of scope based on the end benefit delivered to your client instead of whatever the going rate is for a developer or designer in front of a keyboard.
- You can price according to value, not time.
- Your clients understand exactly how much a particular requirement will cost.
- If a particular feature only takes you a few hours of work, but is worth a significant amount of money to the client, your effective hourly rate for sitting in front of your keyboard skyrockets.
- For a big project, this can require a lot of negotiation. Each and every part of a project needs to be approved and budgeted for.
- Scope changes can requirement additional negotiation and discussions. It’s not uncommon for a stakeholder to decide that something needs to change once he or she gets their hands on the work-in-progress feature or concept.
This is the most “productized” option available. I don’t pay Sony for the amount of R&D and manufacturing hours that went into the TV that’s on my wall (T&M billing), nor do I buy the remote and the power cords separately (per requirement billing.) I pay for the TV, and in my head that TV has a certain amount of value to it.
Billing by the project can allow you to make a ridiculous ROI on your time, but it can also really hurt you if you work with a client who looks at your engagement as an all-you-can-eat buffet.
- You charge for the value you produce.
- Your client will know exactly how much a project will cost, thus mitigating the risk of budget overflow with time-based billing. This might be enough to win over a reluctant client.
- You can peg the price based on the expected financial upside that a successful deliver of this project will bring to your client. Learn how to do that with my free course on pricing.
- The faster it gets done, the higher your effective hourly rate.
- It can require you to map out every. single. aspect. of the project before you get started. Otherwise, you might assume something is simple and price accordingly, and then realize midway through that the requirement is significantly more complicated.
- It’s often beneficial for your clients to be able to change scope. When you’re billing a flat fee, you can come out as cold when you constantly respond with: “This is outside our Statement of Work (SOW). We’ll need to draft up an additional agreement and increase the cost of the project.”
- Less savvy freelancers can cave in to client demands, and spend more time on tweaks and 11th hour changes (I know I used to.) Remember: Each additional hour you spend on a fixed price project further reduces your hourly rate.
I favor weekly and I also favor per project billing.
I’m a web developer, and many of the freelance projects I’ve worked on have been many, many months in length. Anytime I ever attempted to put a flat price on dubious information that was almost 100% guaranteed to change, I was always the one left out in the cold. If you’re working on a large project, and if the scope isn’t nailed down (e.g. if you aren’t given information like: “There will be a button in the bottom right corner of the account profile page. It will say “Next”. Clicking it will trigger off X, Y and Z” and delivered a mockup and corresponding workflow diagram.)
One quick tip: Regardless of how you bill, for sizable projects you should charge for some upfront scoping or requirements gathering sessions. Some people might call this an Inception or Discovery meeting; I always called it a Roadmapping meeting. It doesn’t matter what it’s called, but it should:
- Be something with a fixed price.
- Should be an onsite meeting that aims to put you on the same expectational wavelength as your clients.
- Should have a deliverable, e.g. wireframes and 3×5 prioritized story cards, that is given to the client.
This will allow you to be more precise when estimating a new project, which not only benefits you (you look pretty bad if your estimates are off by an order of magnitude!) but also really helps your client. And plus, you establish early on that your time is worth something — you should not be in the habit of spending a day or two on putting together a proposal that might never materialize.
OK, so that wasn’t as quick as I wanted it to be, but hopefully you get the picture. Charge upfront so you can help the client distil their raw ideas into something actionable, which also affords you to get a much more precise understanding to estimate off of. Don’t be that guy or gal who throws out quotes on nothing more than, “I need a social network for X.”
For small, well defined (read: a week or two) project, I like selling a product for a fixed price. This allows me to focus negotiations around what I’ll be delivering in a week or two, and establishes a benchmark (the financial upside of a successful delivery) to start pricing against. If there’s very little room that a project’s requirements are suspect to change, and the scope is clearly defined, and you know what your client needs out of your engagement, then slap a price tag on it.
How have you billed in the past? And what issues / benefits resulted from your chosen billing style? Sound off in the comments below and let me know!