How to charge clients: flat fee vs. hourly rate?
watilo.com
watilo.com
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.
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.
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".
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 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.
I also worked for a firm that sold sprints whose point velocity would automatically adjust to account for point value fluctuations.
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.
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'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.
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.
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 do suggest that as a general rule for the OP, don't do this is a good idea.
The value add of consulting ends up working way better than directly charging for a proposal.
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.
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'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 ;)
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.)
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.
* 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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
But once you get it, they're pretty nice to offer to people.
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.
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.
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.
And you seriously charge €40 to move a button to the left or change a few hex codes? You must have some desperate clients.
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.
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.
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.