Links

I was recently contacted by my first Greek potential client, wanting to do some new features in a small Django application. I quoted him my hourly rate and he was shocked! He wanted me to quote a fixed price for the features he wanted, and I strongly declined. The outcome?

We ended up working together, he is very pleased with both the results and the money he's paying, and I didn't budge on my initial quote. Here are the arguments I used to support that an hourly rate is better for everyone. Hopefully they will help somebody else as well.

A comparison

I like to link software development to erecting a building, starting only from a plot of land. The process usually goes like so:

Client:

Here's the patch of land we want to build on.

Here's some more-or-less vague sketches of what we want to build.

Can you quote us an exact price for it?

Any engineer would immediately recoil from such a suggestion, however many times software developers, probably anxious to close the deal, will do a wild estimate, double it and add 30% and hope for the best.

Back to harsh reality

Here's my response:

My hourly rate is XX/hour.

I can spend 2-3 hours free of charge, trying to define the scope of what you want.

After that, I will start charging, even for a 5 minute telephone conversation.

The rule of thumb is: If I am doing something which I wouldn't do if it weren't for your project, you get charged for it.

My client was terrified. His first response was that XX/hour is way too much. He mentioned other developers that have wasted his time and money and left him with unusable crap. His fear was valid - how do I know I can trust you?

A valid question

I then presented him with the following facts:

XX/hour may seem too much, but a) I'm good and b) I'm fast.

I use a time meter (much like a taxi driver) to accurately track my time.

I am honorable. I will not overcharge you.

Before embarking on any task, I will give you reasonable estimates.

Those estimates will not exceed 4 hours.

If at any point I realise something is going to exceed my estimate, I will present you with alternatives and you will decide the course of action.

Let's visit those one by one.

I'm good and fast.

Really, if I can get something done in 1 hour where someone else would need 3, do you end up paying less or more? Enough said.

Track time.

I mean it - I press "start" when the editor launch, "stop" once I've checked in. Any interruption longer than 30 seconds and I will pause the meter. I give daily reports (automated, of course) so the client can track the cost and can budget accordingly.

Honor

I could easily overcharge you. I hold all the domain knowledge, and I can claim I spent 2 hours where I spent half. I would probably be able to slip in a dozen extra hours per month. It's not worth it. My reputation is far more valuable than any amount of short-term money. I plan on getting references and leads from a happy client, and any suspicion of being dishonest will ruin that chance.

Communication

You won't have to worry about hidden costs. I will let you know, to my best efforts, what the potential costs are going to be, and you get to decide and prioritise. I will not disappear for a month then come back with a finished product.

Estimation

This one is tricky. I use this handy rule - if I feel a feature is going to take more than 4 hours, I write down "UNKNOWN". Think of it as asking someone to paint a room of unknown dimensions. Any figure he'll be giving you is going to be random. In the case of software, I will need to spend some time planning and thinking about the feature before coming up with an estimate. And you get billed for that time, as well.

This particular client understood this immediately, and he is now giving me very detailed specifications, data schemas, even mockups of the interface. This way he keeps his bill low and he also ensures feature creep is not going to destroy his project.

That last point is of particular value. Any client will have grand dreams of his product. He will constantly ask for new things, and think those were naturally implied from his vague sketches. If you have quoted a fixed price, and you were smart enough to have a detailed contract, you will need to fight him on every step, saying "we didn't spec that". Whereas, with an hourly rate, you can say "sure, let me estimate how much will this be". The client can then decide if it's worth the money.

Uncertainty and unknowns

In software, it is quite expected that unforeseen problems will arise and budgets will slip. There are two ways to deal with this:

Try to factor the risk into your price or

be honest with the client and let him decide what the outcome will be.

With the first way, the client may overpay for something that wasn't really necessary, or the developer must live with the anxiety of overshooting your budget and working for free.

With the second way, the client will need to pay more only if necessary, and he is part of the decision making process.

Being agile

This whole essay is about Agile Project Management. I'm the expert on managing software projects, my client is not, hence I need to educate him. I don't really care about the whole array of tricks available to manage software teams, only about some core topics:

Daily results

Constant communication

Trust

Keeping the tasks small enough to be completed within a day means I can show my client daily results. Compare that to the previous developer, who vanished for 6 months and delivered a piece of crap.

Daily results mean the he can steer the project to where he wants, because I allow him to see if what he thought he wanted is what he really wanted. We communicate daily - once before I start work, having a brief chat about the feature I'm about to implement, and once after I finish, where I ask him to have a look and see if that's what he wanted. This puts the client in power, because he's the one making the decisions, and his decisions doesn't cost a ridiculous amount of money.

