How to charge clients: flat fee vs. hourly rate?(watilo.com)
watilo.com
How to charge clients: flat fee vs. hourly rate?
http://watilo.com/how-to-charge-clients-flat-fee-vs-hourly-rate
26 comments
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.
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.
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.
I respectfully disagree.
The last company I was at completely turned around when we stopped begging people to let us do their proposals and instead started charging them for the privilege to have us analyze their business, create actionable guidelines (that they could conceivably have anyone implement) and provide a quote for what our services would cost to implement them ourselves. They were welcome to take that strategy plan elsewhere, but when we started charging people for it, we had more clients than we knew what to do with.
People start to see you differently when you value your time, ideas and strategy and don't just give them away. Yes, there are some cases where it's worth doing one gratis, but the vast majority of time, we got more business by refusing to work with people who didn't run through our proposal process.
The last company I was at completely turned around when we stopped begging people to let us do their proposals and instead started charging them for the privilege to have us analyze their business, create actionable guidelines (that they could conceivably have anyone implement) and provide a quote for what our services would cost to implement them ourselves. They were welcome to take that strategy plan elsewhere, but when we started charging people for it, we had more clients than we knew what to do with.
People start to see you differently when you value your time, ideas and strategy and don't just give them away. Yes, there are some cases where it's worth doing one gratis, but the vast majority of time, we got more business by refusing to work with people who didn't run through our proposal process.
We probably don't disagree.
I am making a tactical point, and you are making a strategic point.
Strategically: of course you should structure your interactions with clients so that you are paid for your time, ideas, and strategy.
Tactically: avoid being that firm that wants money just to provide a proposal.
We are literally just talking about different ways to word things.
And while I totally believe your firm "turned around" once you started asking people to pay to get proposals, in my universe, the first purchase order you get from a client comes with multiple weeks of legal negotiation over an MSA. Nobody is going to do that casually.
I am making a tactical point, and you are making a strategic point.
Strategically: of course you should structure your interactions with clients so that you are paid for your time, ideas, and strategy.
Tactically: avoid being that firm that wants money just to provide a proposal.
We are literally just talking about different ways to word things.
And while I totally believe your firm "turned around" once you started asking people to pay to get proposals, in my universe, the first purchase order you get from a client comes with multiple weeks of legal negotiation over an MSA. Nobody is going to do that casually.
I think this might depend on the case.
I've had clients with only a vague idea of what they actually needed, meaning that we essentially needed to design the product before we could quote it. We charged a nominal fee, which was discounted from the project if the proposal was accepted.
I've had clients with only a vague idea of what they actually needed, meaning that we essentially needed to design the product before we could quote it. We charged a nominal fee, which was discounted from the project if the proposal was accepted.
It doesn't depend on the case; it's a question of how you frame the project.
If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation.
Or, you can quote the project "blind" but structure it so that the client bears the risk; for instance, by quoting a fixed number of billable weeks with a "if you tell us by week N, you can get more contiguous weeks at this rate" clause.
Or, if the client is really worth having and the project is good, you can do enough design work to do a realistic proposal gratis, which is what we invariably end up doing, because we don't do projects that aren't worth doing that for.
But in no circumstances should your proposal itself be perceived as having a price tag. One consultant did that with us once and I had to talk my parters down off the wall against ending communications with them right there.
If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation.
Or, you can quote the project "blind" but structure it so that the client bears the risk; for instance, by quoting a fixed number of billable weeks with a "if you tell us by week N, you can get more contiguous weeks at this rate" clause.
Or, if the client is really worth having and the project is good, you can do enough design work to do a realistic proposal gratis, which is what we invariably end up doing, because we don't do projects that aren't worth doing that for.
But in no circumstances should your proposal itself be perceived as having a price tag. One consultant did that with us once and I had to talk my parters down off the wall against ending communications with them right there.
> If you need to design the product before you can estimate it, you propose a design project. You should propose to produce a design deliverable; you can offer your client a price break to skip that deliverable and plow ahead into implementation.
I guess this is ultimately what we did (had they turned us down on the main project, they would have walked away with the design spec). That's the standard policy now.
I guess this is ultimately what we did (had they turned us down on the main project, they would have walked away with the design spec). That's the standard policy now.
Yeah; I think I sounded pretty pedantic back there, so let me just say I don't think you're suggesting anything wrong. I'm just saying, I've seen fledgling consultants accidentally let themselves be perceived as billing for the proposal work, and I'm pretty sure that's a big mistake, worth calling out.
I've ran into a lot of scenarios where a client doesn't know what they want, and creating a proposal for them involves more of my time than it should. So as a result I'll offer consulting for a fee in order to come up with their ideal solution. This in term gets me most everything I need for a proposal as well as helps them to know what they are actually looking for.
The value add of consulting ends up working way better than directly charging for a proposal.
The value add of consulting ends up working way better than directly charging for a proposal.
Based on the rest of this thread it looks like you're main objection is the wording I used (proposal versus some sort of preliminary design). So it boils down to marketing essentially.
I'm just one person and I'm fairly busy so I can't afford to spend the time screwing around with potential customers who are looking for free spec work. There's actually a significant number of people who heard about this web 2.0 social startup awesomeness and want to spec out their amazing idea with no intention of ever paying me.
It usually goes something like; "I think it'll cost around $xxxxx but I can't guarantee that until I've spent a good amount of time breaking it down into it's features with you to reduce risk for both of us and make sure you're getting something you really want."
It's at this point that I require an investment from them. It might not be a huge investment but it's generally a combination of compensation and their time (answering questions etc.).
I guess I just see most projects as more of a partnership to build something great. They bring the domain knowledge and I bring the programming / architecture know how. I won't partner with anyone who hasn't also committed their money, time, and resources. It sets a bad precedent to the relationship and they'll never value my work.
Everyone does things differently though, and I appreciate you're feedback. I don't think we're so far apart based on you're other comments. I stick by my recommendation, but feel free to reject it ;)
I'm just one person and I'm fairly busy so I can't afford to spend the time screwing around with potential customers who are looking for free spec work. There's actually a significant number of people who heard about this web 2.0 social startup awesomeness and want to spec out their amazing idea with no intention of ever paying me.
It usually goes something like; "I think it'll cost around $xxxxx but I can't guarantee that until I've spent a good amount of time breaking it down into it's features with you to reduce risk for both of us and make sure you're getting something you really want."
It's at this point that I require an investment from them. It might not be a huge investment but it's generally a combination of compensation and their time (answering questions etc.).
I guess I just see most projects as more of a partnership to build something great. They bring the domain knowledge and I bring the programming / architecture know how. I won't partner with anyone who hasn't also committed their money, time, and resources. It sets a bad precedent to the relationship and they'll never value my work.
Everyone does things differently though, and I appreciate you're feedback. I don't think we're so far apart based on you're other comments. I stick by my recommendation, but feel free to reject it ;)
My segment of the software market doesn't require that I bill people to develop specs/quotes, but honestly, some types of software involve so much research related to the company, 90% of the project worth is figuring out what needs done, not the doing.
I do suggest that as a general rule for the OP, don't do this is a good idea.
I do suggest that as a general rule for the OP, don't do this is a good idea.
"Cost of doing business" ... which eventually winds up being factored in anyway. I prefer the transparency that comes with listing how much I'm charging for the estimate as a line item w/in it. If they choose not to move forward, then no charge, else I treat it as billable time that lands in an invoice.
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.
I also worked for a firm that sold sprints whose point velocity would automatically adjust to account for point value fluctuations.
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.
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.
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.
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.
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.
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".
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".
For what it's worth, my experience also echoes what Thomas is saying here. When he speaks of larger firms pulling shenanigans around doubling up work or other suboptimal practices...yeah, that's my company.
The only thing we ever billed at an hourly rate was forensic work, and that was specifically done to make up for the reactive nature of that work.
For everything else, it's a fixed rate contract based on the estimated number of person/weeks of work with a clearly defined scope as to what is expected to be done. Our contracting department (which itself is larger than most of the companies we work for) would never want to deal with anything else.
The only thing we ever billed at an hourly rate was forensic work, and that was specifically done to make up for the reactive nature of that work.
For everything else, it's a fixed rate contract based on the estimated number of person/weeks of work with a clearly defined scope as to what is expected to be done. Our contracting department (which itself is larger than most of the companies we work for) would never want to deal with anything else.
I have seen scope change been an issue on 10k projects as well on multi-million dollar projects. All of which in my history would have been better off with an hourly billing.
The number of bodies were talking about makes a big difference, and the larger that number is the more a fixed rate person/week makes sense. Just like the larger consulting firms its all about placing a lot of people for a long time, +/- 1 week here or there won't matter. You mitigate the risk and it makes sense to take it on spread across the team and only as granular as weeks. Agreed your system works really well with those scenarios.
I interpreted the the original post was an individual who provides consulting service where 1 week could make a difference, 20% overage on a 1 month project. The companies aren't necessarily tiny, but maybe the departments within those companies (read budget) he consults with are limited. In this scenario I would favour a good hourly rate over fixed price every time.
The number of bodies were talking about makes a big difference, and the larger that number is the more a fixed rate person/week makes sense. Just like the larger consulting firms its all about placing a lot of people for a long time, +/- 1 week here or there won't matter. You mitigate the risk and it makes sense to take it on spread across the team and only as granular as weeks. Agreed your system works really well with those scenarios.
I interpreted the the original post was an individual who provides consulting service where 1 week could make a difference, 20% overage on a 1 month project. The companies aren't necessarily tiny, but maybe the departments within those companies (read budget) he consults with are limited. In this scenario I would favour a good hourly rate over fixed price every time.
This is brilliant. I'm going to try this on my next freelance gig.
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.)
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.)
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.
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.
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.
* 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.
I really like that middle-ground solution. I might do something like that if I get another free-lance job. Thanks.
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.
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.
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.
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.
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.
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.
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.
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.
> 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."
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."
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.
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.
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.
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.
We're definitely on the same page on flat fees!
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.
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.
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.
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.
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.
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.
Consider charging a day rate. Only you know how many hours it takes you to do a 'day' of work.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
But once you get it, they're pretty nice to offer to people.
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
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.
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).
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.
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.
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.
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.
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.
This just doesn't make any sense to me as a developer, I can't imagine what a client thinks of it, incredibly opaque.
And you seriously charge €40 to move a button to the left or change a few hex codes? You must have some desperate clients.
And you seriously charge €40 to move a button to the left or change a few hex codes? You must have some desperate clients.
Moving a button or changing color was to exemplify for a hypothetical client what a commit is, if said client was “non-technical”.
[deleted]
Seriously, what is with the sudden down-voting of all my comments?
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.
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.
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.
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".
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.
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.)
http://www.unixwiz.net/techtips/be-consultant.html
http://www.unixwiz.net/techtips/be-consultant.html
[deleted]
Clients always have varying project scope and specs, so in my experience hourly rate works well.
watch the Mike Monteiro FU Pay Me Speech. http://vimeo.com/22053820
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
http://www.youtube.com/watch?v=0c3bhh8fqYs
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.
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.
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.