How to charge clients: flat fee vs. hourly rate?

An hourly rate is easier, because you don't need to worry about scope creep. But your total bill should <i>never</i> surprise a client—you need to communicate at each step of the way.<p>A flat rate, on the other hand, allows you to charge for the value you provide, and gives your clients a predictable budget. By charging a fixed rate, you're saying, "I can do this work quickly and well, and I'm sure enough of my estimates to take on all the schedule risk."<p>On the other hand, fixed-priced projects can explode horribly when the requirements inevitably change. I suspect that <i>somebody</i> usually walks away unhappy.<p>I use a hybrid system: I break the project down into features, and offer a quote for each feature. The quotes are measured in "points" (as in XP or Pivotal Tracker), and I charge a fixed price per point. My clients choose which features they want. And if the spec changes, we just scrap some existing features and draw up new quotes.<p>If you're a highly-productive developer, and you're good at communicating with your clients, you might find that this system offers something for everybody: Your clients get predictability and flexibility, and you get a strong incentive to become a better developer.

Tips from Thomas, which I have used to the benefit of clients and myself:<p>1) Any worthwhile developer sounds expensive when you break it out as an hourly rate, so don't. Charge a weekly rate tied to specific business goals which you think you can accomplish within one week, two weeks, three weeks, etc. If your client wants to dicker, dicker over scope, don't dicker over rate. Dickering over rate will hurt all your further business with that client. If e.g. $21,000 is too much for the budget, tell them what they can get for $14,000 and let them make the call on whether $7,000 is worth not getting $DIFFERENCE. Whether it is or isn't, it doesn't chisel anything out of your <i>next</i> engagement with them.<p>An amazing truth about the world: $X00 an hour is a lot of money, but $X00 * 160 for something which makes a meaningful difference to the bottom line of a real company is cheap at the price. Their pricing anchor will be other strategic initiatives rather than e.g. "You make more than I do!"<p>2) You bill on a time and materials basis. Basically, my best estimate is that one week of work gets you $FOO and $BAR. What you actually have at the end of the week is what you are due at the end of the week. If you change your mind on scope for $BAR in the middle of the engagement and it doesn't get done in the week, that's OK, subject to availability you can buy another week.<p>3) The basic offering is "A contiguous block of my time starting at a mutually convenient date in the near future." Things which add business value on top of that cost extra. Want to start working next week? Sure. Costs extra. Want to split the engagement into two parts? Doable. Costs extra. Want support? Wonderful. Costs extra. Want support with an SLA better than "Best effort to answer emails within a day"? Costs extra. Travel? Extra, and you reimburse costs as per your company's usual travel policy. (If I had heard that line a year earlier I would be five figures richer to the detriment of exactly no one. Doh.)

After almost ten years of contracting work as webdeveloper, I have set some simple rules for myself:<p>* If project is described, specced and scoped well: fixed price.<p>* I can spec, scope and describe the project <i>with</i> the client; never <i>for</i> the client: most simply don't read piles of specs, misunderstand wireframes and so on. We then have a specced project, which allows me to offer it fixed-price.<p>* In all other cases, I won't ever work fixed price, because one thing is guaranteed: the noneexisting specs will shift, the wireframes in the head of the client will be "different then you understood them" and you will go over your allocated time, on your own money.<p>* A middleground solution would be to give a fixed price for the well-known territory (setting up a set of servers, installing, say, Drupal with some wellknown modules) but move over to hourly rates for all the (as yet undefined) custom work.<p>To sell this to clients, I simply give them a vast discount on hourly rates: after all, the client is carrying the risk. If a client does not understand this, then I bail out of the project: I can simply not afford to carry the risk of a) Not getting payed for several months, because of a delay of several months. b) With every additional 100 hours, seeing your "wage" drop another few dollars. I have had projects, where in the end, I worked for less then I would have made, had I spend these hours working in the MacDonalds. You can explain a client that having their developers carry such a risk, will bring themselves the risk that at a point the developer will simply quit (without pay): leaving the client with a huge amount of wasted time and still no releasable project.

