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

http://watilo.com/how-to-charge-clients-flat-fee-vs-hourly-rate

by Concours • 15 years ago

116 67 15 years ago

vaksel• 15 years ago

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

paulhart• 15 years ago

And that's why change requests were created. Also, be sure not to make the scope fungible, because the last thing you need as the worker is for the client to say "oh, we don't want that functionality any more, we want this instead, that should be the same effort".

tptacek10• 15 years ago

The problem with your business is that you take projects that don't have formal statements of work.

Professional consultants always work under a SOW, either as an exhibit to the standalone contract they have with their clients or, for major or longstanding clients, as the "per project" contract that accompanies a master (MSA) contract.

The whole reason you write a statement of work is so that the client can't reasonably claim that an "extra" they want is actually within the original scope of the project. If you chronically say "yes" when your contract (and good sense) says "no", then the problem isn't with how you quoted the rate; it's that you're unprofessional.

I'm sorry to be harsh about it, but the histrionic tone of your comment ("working for minimum wage") seemed to justify it. If you're even coming close to working for the rate your expected full time salary would back out to, you're doing something so wrong as to warrant shouting.

rick888• 15 years ago

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.

sathishmanohar• 15 years ago

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

peteretep2• 15 years ago

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

dan_manges2• 15 years ago

I think it's misleading to quote a day rate and then work less than a typically expected number of hours. The client will make an assumption that a day is approximately 8 hours and wouldn't be happy if he/she found out that you were only working 4 hours per "day."

Dove• 15 years ago

I disagree. The client is much more interested in what you get done in a day than how much time you spend doing it.

peteretep2• 15 years ago

The client is expecting a certain amount of work done in a day, and is measuring your 'days' against the 'days' offered by shittier programmers.

pingswept3• 15 years ago

I've worked as an engineering consultant for 10 years. Here's the best algorithm I've come up with.

1. Guess how many hours you think the project will take to complete. (This is hard.)

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

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.

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

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.

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.

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.

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.

Edit: I should add that putting free polish on a project is often the best sales work you can do.

pingswept3• 15 years ago

I should also add that I think this algorithm doesn't solve the problem mentioned in the blog post-- the situation of a seasoned designer working on long, open-ended projects. I think that requires an excellent record of desired results and a trusting client.

T-hawk• 15 years ago

> 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

This bears repeating. Has anyone else noticed how the business world has redefined "estimate" into exactly the opposite meaning? Now it means, more often than not, an exact number etched in concrete for the beancounters to lock in their costs. In my previous job at a financial software consulting company, we developers learned to fear any call for an estimate. We even frequently had conversations from management that went "give me an estimate for this development, and the client has already approved a ten day work order so your estimate needs to be exactly ten days."

dan_manges2• 15 years ago

It's helpful if you let people know as early as possible if you're going to go over the estimate by a substantial amount. In the example in the grandparent comment, I can understand why the client would be unhappy paying $30,000 for a project that was estimated at $15,000 if they didn't find out until the very end. Imagine if you had to get your car fixed and when you went to pay the bill it was twice as much as the estimate, and compare that to the experience of getting a call part way through to inform you that the fixes will be more expensive than originally estimated.

tptacek10• 15 years ago

I agree with most of this, but caution against bidding more hours than you think the project needs in order to raise your "effective" rate. In addition to being slightly skeezy and potentially queering expectations on future projects, doing this also has the practical risk of putting you on the hook for additional work if your client starts aggressively project managing you; after all, they bought the time.

Another way (also skeezy, I think) firms play this game is to double-book and have teams juggle multiple projects, thus genuinely spreading the hours on the project out while keeping effort constant.

I really think the thing to do is to be upfront; if your rates are raising, they're raising. If your customers want to mitigate that risk, they can pay for it: pre-buy time commitments at a discount from your current rate. I think advanced purchase is a more effective (and more professional) lever to use than rustproofed hourly quotes.

pingswept3• 15 years ago

I should be clear-- I'm not saying you should make up fake hours or pad your estimates to conceal a higher rate-- you should work on the basis of flat fees. If the client thinks you're not worth the money, they can choose someone else to do the work. If the project takes longer than you expected, you lose, and the client wins. I think that's different than the "they bought the time" approach you were (sort of) attributing to me.

berkes• 15 years ago

After almost ten years of contracting work as webdeveloper, I have set some simple rules for myself:

* If project is described, specced and scoped well: fixed price.

* I can spec, scope and describe the project with the client; never for 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.

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

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

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.

andrewflnr• 15 years ago

I really like that middle-ground solution. I might do something like that if I get another free-lance job. Thanks.

ekidd• 15 years ago

An hourly rate is easier, because you don't need to worry about scope creep. But your total bill should never surprise a client—you need to communicate at each step of the way.

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

On the other hand, fixed-priced projects can explode horribly when the requirements inevitably change. I suspect that somebody usually walks away unhappy.

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.

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.

nicksergeant• 15 years ago

This is brilliant. I'm going to try this on my next freelance gig.

nesbot3• 15 years ago

I just see this as fixed price your just exposing your broken down system to the client rather than supplying a larger $x to complete the whole project. You do limit your exposure by using the smaller chunks though.