Those two items help build trust. The client, seeing daily results and interacting in a professional way, is convinced that indeed my hourly rate is worth it and he is getting exactly the things he wants.

I firmly believe that this way of working gives both the client the best result for the least amount of money, and provides me with the peace of mind that I will not work for peanuts because of a bad estimation made on shaky evidence.

Definitely a comprehensive overview of why this approach makes sense. I might just borrow some of these points for whenever any of my own clients are displaying doubt in this department.It of course only works as long as the client is comfortable with trusting you to be honorable, but then again being dishonorable won't keep you going in the long run.

Yes, please share your time tracker. I have been using Rachota for time tracking and eHour for time reporting. Both are very good, but I am always looking for other open source products that may be better.

Excellent article! I would really like to know what you use for automatically sending daily updates and what you use for timing your work. I'm hoping the timing is done with something more sophisticated than a simple start/stop timer app.

Great post! I've been thinking about things like this recently since my 2 man consulting group has gotten bigger. Thanks for really putting things, I've been thinking into words. I'm not sure what you use for time tracking but we use freshbooks.com, its easy and allows simple client/team time management as well as billing.

Nice, though you'll have a hard time getting work with anyone other than small-time clients. As soon as you find a client that has to justify budgets to his own bosses (and leans on you to do the same), you'll realize the software development world isn't quite what you think it is.

Oh, and there actually is a process to developing comprehensive quotes that are actually grounded in reality. If you want to do big, interesting projects for real clients you'll invest the time now in learning how to budget/quote accurately. Otherwise, enjoy the regular stream of "build a social network/design my website" small-time work.

@Thomas Unfortunately unless you're willing to change it, we live in a Capitalist society. Trust has value, if you're paying more for someone who won't screw you over that's just common sense. Nobody is preventing bosses doing research to see how much what they want is worth, but getting someone honest to do it is worth at least an extra 50%

I also support this way of work. Charging an hourly rate, instead of fixed price, will allow you also to teach your client to get things ready for you and not waste time in meetings that at the end will make you work twice the time you estimated at the beginning.I use www.time.shockoe.com. They have a mac widget and also do billing.

As someone that manages multi-million dollar contracts, I agree that hourly is the best way to go, with one exception. I'll always ask for the documentation part to be fixed price. Everyone forgets the documentation, or sacrifices the hours set aside for it in lieu of additional development time.

this hybrid approach has stood me in good stead on multi-million dollar engagements.. and both parties were happy.

Actually... when I build something, I ask the contractor to provide me a fixed price, not some hourly rate junk.

It's what they do.

When I provide a detailed set of requirements, you should be able to provide me a quotation based on the work needing to be done.

It is the same thing.

What you fail to understand is that I don't do business with people who charge by the hour. I do business with people who know their business well enough to tell me how much it will cost me... regardless of the hours it will take.

In the end, it is the same thing, but I am unwilling to put it out there for some 40% deviation because you don't know your business well enough to quote me properly.

"What you fail to understand is that I don't do business with people who charge by the hour"...

That works out well for me. My company is strictly T&M. I know my business well enough to not role the dice on my ability to estimate the complexities of my clients' businesses. Maybe if I had to choose between laying someone off or taking a risk on a fixed bid I'd take the fixed bid.

There is no upside to be had on a fixed bid unless you add in a huge multiplier that ensures you can't lose combined with a good errors and omissions policy. Knowing my business means not putting myself out of business by doing something stupid - like working with a customer like you.

It is quite obvious you certainly *do not* understand the software business - *most* software projects are over budget and over schedule (the leading cause being feature/scope creep - those new requirements that you think you are so good at writing) and no matter how detailed you *think* your specifications and requirements are, they almost *never* are.

I've been a developer for over 15 years - I'm currently a Project Manager and I write very detailed requirements (both my engineers and my customers have commented on the quality of my specifications) and yet both I and my customers still miss stuff and have to explain it or re-direct my team. This is even with highly-detailed, nearly pixel-perfect screen mockups and paper walkthroughs before we begin.

When you enter into a fixed-price contract with a developer you are attempting to foist your risk onto him - any developer willing to take that deal either doesn't understand his business or is desperate. Besides foisting your risk onto the developer, you are setting up an antagonistic relationship *and* you are asking to *spend more* every time you ask for *anything* that is outside the original specification.

