The Definitive Guide To Project Billing

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.


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


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


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

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.


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


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

Interested in more content like this? Join over 6,500 other freelancers and consultants in getting my weekly newsletter.

What would raising your rates do for you this year?

You bill $ and work hours a week...
  • A 50% increase in rates will bring you $ more this year
    (or 5 X)
  • A 100% increase in rates will bring you $ more this year
    (or 12 X)
  • A 200% increase in rates will bring you $ more this year
    (or 52 X)
Find out how you can Double Your Freelancing Rate →
  • 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”

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

    • Brennan Dunn

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

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

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

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

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

    • 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

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

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

          • 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?)

    • Daniel Salazar

      This would be an awesome feature.

  • 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


    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.


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

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

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