The issue is that if the "spec changes" you still need to work out what happens next, ie. scrapping some features etc.

Hourly rate keeps this process smoother, and smooth is the new fast.

tptacek10• 15 years ago

Hourly rates get you paid less, because your rate sounds higher in the context of "one hour's work" than it does in the context of "cost for a completed project", plus the fact that the hourly quote comes with the implicit risk that you'll go wildly over budget. The client will mitigate that risk and take the cost of that mitigation out of your hide.

You won't realize it until you and your friends start complaining over beers about how jacked up your big competitors rates are; they aren't, though, they're just not getting rolled by their clients.

People here really seem obsessed with the risk that the client is going to change their mind a hundred times. That makes sense, because it's the element of risk that developers actually see, care about, and feel entitled to an opinion about. But some important things about that risk:

* Unless you're working for tiny clients, it's much less of a real-world risk than it sounds. Major clients don't start projects with the intent of squeezing extra hours out of their devs. The amount of money they save by doing that is less than a rounding error, and, most importantly, they aren't spending their own money to get you.

* There are better levers to pull to mitigate project/schedule risk than quoting at your most flexible and least favorable rate by default.

* Even if you shoulder the risk of midstream spec changes, in all likelihood a client that pulls the rug out from under you is probably going to be reasonable about buying more of your time, especially when you say "no, I can't get that done in the original schedule; I don't see a way to resolve this without adding time to the project".

The middle ground between project and hourly rates has been our default for years:

* We break pricing down by person/week

* Our proposals loosely attribute milestones to weeks

* Any negotiation is conducted over the total project amount

* Project price cuts take the form of scope/effort reductions

This is a project-based bidding system that leaves you with the ability to say "no" or "you choose, either this new stuff, the original project milestone for the week, or an extra billable week and a new SOW".

dennyabraham• 15 years ago

This is definitely my favorite system when I can get clients to sign on to it. It manages expectations, defines scope, and ensures communicative development at the same time.

I also worked for a firm that sold sprints whose point velocity would automatically adjust to account for point value fluctuations.

dhalsey• 15 years ago

Do clients usually agree to this system? If they're unfamiliar with sw development, it might seem suspicious. I wouldn't be exactly comfortable with a plumber drafting up anything else than a standard work-and-parts contract.

nickmolnar2• 15 years ago

We have tried just about everything at our shop, Thirdi.

Fixed rate quotes are dangerous because they make all the pricing decisions at the point where you know the least about the product. They lead to waterfall-esque development, since your only shot at avoiding scope creep is to catch everything up-front. Plus, change requests feel like nickel and diming to the client, slow the project down, and are just generally bad service.

Hourly billing is difficult to sell: would you buy a house, knowing that the sale price might increase by 30% after you moved in? Plus, you run into the problem of those hours not being tied to a productivity level.

We've started giving high-level estimates of projects up front, but not committing to a specific scope or price. Instead we invoice for each 2-week sprint with set deliverables. This way, the client is paying for features, not time. We start a feature backlog at the beginning of a project, but add in much more detail right before each sprint starts. The client always knows what they're buying, and we can quickly tell if we're running ahead or behind on the project based on whether we are finishing sprints early, and how many features we are knocking off.

By not getting married to one feature-set at the beginning of the project, it also allows us to throw in 'nice-to-haves' that might be easier than expected, or scale back less important features if they turn out to be more complicated than we thought. It does add time for communication and managing the backlog, of course. We have a dedicated project manager and a QA lead to keep this stuff away from our development team, otherwise they might have all gone mad by now.

rapind2• 15 years ago

One thing to keep in mind is that it takes time to come up with a detailed quote like this, and you'll want to be paid for that time.

I usually throw out a ball-park guesstimate (without signing anything) to see if the client is comfortable with it, and then ask them to pay for a detailed quote like this, which they then own and can shop around with.

You can take somewhat of a loss on the scoping since if they've agreed to pay you for it, there's a really good chance you'll be awarded the contract (as long as it doesn't blow them away or they have unrealistic expectations, in which case thank god you scoped it out). This way at least you're still getting paid something.

tptacek10• 15 years ago

I would never bill a client for the time it takes me to build a proposal, and I would think way less of any contractor who suggested I pay for their proposals. Don't do this. Research for quotes and proposals is in almost all cases a cost of doing business.

TheHunter• 15 years ago

watch the Mike Monteiro FU Pay Me Speech. http://vimeo.com/22053820

stevengg• 15 years ago

Business bad? Fuck you, pay me. Oh, you had a fire? Fuck you, pay me. Place got hit by lightning, huh? Fuck you, pay me.

http://www.youtube.com/watch?v=0c3bhh8fqYs

sorbits4• 15 years ago

I recently switched to invoicing per commit (current rate being €40).

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.

phunehehe• 15 years ago

Then you'd have to explain to non-technical clients what commits are, and then it comes to the problem of big and small commits. Some enjoys "commit early, commit often", other enjoys squashing commits into a big one. This solution reminds me of invoicing per line of code.

sorbits4• 15 years ago