Too many people think that just because its software and nothing is set in stone that small changes must be free (or nearly so). Tell you what, if you ever have an opportunity to build a building, ask the contractor if he'd mine moving that outlet 4 inches to the right *after* he's already placed it, wired it, done the drywall and paint? He *may* do it for you once - heck, he may do it for you multiple times if he's got a long history with you - but the chance that he's going to do it more than once without that history is approaching zero.

"Customers" like you are best avoided. I feel sorry for any developer unfortunate enough to accept a contract from you.

The logical fallacy in your approach is your characterization of certain ideas as 'facts'. These include your being good, fast and honourable. These items may or may not be true, but the client has no reason to believe these claims at the outset of the project. So, your approach seems to be based, at least in part, on a sketchy premise.

Billing-hourly simply won't work.Let's view a project in the perspective of the client.Client wants to add OAuth to his website.Clint meets Developer A. Developer A is a good programmer but with little experience with OAuth, he charges 8 hours.Clint meets Developer B. Developer B is a good programmer and just finished a similar OAuth project, he charges 1 hour.How will the client react?This goes back to the root of the problem: software development is not engineering.

Construction contracting work is much different than software development. You're often talking about solving new, complex problems in unchartered territories, not installing a pool or pouring a foundation for the thousandth time.

When a software developer is solving new problems, breakthroughs and creative "lightbulb moments" are often achieved in short bursts, not linear time. It is difficult, and sometimes near impossible, to accurately determine how much time a new problem will take to solve--especially given the fact that many obstacles only present themselves halfway through the process.

Additionally, property developers are EXPERTS at the business of construction. They are experts at providing specs, having realistic expectations, and understanding what goes into the development process. However, people in business consulting a "tech guy" are rarely experts in software development. It's not uncommon for the client to be completely incompetent in providing specs, overly zealous with feature creep, and having no idea as to understanding the time/money demands.

This is an interesting approach. My employer is a large B2B firm with an existing product. Most of our custom programming work for clients is in the form of tweaks and enhancements, so our process is a bit different since we're not building something from the ground up.

We gather requirements from the customer, write up specifications, agree on them, then provide an estimate. Customers need to know what something is going to cost -- they have a budget they work with, bosses to report to, etc., so it's important to them. However, as you point out, it's not practical to provide a flat-rate price on development. So along with the estimate, we clearly inform the customer that it's just an estimate, and they will be billed for the actual time spent.

To CeeDouble U - I work with highly skilled, highly paid professionals. Experience has shown that no matter how good you are, things will be missed, need to be tweaked, etc. To assume that your specs are detailed enough, and clear enough so that a developer can make exactly what you envisioned is not realistic. It shows a lack of experience and professionalism, and a diminutive attitude towards your business partners. As someone else pointed out, you are attempting to hand your risk off to the developer. You also falsely assume that your specs will always be 100% right, and the developer will understand them 100%. Because the developer eats the cost of additional work, your argument implies that if anything goes wrong, it must have been the developer's fault. Sorry to say it, but most respected companies would not work with someone like you. It's just not the way business is done.

When I worked as a contractor (copy and design, but same problem) I combined the two approaches. Some clients need a flat price. So they'd get a proposal with a fixed dollar amount with very specific details on what that included -- and a bulleted list of what that did not include. Then there'd be a clear note of the hourly rate if we went outside of this list.

OR if they preferred an hourly rate, I'd say hourly rate is this -- not to exceed X amount for this project. That way if scope started to creep I could remind them of the budget limit and give them the choice of proceeding for more money or setting the new requests aside for a future phase.

No matter how you slice it, you're going to have to pay me a fair amount of money to do a goodly amount of work that you can use. No matter how I bill, we're both taking a risk. In my (sometimes unfortunate) experience, being clear and precise about the scope from the very start of the project matters a whole lot more than the billing method.

"Actually... when I build something, I ask the contractor to provide me a fixed price, not some hourly rate junk.

...

What you fail to understand is that I don't do business with people who charge by the hour.

...

Just sayin'"

To the people saying this ^^^^:

Honestly?

Almost every contracter charges by the hour. They however will give you what we in the business call an *estimate*: how long they *expect* it to take. If you knew the business that well at all, you would at least know that.

OP, GREAT ARTICLE! You took a lot of fluid concepts that were drifting around my brain and solidified them into a procedure and a few guidelines packaged and ready for use later.

Also, to the guys saying "but the client not know if he fast and smart and honor." Well duh, they don't ever *know* that when they first meet, and charging a fixed rate doesn't mitigate any of the client's risk. Does the client not realize that when DevA quotes xx hours at yy/hour, and DevB quotes zzz total, DevB has simply made those same calculations opaque? I'd assume that a fair amount of them miss it.

