The Definitive Guide To Project Billing

by Brennan Dunn on — Get free updates of new posts here

I’m coming up on my one year anniversary of publishing weekly fresh content for freelancers and consultants. For those that have been with me the entire time (and those that have jumped on along the way) — thank you!

Today I’d like to, once and for all, answer a question that I’ve been asked dozens and dozens of times. (Seriously. I probably get ~5 emails a week on this question. Yipee! Now I’ll have a post to send ‘em to :-))

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

Hourly

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.

Pros:

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

Cons:

  • 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

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.

Pros:

  • You don’t need to track any 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.

Cons:

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

Weekly

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.

Pros:

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

Cons:

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

Monthly

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. See this post on recurring revenue, and sign up for my upcoming bootcamp with patio11 on how to build up recurring revenue for your business.

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.

Pros:

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

Cons:

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

Per Project

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.

Pros:

  • 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. More about that in my Skillshare course.
  • The faster it gets done, the higher your effective hourly rate.

Cons:

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

My Recommendations

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 can be done live or remote using something like Planscope’s collaborative estimating feature.)

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 distill 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!

 

Want more pricing advice like this?

Here's something I wrote that I think you'll like, "Sell More Than Just Information"

Brennan Dunn writes about the business of freelancing. Over the years, his weekly articles and courses have helped 22,000+ freelancers grow their businesses.
  • lisaleague

    Great article! Trying out weekly and daily billing now on new proposals.

    “Don’t be that guy or gay who throws out quotes on nothing more than…” – I think you meant “gal”

    • https://planscope.io/ Brennan Dunn

      Ha! Serves me right for reading a few articles on the Pope’s trip to Brazil and the press interview thereafter right before writing this post. Thanks Lisa!

  • Jason Swett

    What billing style have you used (or would recommend using) for projects that are several months in length?

    • https://planscope.io/ Brennan Dunn

      Weekly, prefaced with a paid roadmapping session (see my 2nd paragraph under “My Recommendations”)

  • http://www.coreyballou.com/ Corey Ballou

    Billing for the final product or for a specified amount of deliverables is the holy grail but requires experience in project estimation as to not screw yourself. Anyone with experience working for creative/design/development agencies gets pretty accustomed to this. At some point, you’re responsible for scoping out projects in fine grained detail so the agency can tack on a dollar amount to your hourly estimation, multiply by a buffer (due to your inability to estimate properly), and send that off as the final project quote to the client.

    If you’re comfortable with doing this, it’s in your best interest to to pitch this style of project bid (for deliverables) as opposed to tacking on hourly estimates to each line item. You’ll still have a deadline, but you take the focus away from hours of work. Your hourly estimates per line item should be an internal reference for yourself when bidding on the project. This approach shifts focus towards the amount of work you’ve completed and not how much you charge per hour. It’s an easier sell for projects large enough to warrant it; namely anything that will take a week or more to complete.

    Oh, and follow me on Twitter @cballou!

    • https://planscope.io/ Brennan Dunn

      Well said, Corey! “Taking the focus away from hours of work” is the key to making more FOR the actual hours you work :-)

  • clemensk

    I don’t like the approach of “obfuscating” the amount of work you put into different aspects of the project. I like the transparency hour sheets bring because in my experience they tend to build trust between you and the client – and I do them independent of how the project is billed.

  • Cory Schmitt

    How do you developers bill for bug fixes?
    It seems that you could bill more time on the front end really testing for the edge cases that come up, or bill a small fee when/if they come up.

    Other opinion I heard was give a grace period after delivery. Any bugs fixed for free for 30 days, and after that have to pay my hours rate.

    How do you guys handle this?

    • http://paltman.com/ Patrick Altman

      I don’t view bug fixes as something that should be free. Software is never perfect and in my experience, clients prefer speed over bug-free. There is also a huge grey area of “is it a bug or something that the client would like improved”. A typical argument against me in charging for bug fixes is that it gives me motivations to be sloppy or deliver bugs so that i get follow on work, but that is a very poor argument, as buggy code can really kill one’s branding. We all want our businesses to be known for delivering high value and that means both fast and high quality. I find I am usually more concerned with bugs than my clients are because I care deeply about their perception over what we are delivering.

      • Bill

        Hi Patrick,

        I run an animation studio so we work in a different medium but I think our rule to some kinds of bug fixes. If there is a flaw in what we produce that is down to our own oversight, we fix that for free.
        Similarly if a web designer was given a brief, say it had to work on Firefox, Safari and Internet Explorer, and then after delivery it was found to have a glitch or formatting issue on Firefox, I’d expect that to be fixed for free as the web designer hasn’t met the conditions of the brief.
        However, if there was a new version of Firefox that came along after the launch of the site and that caused some kind of issue, I’d expect to pay for that bug fix as it wasn’t caused by anything the web designer had done.

      • PalladiumDrive

        I usually give a 30-day debug window and i am very clear with the client as to whether the issue put forward is a bug or an additional requirement. If it’s determined to be a bug (or a missed requirement from original SOW), it’s fixed on my dime. After the 30 days, any issues are fee for service. I like to set up a maintenance contract after the 30 days so the client has some hours paid for and can have some semblance of cost certainty.

        BTW, for clients I really enjoy working with and respect me and my time, and the project was big enough to warrant it, I will extend a 60-day window :)

    • Won Word

      If I caused the bug, then I fix it for free (I have some padding in the estimate for unknowns, which includes bugs).

      If the bug is caused by a hole in the scope (like an edge case), then that is billable.

      Finally, I’m pretty flexible for nice clients. If there’s an infrequent request for a really small fix and they were pleasant to work with & paid on time, then I’ll do ‘em a solid.

  • http://www.theperpetualvacation.com/ Marcella Chamorro

    Awesome post, Brennan. Thanks for answering all of that. Is Planscope going to offer per feature or per project billing in the future, or is it only per hour?

    • https://planscope.io/ Brennan Dunn

      Right now planscope offers all of the above *except* for per project (though you can use it now hourly with no hourly rate to basically do that). We support daily, weekly, monthly and per task

      • http://www.theperpetualvacation.com/ Marcella Chamorro

        Awesome, Brennan! I didn’t quite get how you’d use it hourly with no hourly rate, could you explain a bit further?

        • https://planscope.io/ Brennan Dunn

          Great question! So if you’re billing a flat rate for a project, Planscope’s budgeting doesn’t really matter. However, I still think it’s important to know (especially on flat rate projects) how much time you actually spend doing work.

          So you’d create a new Planscope project with the defaults (hourly, no rate supplied), work on your project, and then cycle back and see exactly how much time you spent — even though it doesn’t end up affecting your client. It’s valuable to figure out your effective hourly rate.

          • http://www.theperpetualvacation.com/ Marcella Chamorro

            Ah I see! I ask because one of the features I believe makes Planscope so incredible is the collaboration on creating a budget with the client — and the notion that any new features will go into the in review tab. I feel like those two aspects create so much frustration/awkwardness for freelancers and you managed to help that. It’d be so cool to be able to do the same as you have it set up now, but with per feature costs instead of per hour. (Maybe that’s already possible?)

    • http://danielsalazar.me/ Daniel Salazar

      This would be an awesome feature.

  • http://chriskottom.com Chris Kottom

    A lot more customers want/expect per-project pricing now than used to years back when I first started freelancing, and if there’s one thing I’ve learned over the years, it’s that I’m a crap estimator. Because of this, I’ll still advise customers who haven’t really locked down their specs to opt for daily or hourly, but in cases where they insist, I’ve started to price projects with the possibility for a multiplier related to the uncertainty for certain requirements or the whole project.

  • Yehoshua Coren

    Brennan,

    I tend to try to leave more substantive comments to people’s posts, but it is late at night for me and I just want to tell you that I really enjoyed your post (before I need to go crash).

    Thank you.

    Yehoshua

  • Troy Dean

    Great post Brennan and thank you for sharing your thoughts on this somewhat complex issue. I firmly believe that trading time for money is not a sustainable business model. I also sell road mapping sessions but usually call them “online business accelerators”. I have also productised wireframing, prototyping and strategy consulting for those projects where the brief is too vague to quote on designing and developing.

    After speaking with hundreds of WordPress consultants at WordCamps over the years I believe it is an inherent insecurity and not valuing oneself that leads most freelancers to charge an hourly rate. An hourly rate is an arbitrary figure that two parties agree on when they can’t agree on the value being transferred in a relationship.

    Our job as web consultants is to illuminate the value we bring to the table and lose our hourly rate forever.

    Keep up the great work Brennan!

    • https://planscope.io/ Brennan Dunn

      “An hourly rate is an arbitrary figure that two parties agree on when they can’t agree on the value being transferred in a relationship.”

      Perfectly said, Troy!

      • Troy Dean

        You might enjoy this sometime – a presentation I gave at WordCamp Phoenix via video from Melbourne – http://www.videousermanuals.com/blog/wordcamp-phoenix-presentation/

      • Bill

        This is where I get stuck. If I had some work that needed doing on my car and it took someone 1 day to do it, I’d totally expect to pay for 1 day of their time. I would not expect them to put a value on me being able to get to work, pick up my family when I needed to, go to client meetings and so on and then bill me according to that.
        if someone took that approach I’d go find someone who billed more fairly.
        To me the billing-by-value approach seems greedy and like old fashioned ‘evil-business’ I put that in inverted commas as I couldn’t think of a better phrases just now, but why should people and companies be victims of people who want to screw as much money out of them as possible (sorry if this is a little overstated!) instead of paying for the time, skill and training that was needed to create it?
        I’m really looking forward to the workshop to see if it changes my opinion on things!

        • Won Word

          If your car was broken down and your boss told you that you had to be at work on time the next day or you’d be fired, getting your car fixed on time and done right would be WORTH THE EXTRA COST.

          If, however, you were heading into a three-day weekend followed by a week of telecommuting (and you had a full fridge) and your car made a faint funny noise when you turned on the windshield wipers and the radio at the same time, then it might not even be worth your time to get it fixed, even if the fix was free.

          See how those extremes work?

          That’s value.

    • Rob Balucas

      Really well said, Troy. As always! Look me up next you’re in San Francisco

  • http://www.mimiran.com/ Reuben

    Great article. The tip about the paid discovery session at the beginning is critical. You do not have to do project billing blindly, which would be bad not only for you but the client, as well. You can even break large projects into chunks. In my experience, most customers would rather not deal with hours, time sheets, juggling availability of people, approving expenses for purchasing packaged software when it makes more sense than writing code, and all the other minutia. The just want to make sure you are on track to deliver.

  • Dorian Speed

    I actually have switched to hourly billing for now, largely as a result of using Planscope. I do this for two reasons:
    1. I am part-time on purpose, with an extremely variable schedule as to when I can work (because of family commitments)
    2. I’m still learning to appropriately estimate the amount of time something will take and avoid scope creep. Hourly billing helps with this, particularly my *own* tendency to introduce features and say “hey, this would be great! Let’s do it!”

  • tgriffin5000

    That’s for the great post. Over the years, I’ve aways been a “flat fee” provider–and not very profitable. About a year ago, I took a hard look at my “numbers”–all the project-based stats I’d been tracking–and got real depressed! That’s when I started experimenting with various pricing methods.

    Currently, the way I estimate costs is a mix between “per-item/unit” pricing–which was admittedly hard to adjust to, for someone who’s always been against “commoditizing” my work–and the old “flat fee” method. There are still kinks in the system, but it’s working out. Something I didn’t expect is that being able to put a specific, preset dollar value on everything I do has made me a lot bolder and more confident in dealing with clients.

    • tgriffin5000

      “Thanks” for the great post. :)

  • Klaus Hebsgaard

    I know I am really late to the game here – but I have a question:
    I completely buy the weekly is better than daily for me as a consultant.
    But for the customer what are the benefits?
    How do you sell weekly billing when hourly is expected by the customer?

    • Won Word

      Weekly is better because you’re focusing on weekly deliverables, rather than daily work.

      On a more advanced software development project, there aren’t too many daily deliverables. YMMV.

  • http://1106design.com Michele DeFilippo

    We bill by the item, including a set amount of revisions, with additional revisions billed by the hour, which works pretty well. Two “surprises” throw off the calculations and siphon off profits: (1) As you said, clients who consider us an “all you can eat buffet” for advice, generating hundreds of emails, and (2) clients who demand in-person meetings that aren’t necessary.

    It’s rarely possible to discover these traits before we are hired. In your webinar, I’d like to learn how to address these two issues without disappointing the client or being accused of “bait-and-switch” tactics.

  • Madison Woods

    I billed by the project once, and it seemed all was going well. Met with client, discussed and plotted out the project, explained how it worked to them, they were happy with first draft and so I went on to applying the finishing touches. Then client became very picky and wanted different shades of colors, different texts in places we’d already decided upon the text that was there, different photos in different places. I tweaked for more than a week trying to satisfy, but the amount of change she wanted in reality ended us up with an entirely different project that I would have billed differently had I anticipated it in the beginning. How do you deal with customers who want endless tweaks? When she wanted to change photos (this was for an apartment complex website) she gave me a thumb drive with a lot of high res, disorganized photos. After she wanted different ones than the ones I’d chosen to represent the shots she wanted on the site, I gave her the drive back and asked her to reduce the files and organize them into folders according to the page she wanted them on. The job finally ended after that because it was too much work for her to do.

  • Nathan E Ball

    I really like the idea of giving some support to items directly developed by “us” but I often find clients get “confused” about what is an issue built into a plugin or a software over a mistake or over-site on the part of the designer/developer. I think a strong paragraph in your proposal stating or outlining what is considered a bug or over-site can be handled in a say 30day period but an inherent issue with software or freeware should not be included and would warrant a hourly charge. I also often offer a monthly service plan with a discounted set amount of hours so something like thins could fall into that an not cost them as much.

  • Andrew Chason

    I have a pretty great little company making logos and websites. I have over 15 years of design experience. I only have about 2 of being in business.

    The problem is I know right where most my clients are at, I am them in a sense, I can empathize with them. I exist somewhere between freelance and a small design firm (having not fully formed the business properly and being thrust into being an Entrepreneur by life’s circumstances).

    I charge $60 and hour and then do the math to make that a semi-fixed rate (my contract says all number are estimates).

    My clients tend to be small business folks; most of which have no money and no business plan, but know they need what I can create just so they can be “marketable”. If I start charging more, this avenue will dry up. I don’t know how to increase my rate AND start courting the medium-to-large sized businesses I need so _I_ can be successful.

    • Nate Nordstrom

      Hi Andrew, hopefully a little of my story will help you too.

      I used to be a solo freelancer at an hourly rate like yours. I worked with small businesses and they really liked my work. I got so busy that I needed to hire some contractors to help get everything done. After about a year some larger businesses started to take note. When I got a chance, I pitched larger dollar projects to these larger clients, and soon we were mostly doing the higher dollar projects I never thought we could get.

      What we found is that these middle sizes businesses got even more value out of the work we did because of their size. They were so happy with our work, that we soon got opportunities to land even larger clients. (We’ve added staff along the way.) Every time in our business that it seemed we were hitting a ceiling, we found another “magical” client level where they happily paid our increased rates.

      The most important thing we have done is to ALWAYS focus quality, listening to our client’s needs (and asking questions until we identified where/how we can add the most value for them), and good ol’ fashioned customer service. Do the right things, don’t be afraid to hear no sometimes, aim upward, and keep pressing on. The future is bright!

  • http://www.invoicera.com veronikatondon

    Hi
    This is a very useful article. I prefer billing for tasks, time and expenses. I use Invoicera to first send and estimate to my client. Once the estimate is approved a ask client for an advance and then get the work started.

    Manager
    http://www.invoicera.com

Contact Twitter Facebook