Any time you hear yourself thinking "I'll quote this part of the project based on my hourly rate", please at least use a <i>daily</i> rate. You're a sought-after professional in a white hot market. You don't do partial days.<p>A customer that's worth bending that far backwards for is worth a couple hours <i>gratis</i>. Everyone else can just pay your daily.<p>Every quantum of time higher than "hourly" is more favorable to you. Data entry temps might look attractive at their hourly rate, but developers have frightening hourly rates. Even just doing your quotes in chunks of eight hours frees your client up to think about how much you can get done in a day. Nothing gets done in an hour.<p>You have a 1-day minimum. Think of it this way: there is <i>no way</i> you can expect to be effective working for two different clients 4 hours each in a single day. It takes too much time just to get back into flow. So any time you quote less than a day, you're either giving the client the rest of your availability that day <i>for free</i>, or you're stealing it from another client.

I've worked as an engineering consultant for 10 years. Here's the best algorithm I've come up with.<p>1. Guess how many hours you think the project will take to complete. (This is hard.)<p>2. Guess the highest number the client will agree pay for the project. (This is also hard. I find that saying things like, "Do you see this as a small $5000 project or a more substantial $50,000 effort?" is useful.)<p>3. If that results in an acceptable hourly rate for you, propose this as a flat fee to the client. Otherwise, figure out how to make the project smaller or leave.<p>4. Do the project and bill the client with an invoice that makes your hourly rate clear. (If the project takes longer than you expected, give the client those hours for free. If the client tries to add more stuff to the project, refuse to do those things under this contract.)<p>5. Now you've established an hourly rate with that client. If you did a good job and the client is reasonable, you can now do future projects on an hourly basis.<p>Eventually, you will want to raise your rates, which is hard to do. I've found it easier to just make higher flat estimates, and then finish them faster, making my effective hourly rate higher. The key here is that people balk at $XXX per hour, but they'll often pay $XX,XXX at that rate if it's for something they need.<p>There's definitely the risk with this algorithm that you will charge too little and work too long. I think the hard truth is that even "hourly" projects are usually charged a flat fee, plus or minus a few percent, because most clients aren't lying about their budgets. If you estimate a project at 100 hours at $150 per hour, they will expect you to complete the project for something very close to $15,000. If you end up saying, "Well, that was just an estimate. It actually took 200 hours, so you owe me $30,000," they might pay, but they won't hire you again, which makes your hourly rate terrible because you have to spend free hours finding a new client.<p>I think the right knob to tweak in doing work on a project basis is often quality. If you've agreed to do X for $XX,XXX, the price is defined with great precision. The project is not. You should strive to deliver the best results you can, but you can omit the engineering polish you'd like to put in-- finishing on time and on budget is its own kind of polish, and one that people who hire consultants particularly appreciate.<p>Edit: I should add that putting free polish on a project is often the best sales work you can do.

I've found that by far the best strategy has been coming up with a flat quote for the rough draft, and then billing the revisions phase by the hour.<p>This way, the incentives line up: the part that you have total control over, you are incentivized to go as fast as you can, to work as efficiently as you can, etc. Then once you've delivered a rough draft, the client is incentivized to be as clear as possible and not to endlessly change his mind. And even if they do, you're happy because you can bill for more hours.<p>I think splitting the difference in this way has worked very well for me in several years of client work.

I think a better idea is to charge a flat fee for the project (you get it nailed down before working on it) and then per/hour for any additional changes.

I use an hourly rate to calculate my fixed prices based on estimates.<p>It's rare that on a large project a client will accept an hourly rate (hourly rates usually occur on maintenance agreements in my experience with a cap over which extra approval is required).<p>The trick to staying profitable is to iterate in very small chunks, the earlier in the relationship, the smaller the iteration.<p>Deliver discrete value with each iteration so if they're not happy, they can walk and reasonably expect another competent contractor to finish the work (this means using popular tools and good documentation).<p>As you get further along in the relationship and on each project you get a better idea of how long things typically take and can provide higher fixed price quotes with less risk. Also as the relationship improves and your client trusts you more, you can do things like give "best case" estimates with the proviso that it may be revised upwards if a task turns out to be more difficult than you'd thought (in exchange for this, you can charge the client less money because you don't need as much "padding" to absorb the risk yourself).<p>Eventually you move into the maintenance phase where you bill by the hour and by that point the client generally trusts you enough so they know you're not trying to screw them.