Naturally if your commits are not fine grained, as I thought most agree is the recommended style, then this scheme would not be in your favor.

As for explaining it to the client, I’d probably just call a commit a “feature”, but something like “move button to the left” or “make it darker” is also a feature if the code is already written, and “making the code nicer” (to ease future maintenance) is a feature as well (and if he thinks this is not worth paying for, you can hold back on the refactoring, but when he wants you to extend the project beyond the initial goals, you can then point to him opting out on “clean code”, so the rate for the extensions will be set higher due to the less flexible code base).

Anyway, if you do disciplined fine grained commits, try look at some of your past projects and see how many commits you did and what the rate per commit would be given your estimated value of the work that went into the project — I found it surprisingly consistent.

sorbits4• 15 years ago

Seriously, what is with the sudden down-voting of all my comments?

ForrestN• 15 years ago

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.

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.

I think splitting the difference in this way has worked very well for me in several years of client work.

csomar• 15 years ago

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.

Since it's an estimate, I draw the client attention to the following facts:

- If the requirements change the estimate will change too.

- I work on an hourly rate. If I think that the project will cost more, I'll notify you why and by how much.

dools• 15 years ago

I use an hourly rate to calculate my fixed prices based on estimates.

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

The trick to staying profitable is to iterate in very small chunks, the earlier in the relationship, the smaller the iteration.

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

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

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.

nesbot3• 15 years ago

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.

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.

It's much easier to take each new decided feature, say yes and charge for the time it takes.

"Time is money" and that's how you should charge for it.

patio11• 15 years ago

Tips from Thomas, which I have used to the benefit of clients and myself:

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 next engagement with them.

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

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.

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

biot• 15 years ago

It sounds like you prefer fixed scope of work for a fixed price? How do you adjust when your estimate of delivering a specific objective is off? And how do you factor that into your schedule if you have commitments with other clients?

I can see this being a lot different for someone providing a week of SEO consulting vs. a week of software development, for example. Two hours of keyword research always takes exactly two hours. But if $FOO and $BAR are software features which involve third party integration or dealing with race condition bugs that are difficult to pin down, one week can easily turn into much more.

jeffreymcmanus• 15 years ago

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.

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.

Fixed-rate coding assumes that software development is at the same general level of predictability as having the oil changed in your car.

tptacek10• 15 years ago

Any time you hear yourself thinking "I'll quote this part of the project based on my hourly rate", please at least use a daily rate. You're a sought-after professional in a white hot market. You don't do partial days.

A customer that's worth bending that far backwards for is worth a couple hours gratis. Everyone else can just pay your daily.

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.

You have a 1-day minimum. Think of it this way: there is no way 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 for free, or you're stealing it from another client.

jules• 15 years ago

In my experience working on one thing for 8 hours isn't the most effective way to work. I find myself more effective when working on multiple tasks in one day if they require thinking effort. A lot of the thinking doesn't get done when sitting in front of your keyboard, but rather when you are taking a shower or taking a walk. But passively thinking about a single thing during those activities doesn't exploit your thinking potential fully. You can't think that far ahead.

If you have two projects you're working on, you can think a bit on one, and when you're stuck you think a bit on the other. When it actually comes to working, you have enough new material to work for a couple of hours on each project. This working will uncover new things to think about. If you instead work for 8 hours straight on a single thing, then after a couple of hours you'll hit things that require thinking before you can proceed, and doing that in front of your computer doesn't work but taking a walk or taking a shower isn't billable -- and even if it were I'd still get more work done when working on more than one project.

tptacek10• 15 years ago

I don't want to touch this developer workday thing with a 20 foot pole. Work however is productive for you to work. But don't communicate to your customer that you are billable in increments smaller than a day.

riledhel• 15 years ago

I wish I could upvote your comment more. Never thought about this subject this particular way (probably because of my lack of experience). Thank you very much.

foxit• 15 years ago

I liked Steve Friedl's thoughts on this. (Skip to the Billing heading.)

http://www.unixwiz.net/techtips/be-consultant.html

gte910h2• 15 years ago

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.

But once you get it, they're pretty nice to offer to people.

kristiandupont• 15 years ago

I have had good experiences with what we call "Collaborative Contracts": http://www.zealake.com/2010/09/26/pay-less-for-your-agile-pr...

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.

rafski• 15 years ago

My preference is to scope well, give the client a per-project quote and then charge hourly for out-of-scope work.

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.

teyc• 15 years ago

Your overall fee should always reflect competitive pressures.

Your competition are:

1. Other local developers who have the same domain expertise

2. Other local developers who don't have the same domain expertise

3. Outsourcers

4. Alternative technology stacks

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.

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.

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

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.

joelrunyon2• 15 years ago

Bill on value not costs.

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

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.

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.

ansy• 15 years ago

I don't have good citations for these figures, but I'm pulling this out of Stephen Fishman's book "Working for Yourself."

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.

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.

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.

2) Customers are willing to pay a premium for cost certainty even if that cost ends up being higher.

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.

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

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.

harichinnan• 15 years ago

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

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.

robjohnson• 15 years ago

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.

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

Related Stories