This is where those things called "charsima" and "people skills" come in, and I'd be willing to wager that a mediocre programmer with great people skills gets a lot more work in this domain (I'm assuming a light-medium complexity web app). When you are confident, knowledgable, and up front with people they easily pick up on it since most of them are the opposite when it comes to their technical needs. :)

Well reasoned, but that's not how the business world works, so good luck telling people their projects are totally open-ended but don't worry because I'm fast" . The right answer is "give me a requirements document and I will quote a price. If you don't have a requirements document - I will bill you hourly to get to that point". Determining the scope and requirements are the only time an open-ended hourly billing is acceptable IMO.

Very good reasoning overall, and probably the best way to do this. I don't know why clients should be afraid: the example of building something physical is perfect: your plumber won't (usually) charge you by "installing tubes" but by hours spent in doing it. Software is more similar to this than most (non-software-ish) people realise. How are your experiences with other employers? Were they also able to "see it"?

I think this is a very well written article. I can see how regular communication is important, depending on the project I can even agree with daily updates.

My one thought is that as a developer I agree to do a project, with a set hourly rate, I give the client an estimated time line, and I communicate regularly. The client continues to request new features, and agrees to pay the fees. Here is the question: is there ever a point where you tell the client that the project is so much larger than originally planned and that you are concerned that they may not actually be able to afford the bill is it acceptable to ask for a portion of the project fees before completion?

However I like to make this comparison. You are getting a new kitchen put in your house, and you ring up some builders the first builder says "well I am fast and honest and I don't overcharge but I cant give you an estimate". The second builder you ring up says "well I can do it for $2000" and the third builder says "I can do it for $3000". Who would you pick?

The point is fixed price quotes are not fair. But customers are risk averse, and they compare quotes. How else can they shop around?

As a business when you make an estimate you take a risk and sometimes you will get it wrong.

If a client is considering different contractors for the work they are going to need a quote as they need a way to decide between options.

Some customers, once they have worked with you for a while will be willing to pay for the amount of time spent.

Not much left to add imho as this is a good description of the best practices regarding contracting that emerge when freelancing as a developer. One thing though: may all your clients be like the one in your story... :-)

What do you use to invoice clients?Currently, I use CurdBee, which is really easy to invoice with hourly rates and receive partial payments for work covered. Only wish is they support time tracking which would make the ideal suite for me as a freelancer.

"I get freelancers to do work for me and I wouldn't start if they wanted to bill hourly"

Really ? I like how you put the problem of trust only one way. Not sure I would want to do business with someone like you. What about the freelancer trusting you that you don't change your requirements 4 times per day and expect them to work for the same money ? What about learning and knowing about your domain enough so you can place a sound judgment on estimates ? Oh wait ... you expect the freelancer to take risks for your incompetence in the area ? Ha ha ... Why ? Because you think that is what freelancer means ? Taking huge risks for clueless customers ?

Interesting article. I think his approach is consistent if we understand that the customer is hiring a programmer. A well-organized, accountable programmer that will provide task estimates, track his work and get directions about what he should do next. The other duties are still with the customer: project management, requirement analysis, quality control. Some comments seemed to be related to engagements where the customer prefers to pay for someone to do the entire work, not just the programming part.

This is spot on and EXACTLY the way smaller clients should be dealt with. IF someone insists upon a price and has a small budget, we work a simple change doc into the contract so we don't get killed when the client want to make tiny adjustments based on their 6 months of experience. (NOTE - after building apps/software/websites for 18 long years, the times of "the client is always right" are OVER. We DO NOT let the client stay in control. We carefully create the illusion of control and go about doing what needs to be done.

@c0demonkey - actually, that is not true. I started my professional life as a developer, like in the days of COBOL. The business wasn't really for me.

I run my own enterprise today. It is pretty fun this... and I deal with the likes of hourly paid folks all day long.

I don't disagree with what is being said, though I don't think anyone should charge for anything hourly. From a business perspective, it isn't a good idea. I could write a novel on how many better ways there are to do business.

As a business, however, when I ask for something to be created (whether it is a bathroom or a website) I will tell you what I want on the floor, what I want for a ceiling, and I will tell you what I want to sit on and take a dump.

If you cannot tell me how much it will cost to put that together, then I am talking to the wrong person.

If I want a website, I will give you detailed specs. You will tell me how much it will cost to produce.

My experience with most software developers is this... a wall isn't a wall for them, it could be anything.... and likely the idea of the wall will change 30 times... that is halfway through building the "wall" he will come up with a better, neater, fancier way to build the wall.