Consider charging a day rate. Only you know how many hours it takes you to do a 'day' of work.

Your overall fee should always reflect competitive pressures.<p>Your competition are:<p>1. Other local developers who have the same domain expertise<p>2. Other local developers who don't have the same domain expertise<p>3. Outsourcers<p>4. Alternative technology stacks<p>Each of the alternatives have their own risks and advantage. If you are dealing with portions of technology where you are not familiar with, then you have to ask yourself whether it makes sense to charge more to cover for the additional time, or incur the cost of learning on yourself. In which case, whether it is a technology you wish to master. You have to remember it only takes one little problem for things to blow out.<p>There is another aspect to consider: pre-built components and your own IP. You can command a higher hourly rate if you tell them that you will include software libraries that you bring to the table, or alternatively bring the overall cost down. In some countries, there are taxation differences between selling licenses and selling labour.<p>It should also reflect timelines. Some people are prepared to wait, other people need this immediately. Your charging should also reflect this. For instance, when people have an urgent need, you should put more effort into providing confidence that the project will be delivered on spec and on time, and charge accordingly (i.e. don't try to compete on price).<p>In addition, your cost should reflect the number of attempts the customer has made in the past. For example if he had two failed attempts, you have to ask yourself what is actually wrong, and perhaps he is unable to communicate the requirements properly.

Bill on value not costs.<p>Whether you're billing hourly or a flat fee, you're still probably billing hourly (factoring all the hours that you can plus the amount of risk you think you can handle).<p>Figure out how much value added this project with add to their bottom line in the next 3/6/9/12/36 months. Bill them accordingly.<p>As long as it's not obscenely out of the market range and you can PROVE the value of what you're doing, people are happy to pay.

Well, I found the best thing for me is to create an estimate based on my hourly rate. Clients generally don't care a lot about the hourly rate but the global cost.<p>Since it's an estimate, I draw the client attention to the following facts:<p>- If the requirements change the estimate will change too.<p>- I work on an hourly rate. If I think that the project will cost more, I'll notify you why and by how much.

It boils down to who wants to take on the risk, you or the client. In all my years, I have never worked on a project that didn't change in scope (smaller or larger) ... even my own. It's almost inevitable in fixed price that one of the participants always ends up unhappy.<p>After having run a services business for many years and experiencing the issues with fixed price, I am definitely in the hourly rate camp. As for the argument that it punishes the speedy, well it's up to you to sell an appropriate rate that you are happy with. That way you can't lose no matter what the client requests or changes and it keeps your personal PM part of the job to a minimum. I can hear the "what about AAs/CRs" already but we all know it's a hassle going back all the time asking for more money if the project is changing a lot.<p>It's much easier to take each new decided feature, say yes and charge for the time it takes.<p><i>"Time is money"</i> and that's how you should charge for it.

This dilemma is where an iterative approach to development can really come in handy. Charging $200/hour for an open-ended project is challenging to get any client to accept. Charging $x/hour for a 3-4 week iteration (where the deliverable is a functional, but not necessarily complete, piece of software) is much easier.<p>I have been burned so many times by fixed-rate projects that I generally turn the work down every time the client insists on it. It throws the alignment of the developer and the client completely out of whack, takes away the paltry amount of leverage that the developer has over the project, and it basically assumes that you won't run into unknown unknowns. This means it's terrible for the developer, but it's actually quite a bad deal for the client as well.<p>Fixed-rate coding assumes that software development is at the same general level of predictability as having the oil changed in your car.

I have had good experiences with what we call "Collaborative Contracts": <a href="http://www.zealake.com/2010/09/26/pay-less-for-your-agile-project/" rel="nofollow">http://www.zealake.com/2010/09/26/pay-less-for-your-agile-pr...</a><p>Basically, you charge an hourly rate but a rather low one. A bonus is added for reached milestones. This gives you the best of both worlds. The buyer is not tempted to "sneak in" more features or argue over some spec because he is still paying per hour. However, the developer is interested in working as efficiently as possible as the bonus is a fixed amount which will mean that his effective hourly rate goes up with fewer development hours.

When you're starting out, just DON'T start with flat fees. Your rates aren't high enough, and you won't have the leverage/experience to successfully navigate the issues with requirements changes.<p>But once you get it, they're pretty nice to offer to people.

Alternative Fee Arrangements used by law firms could be adopted for this. The following are most commonly employed. 1. Fixed Fee 2. Capped Fee 3. Volume Discount 4. Early Payment Discount 5. Fixed Rate 6. Blended Rate 7. Retainer<p>The idea is you have a lawyer draft a complex agreement with multiple fee arrangements, most involving some math. And provide an invoice with pre-agreed work descriptions. Lawyers use UTBMS. You should be able to come up with something that you and your client agree. This makes your invoice look more "professional" and easy for the accounting departments of your clients.

I recently switched to invoicing per commit (current rate being €40).<p>A flat fee is risky for you and charging per hour is risky for the client (and tedious for you to keep track of) — the commit is less risky because he won’t be charged for half the day you spent tracking down a stupid bug you introduced in an earlier commit or work you threw away because your understanding of the involved API was immature when you started it etc.

I've always been a per-project type of person. If the requirements are clearly defined up front, you as the developer don't need to worry about scope creep. Obviously, this is a double-edged sword if you find yourself in a position where something takes you longer than expected. But if that's the case, that's really your own fault - not the client's. It seems to be the most equitable basis IMO.

the problem with flat fees, is that clients tend to want extras, so you can end up working for minimum wage.

My preference is to scope well, give the client a per-project quote and then charge hourly for out-of-scope work.<p>This way, the client knows what to expect to pay from the start and if he introduces changes on the way he knows it is going to cost him extra.

I liked Steve Friedl's thoughts on this. (Skip to the Billing heading.)<p><a href="http://www.unixwiz.net/techtips/be-consultant.html" rel="nofollow">http://www.unixwiz.net/techtips/be-consultant.html</a>

Clients always have varying project scope and specs, so in my experience hourly rate works well.

watch the Mike Monteiro FU Pay Me Speech. <a href="http://vimeo.com/22053820" rel="nofollow">http://vimeo.com/22053820</a>

I don't have good citations for these figures, but I'm pulling this out of Stephen Fishman's book "Working for Yourself."<p>In one informal survey of self-employed people it was found those who charged fixed fees earned on average 150% more than those who charged by the hour for the same services. In another survey by a trade journal it found that self-employed people who charged a fixed fee earned 95% more than similar people who charged by the hour. I believe these surveys were across industries and not specific to software.<p>Make that what you will, but it seems to suggest on average you're much better off charging a flat fee. I can conjecture a few reasons why.<p>1) If you're good enough to have the confidence to charge a fixed-fee, you can estimate based on the normal hourly rate and add a healthy amount of contingency. Because your estimates will be accurate you will almost always come out ahead compared to going with a straight hourly rate.<p>2) Customers are willing to pay a premium for cost certainty even if that cost ends up being higher.<p>3) By putting a cap on the cost of a project, the developer is less likely or unable to exploit that so the project may actually get completed faster and more efficiently than if a payment ceiling wasn't over his head.<p>Controlling a fixed price project is difficult and simple at the same time. It's difficult because it's so easy to hang yourself if you're not careful. It's easy because all you need to do is define the scope ahead of time and agree up front that the price and time needs to be adjusted when the scope changes. So whenever the client asks for something outside your mutual understanding of scope you have a provision in the contract that states you must amend the contract for the difference in cost and development time. It's called change control, and can be as simple as "hey, that feature is way beyond what we agreed upon. I can do it but it will cost an extra $4,000 and the delivery date needs to get pushed back two weeks. Sign this contract amendment to that affect if you still want me to do it."<p>Likewise, if something that was assumed in the contract turns out to be untrue, that can be revisited with a contract change. For example, assume there is an open source library for barcode scanning. If it later turns out there isn't one suitable for the task, you're completely within the contract to say, "Hey, I know we were hoping to save some time and money by using this library. But we agreed it was a risk and after I used it more it has too many issues and this endangers the success of the project. We can buy this commercial package for $4,000 but I will need to redo a lot of my work. I'll give you a break on my labor, but it will still cost $6,000 and add another week if you agree to it." Something like that.