I don't care. I just want a load bearing wall.

But round and round we go... and if we talk about scope and creep, this is where it comes in.

Not me as the client, but you as the developer... saying "it would be really neat if..."

or

"let's try ajax on this instead of...."

If you don't get my point, it is this... if I pay you by the hour, there is no incentive for you to do this thing quickly.

If you bid on a project, you have a fire lit, or should do, and might be better able to remain focused.

"If I want a website, I will give you detailed specs. You will tell me how much it will cost to produce."

Fine, I give you a quote for your damn site, you agree and I build it according to your ill-defined, vague and inconsistent specs by filling in the blanks myself. You see the result and say "what's this crap, that's not what I wanted, I'm not paying a dime for this". It may not be what you wanted but it is fully consistent with what you described (modulo the initial inconsistencies that I resolved using my own judgement).

"I don't care. I just want a load bearing wall."

No you don't. You want a specific color shade that you can't specify precisely but "you'll know it when you see it".

"if I pay you by the hour, there is no incentive for you to do this thing quickly"

And if you pay me by the project, there is no incentive for you to make up your damn mind from the beginning and not change the specs ten times until you're fully satisfied. See how this works ?

I thought I’d throw in an idea about pricing options for development work.

I’ll also put up front that I’m not a freelancer; I come from one of those consultancy companies Steve refers to … although the chance to charge out at 3 x $77.52 per hour would be nice; I can’t say I’ve managed it yet :-(

Anyway, last year when looking into how best to structure commerical agreements for Agile Development work, I came across the idea of Target Priced Contracts.

The concept is that fixed price contracts mean the developer wears all the risk and therefore will need to add a buffer to mitigate the risk (ie. 30% on top, or the other multipliers described above).

Rather than take that approach, this method shares the risk between the client and the developer…

Once the work is scoped and an agreed set of deliverables defined, a price is set based on your reasonable estimate of durations (the target price, based on your daily rate). This price is signed off on by the customer. For the example, lets say 10 days, $750 per day, target price $7500.

During the project, rather than pay your full rate, they pay your ‘cost’ along the way. In our situation, thats the salary of the developer plus a little to cover overheads. For freelancers, its the rent plus enough to feed yourself and cover general expenses. (for the example, lets say $300 per day)

This will naturally leave a gap between what you’re paid and what the target price is (10 x $300 = $3,000 :- final payment is $4,500). If the contract finishes on time, then this is the amount the client pays you at the end and we’re all happy.

If you are outstanding and find faster ways of completing the work and finish ahead of time (say 8 days), the client still pays that amount. They’re happy because they paid less overall for the project (8 × 300 + 4,500 = $6,900) and you’re happy because you made the same amount of profit for less work ($4,500 for 8 days work instead of 10) and can get onto the next project

If however there is scope creep, things get tricky, something goes wrong and it takes longer than 10 days (say 12 days) then the client continues to pay your costs until you’re finished (an additional 2 × 300), but only pays the same final payment ($4,500).

So, they pay more (12 × 300 + 4,500 = 8,100) and your profit margin goes down (4,500 profit out of 8,100 total payment instead of 4,500 out of 7,500). So, you both feel some pain, but its not unfairly felt by either party.

This means that both parties are focussed on getting a good result – clear requirements, efficient delivery.Its turned into a long post … sorry! Hopefully it fuels some idea’s and further thought for everyone though.

i represent a software development company and we undertake bespoke development work for clients of all sizes. one man bands to enterprise clients.

we frequently undertake fixed price bids and those have worked very well. as long as there is a good agreement on scope creep and change management, an experienced developer will NOT NEED to load risk into his estimations.

we dont load risk and we are transparent about that. what we do is we give an estimate and a tolerance for the estimate for which the price holds true.

however i think most posters are missing an important point made by the OP and that's his way of working is not significantly different to working on fixed price.

he too gives estimates and his tolerance is 4 hours - that is as good as a fixed price bid.

lastly, you will find it very difficult to undertake T&M bids for enterprise. they will prefer fixed bids.

This article is quite refreshing considering fixed priced bids and itemized "Feature based" pricing is all the rage lately. I agree somewhat with Yadu but I think that it is really a game of semantics when you are dealing with a client. The term "Bid" or "fixed price" rings bells in a clients head that they can shove as much as they want into the job after the fact (even if there are terms contradicting this in the bid). We never use the words "bid" or "Fixed price" and when we itemize features we do so by saying how many hours the item will take. We prefer to always use the term "Estimate". For larger jobs we will create a proposal containing an estimate inside.