Good article but it fails to address two huge issues with hourly pricing and why I don't price by the hour.
1) Something that use to take me 10 hours to design may now take me 2 hours. Should I discount the knowledge and skill it took to learn that? I'd be earning a fraction of what someone else gets because I'm more efficient.
Raise my hourly rate you may say? You can really only go so high with your hourly rate until clients will look at you funny. $100, $125, $150, $200 - anything above that as a freelancer and you'll have problems landing clients.
2) Hourly rates also limit how much you can bill - there are only so many hours and days in the year. I prefer fixed pricing as well as calculating in variables to increase the price. So if I can tell a client takes long to respond or give feedback, I add on 10%. If there are 3 or 4 people who are giving feedback, I add 5% - etc.
1) Nonsense, you raise your rate as you prove yourself, as someone who bills at $185+ -- clients aren't idiots. They understand that if you can do it in 1/5th the time and cost 3x the money, they are still saving money. Clients can do basic math. The only time you need to worry is if you can't prove your skill (bad references or new to market).
2) No professional ever uses the phrase "hourly" -- it is always T&M (Time and Materials). Most professionals with enough experience work in 'standard days' or 'standard weeks' on longer contracts. Last contract I did was billed at 7700 a week, no hourly accounting.
... some of what you mention (variable bill adaptation) is tricky as hell, and on FFP (Firm Fixed Price) contacts, it can be outright illegal without clients signatures at every change point. This is a reason home renovators always have change request forms with them.
~ Beyond all that, FFP puts you at odds with your client, you want to fuck them by charging as much as you can and working as little as you can -- they want to bleed you for as many hours as they can while keeping you bound to the initial contract. Nothing like starting a contract as sworn enemies.
Exactly. I was just going to raise the same issue as #1.
From freelancer/agency point of view: why are we supposed to charge less only because we have skills to do things faster?
From client point of view: what's their motivation to do things as fast as they can? I'm paying them for each and every hour anyway so why would they rush?
Agree wholeheartedly, I wrote something similar in a comment above, but the title of OP made me cringe really hard. If you are in an ocean of samesies it might be worth to fight in hour prices, but if your fixed price / competitor hour is cheaper, with you making 10 times more, DO NOT LIMIT YOURSELF.
1) That is a big problem. Really hard to convince people you are more than 3x as good as the 3x cheaper alternative. But than again lawyers manage to do it. Why would web developers not figure it out? ;)
2) Yes. It does not scale in a way "startup people" are used to. It's just part of the deal :(
This is exactly why you might want to consider moving to weekly billing. Bill for a weeks work, as long as the deliverables come in does it matter if the week was only a few hours long?
You can either charge a lot per week, or less per week and still fit in more clients
no, you are saying that next week I will work on the deliverables we agreed for the week. And I will deliver them. And they will bring you this much benefit.
If I need to go and hire two guys and work nights to do it, I lose. But I only lose a limited amount.
SO, I guess I really am saying work fixed bids of one week projects.
So if you finish them in one day - you don't send them to the client until Friday?
I imagine if you did them in a day or two the client would be asking why they paid for a week of work and if they can use the rest of the time somewhere else
I agree...but. You probably only ever get to fixed pricing (successfully) once you've learned to value your hours, which you probably learned by years of selling them.
And here's one reason that overrules all 5: because the customer doesn't like surprise pricing.
Their business is knowing how much something is going to cost. This isn't exclusive to the project I'm working on with them. This extends to every aspect of running their business. Whenever I see a business owner angry about a new government policy being considered that would impact their business, they're rarely upset about the policy itself and more upset about the vagaries that come with being affected by the enigmatic legislation process. Small businesses and even medium sized businesses flourish under consistent understanding of their costs.
Even if I'm not as big a shop or even as talented a shop as the next guy, I know almost any company is going to go with me because I will give them a number and I won't deviate from it unless they, themselves, have deviated so far from the scope that I have to forewarn them that the project needs to be re-estimated. At which point they understand because they're a business owner too.
Moreover, it just feels sheisty. It feels like a bait-and-switch. If I severely underestimate my costs on a project, I shouldn't be passing that mistake along to the customer. It's not their fault. It's mine. I'm the expert here. I'm the professional in this field they hired me to be the professional in. How can I go back to them and ask for more money because I didn't prove myself to be professional? It's not their concern how I run my business, nor should it be.
Great point. Giving or receiving surprises is kryptonite to consulting relationships.
Part of the value we must provide is be the guide to finding and doing the things a business needs to move forward, and help communicate the risks, unknowns and things that have to be figured out before ever starting them so the customer gets to participate in things as an experiment.
To put it a more geeky way, pretend you're building an API. Would you want your two disparate systems (your services, and the client) to "know" about each other's internals? Of course not. It's no different for business interfacing. All the client wants to know when it inputs Money into You is
1) What are the deliverables?
2) What is the value?
So that's all you should be concerned with "exposing" to their side of the API.
Our "response" to this is radical transparency. Client should be able to track the progress in almost realtime.
The problem is that usually the business is not sure what it wants then the project starts - the scope is not well defined. And it's ok. This is something that all stakeholders learn along the way.
And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. The second part of this is a mutual understanding that scope is gospel. This means the client has a clear understanding of the end product and what problem it's going to solve, and you're going to have the same understanding. Changes to the gospel mean changes to everything else.
Obviously running a business is part philosophy. If you don't mind a customer looking over your shoulder throughout an entire project, second guessing your time usage, then sure, I can see how an hourly situation might work. I despise that, and so I've found fixed pricing to be my preferred approach (which has the apparent added benefit of being very appealing to most clients).
"And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault. "
Bingo. Hourly or fixed doesn't matter here. Both will mess up the relationship because there's no value delivered in the clients eyes.
As for the micromanaging; some customers like running a daycare for adults and babysitting everyone. I prefer to not be in these relationships and in exchange be proactive with our updates.
> And my response to this is that if you don't have a scope clear enough to accurately figure out your project's pricing, that's your fault.
How do you get around companies wanting a fixed price without knowing entirely what they want? As a freelancer I can't spend 2-3 days of meetings and spec writing only to lose the project because they preferred an agency/another supplier.
If I had clients who would pay for a 'Consulting' phase of producing a spec (which they could then send to other agencies/freelancers) then I could see this working, but those are like unicorns.
To people who build websites, scope means technical scope--the features, functionality, design, backend etc. A precise technical scope makes it easy to calculate a price.
But to people who buy websites, scope means financial scope--a "$100,000 project" vs. a "$20,000 project." They don't know precisely what they want...because they don't know what is possible. That's why they are hiring you!
So you learn as much as you can in the RFP process and propose your fixed price based on that. Unless the client or RFP is a terrible lie, you should be able to get it in the ballpark.
From there, closing the sale depends on your ability to convey that your expertise will help the client get the best possible product for this "scope" (i.e. price). If you want to cover a few more bases, you can provide some optional levels of effort for the riskiest items, or "nice to haves."
It's possible to be just as transparent and flexible under a fixed price contract. And if changes need to be made, they can still be made on a change request or contract amendment.
The problem with this post is the word "hourly"; the author means "time & materials". It's fine to bill based on your time, but unless you're a furniture mover, you shouldn't be doing it in hour increments.
This is a hobby horse of mine, so I'll spare you the retread:
I agree with everything in the article. However, my experience as a coder has been more positive on fixed-price contracts than on hourly contracts. On hourly contracts, which I started with and have done more of, I tend to feel like I'm bleeding the client with every hour I spend, so I rush. The quality goes down and my stress levels go up. I don't spend time figuring out the best reasonable way to structure my code, and I don't play with interesting corner cases for my own amusement. With fixed-price contracts, I know the client isn't paying for my desire to write the nicest code I can come up with on that day, nor for flights of fancy onto tangents that may be more about my own enlightenment than about delivering value for them.
I realize that I should be able to fix my issues with hourly billing by separating my work into "value for client" and "my own enlightenment" for timekeeping purposes and only billing for the former. In reality though, the effort required to be constantly making this kind of judgement about everything I'm thinking about seriously disrupts my flow, and seems to be just as much effort as estimating a project ahead of time.
When I have a good relationship with a client, I can try to get the best of both worlds by giving them fixed-price-style estimates, and then asking for more money if the project ends up being more effort than I thought.
1. Clients hate them. Very rarely do you they understand the difference between paying for your time and paying for the finish product they are asking for (and it's correlation to your effort/time).
2. I much prefer day rates over hourly rates. If something can be done in a few hours, then it should be free.
3. If you are a good developer and can develop quicker than most than doing a fixed price has a huge upside to it.
4. The number one reason for hours/days going longer than expected isn't based on developer/designer competency, but rather project management and lack of clear requirements (or changing requirements). Pinning commercials against the root cause of most delays can cause really messy situations.
If you're working with startups specifically, I typically do the following:
1. Give a rough estimation of what their project will cost.
2. Tell them that with this estimation they get X number of designer/developer days to build their project. They get to see an update of the project every 1-2 weeks and can decide how they want to use their budget accordingly.
TL;DR - I tell my clients that they are paying for my team's time and not for a web project. Otherwise, I do a fixed price and massively buffer it.
1&2: Hourly is just a mark that the guy who wrote the article is clueless, he meant Time and Materials of course. Hourly, Daily, Weekly, Monthly, lets not worry too much about he subdivision of labor.
3: This is true, but it puts an ugly arrangement, you want to overcharge as much as possible, and work as little as possible. The client wants to "drag out" the contract to try to maximize the value of their investment. You are enemies from day 1.
4: This is 100% true, but unrealistic, the client often doesn't know what they want, they want you to help "defog" their vision and express it in technical terms.
Because a client who is reliably paying you for days of work is worth a free hour or two now and then, and because the precedent that you will work for hours instead of days will come around to bite you in the ass later on.
This approach is great - giving small things for free, but isn't working for every clients. It's horrible for you when your customer is't paying a lot (small projects, low prices etc.). They are overdemanding, don't like your work, put a lot of changes and thinking that you should't do it for free.
As a counter point, i would argue that if you're billing on an hourly rate, you're limiting your earning potential as there's only so many hours in the day and a client will compare you to others in your industry if you charge by the hour. I'll continue to beat the drum of value based pricing as patio11 does too. Deliver a project that brings the client £10,000 worth of value and charge £1,000 for it and they wont give a shit if it takes you 1 hour or 1 week.
Since I have trouble with the value extraction thing, something I also put in perspective is how fast can I finish this against the normal standards? If I can work much faster, have a well established codebase will all sorts of shortcuts to the solution, fixed price will allow me to get paid 10, 20 times more with it actually being cheaper than a normal hourly rate would cost.
Hourly makes you always take your time, I prefer to be able to compress 10 normal development hours into one as much as possible and have more free time.
For too long I have been punished for working fast with hourly rates, I avoid it like the plague. The next step after this are products.
How much value does the new feature bring to the client ?
Easy one: increase their conversion rate for google searches of keyword "blue widget" (ie google -> landing page -> credit card charged) by 5%. YOu just made them 5% of their annual turnover. Charge them a lot
Harder one: (Anything away from sales is always going to be harder to measure) Implement a simple custoemr support online chat featuire (you know the kind) - allows their support to deal with >1 person at a time, and reduces the "waiting" queue on the phone system to zero. Value? Dunno.
Feel around by talking to the VP of customer service or make a judgement call like "not having to hire another five custoemr service people"
At least in the web world (which is the only one I have a whole lot of experience working in), there seems to be an interesting progression that developers go through if/when they leave the corporate world and try things on their own. Recognizing that fixed price development is very often a nasty trap is where many developers and organizations start to actually wonder about how their business model could change.
1. Fixed bid projects. Attempting to offer custom development as a package deal seems like a great way to undercut the competition; in reality it's anything but, and (among other things, including those mentioned in the article) reduces the perceived value of your work, which hurts in the long run.
2. Hourly consulting. Better, and works well for quite a while, allowing you more flexibility in your engagements and with your rate. This might even be a good long-term strategy for individuals; however, it requires very good planning and workload management, which are more difficult than many people think. It also does limit your earning potential, but this is much more of a factor if you expand into a consultancy, in which case your expenses will drop your margin.
3. Product/subscription service development. Often the subject of HN discussion (and rightly so), the prospect of recurring revenue is obviously a powerful one. However, even more than when selling development services, this requires a solid understanding of your target audience(s) and the ability to market to them effectively, in addition to understanding end-user customer support.
Where do we go from there? I personally have no clue; I've been slowly climbing this ladder myself.
This is pretty much the exact path I took. It becomes really interesting when it finally dawns on you that there's very little difference between building and selling a 3 to 4 figure / mo SaaS and offering a value-oriented consulting retainer to a few clients. (See http://draft.nu/revise/)
While retainers aren't exactly turnkey (they'll generally require human effort per account per month), the same positioning, marketing, and pricing rules you'll encounter selling software apply.
My experience has been the opposite, and I think fixed price benefits both sides. Of course, it depends on the circumstance. Fixed price and hourly each have their place. I will say that a fixed price contracts can be tricky.
My primary point of reference is a medium sized fixed price project that was delivered early, and the customer loved the solution and came back for more business. I've also worked countless hourly contracts from both the customer and consultancy side.
1. Assuming a fixed price project requires a big up front spec is wrong. Follow lean/agile principles, iterate and refine. The contract should specify high level basic functionality and the problem being solved.
2. Hard to quantify, but hourly is plenty risky having worked both sides of the relationship. I've seen hours and hours burned building things that are not at all necessary. A fixed price helps everyone focus on building precisely what is needed.
3. Hourly rates put customer and consultant's priorities in line? From a short term view, if I'm paid hourly I'm going to milk the deal. If the consultancy is taking a long term view, everyones priorities are in line. Consultancy delivers fantastic product on time, it's a win by bringing the customer back, and word of mouth.
4. Again, it's how you structure the contract. If a giant spec is written up as part of a contract, you're doomed before you begin.
5. I'd argue the fixed price is a risk balance between the customer and consultancy. If the consultants finish early, they're rewarded. If they are late, they are penalized. This is in contrast to hourly, where it's win-win for the consultant.
If you don't know the contractor well, you don't know how hours worked translates into productivity. The programmer could be a 10x programmer or string you along saying things took longer than expected and suddenly your budget is bloated. I like a happy medium of fixed price with variable scope or a budget range with variable scope and finer details discussed in the contract.
The model that works best for me is a fixed price based on initial scope with additional fixed or hourly billing for 1) tech support and 2) additions to scope or changes that occur after sign-offs.
Hourly billing is great until it comes time for final payment, which is when the client comes back and says "ok, why did x take you 3.267 hours and y took you 4.535 hours. Can we shave off some of this and that, oh, and this, too?" "Ok, this total is a little more workable, but I'll tell you right now that our billing department won't pay a dime more than $z, so you better adjust your rate or take off some more time."
Then you end up getting screwed out of money. This happens even when you do an estimated cost and have clients pay you 50% of the estimate up front. Fixed billing sets the expectations of how much work will be done and what the client should expect ahead of time, so it's a much easier pill for them to swallow when it comes time to pay up.
There's a big misunderstanding here, which is that fixed price implies a waterfall methodology. This is not true. All a fixed price does is cap the financial scope of the project.
But the tradeoff is that you need to vary the technical scope. For this reason, agile methodology is actually the best way to do a fixed-price contract. Every sprint is an opportunity to reconsider the technical scope to stay within schedule and budget.
This does reduce risk for the client. Most companies have much more serious limitations on budget and schedule, than they do on their imagination for what an ideal site should do.
And even if the client does decide they want to spend more money to get more functionality, they can just execute a change request or amendment--a process that is much more controlled and transparent (from the client perspective) than just working a few more hours.
Any project has a defined scope and set of requirements. If you start the project before these are defined, you're dumb, because you have no idea what you're working on.
I always draft a requirements document for my freelance customers, and spell out exactly what I will do for exactly how much money, by a deadline. This document also says in no uncertain terms, that any deviations will result in a new set of requirements, and thus, a new price.
Hourly rates punish you getting better (why shouldn't I charge the same I did last month for something, despite having found a way to do it twice as fast?) and they open you up for all kinds of "why is this taking you so long" or "I'm paying you X per hour! That's more than I pay my shrink!" comments.
I'll admit there's a certain "fudge factor" but the more experience you get with requirements gathering, the less of an issue it is. Ultimately, this is the difference between a "Developer" and an "Engineer".
It's not about the lack of skill on the supplier side. It's usually the client that is not sure how exactly the project should look like. And that's ok - he does not need to scope out every detail - it can be worked out along the way.
15 years of consulting left me dreading reading this article a little.
There is no set formula that I've found. I'm open to finding it. Until then better I get at business, the better I get at all these different ways of "earning" formulas.
You exist to help the customer get the result they want, who usually don't know what they want.
If you don't know what you're doing, or worse, don't know how to help the customer find what they need, the meter can be run up hourly, or lose your shirt fixed price. Both are poor delivery of value for the customer in retaining a sustainable, no-surprise-giving, stable business partner.
The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills.
Still, businesses are great customers. They're a lot more logical than consumers. They especially listen to anything that adds value to their business.
What's this hokey "add value" thing?
One definition is:
Saving or making your customer money, or time.
Time? Yes. The cost of their employees is the #1 cost in their business.
So, if person x spends 5 hours a week generating a spreadsheet at $15/hour, and there's 50 working weeks a year, this spreadsheet cost them $3750 in 1 year.
That's just $15/hr!
If I spent 10 years learning to do something in 2 hours, should I charge the customer the 2 hours, for the 10 years it took to learn, or say.
"This is costing you $4000 a year, I can get rid of it for $1000 permanently".
If it's a large company, you can even look at the savings over 2 or 3 years.
See? You're saving your customer money. Get the sign-offs on any solution from the ground up to the signing authority and put good decisions in front of them.
One reality is you end up doing a bit of both fixed and hourly. The better you understand your clients business, data and processes, the more fixed you can go.
With new clients, for example, I do small fixed price projects to minimize risk for the client and to build small momentum building wins.
When customers see the value themselves, instead of trying to trick them into liking you, what they pay me becomes far less of an issue. Some still prefer hourly so I just quote the total number and let them imagine what the hourly rate is. Some still want to know the hourly rate and I let them know we work extremely fast and have 15 years of experience each.
Regardless of hourly or fixed, if at the end of it they look at it and say "yes, they built what I asked but it wasn't what I wanted", customers will start doubting good decisions in the future because your inability to guide the canoe better. This is a bigger threat to your business than anything, especially if you want to stay in consulting.
Help your customers spend their money with the care as if it was your own, and you'll find yourself with as many long term consulting customers over the years that you can handle.
Mentioned it before in another thread here: This makes sense when you have a well established business that's tweaking it's processes. Impossible when building an MVP and/or experimenting with a new product/service.
I currently build MVP's, in 30-90 days if it can be pushed that fast. I'm a lean practitioner for over 10 years starting in manufacturing.
You want to help your MVP's become long term customers by helping them grow and make money. If they don't get this, it's a real risk to their business, let alone your relationship with them.
For MVP's: You have to invest in understanding your tools and how long it will take to identify and build only the features that customers can't live without.
My original consulting business is for established businesses, but they were all smaller 4-7 years ago.
"build only the features that customers can't live without" - who makes this call? What if you disagree on this? What if the customer learns something new after 2 weeks and needs to change the scope?
If it's truly a lean MVP, the end user/paying customer. Is it an MVP is if no one is getting out of the building and talking to customers/users before designing or writing a line of code?
Completing the problem solution fit, product market fit, and engaging in customer development prior to writing a line of code has to happen if we are wanting to be honest when using a term like MVP.
If you feel this is a binary issue: ultimately the person signing the cheques make the call, and you have a choice on whether to accept said cheque for managing said potential headache.
The grey area in between:
If the customer wants to do whatever they do and call it an MVP by sprinkling the lean dust on it to justify it, you have to recognize it for what it is and either adjust your approach, or decide if that kind of work is something you can live with. No process can correct development pagentry, management/design by committee, and failing to get out of the building.
Building an MVP requires getting through the build - measure - learn loop as quickly as possible.
Interrupting you mid-cycle if it's that ground breaking (customers are saying I'm trying to find a way to give you money) requires answering "Did we really understand anything before hallucinating an MVP ourselves"?
It leaves a few options:
- Change the scope
- Change the deadline
- Change the budget
- Trade features -- something that was important can no longer be important as a result of what was traded.
Avoiding this is the business skills development we all constantly need that I mention to in my initial post.
For me, I try to make sure I understand, and the customer understands why we're doing the things we want first and hopefully minimize the above.
I don't rush customers into building something, but rather rush into understanding what our experiment is, and why we're testing those things. It helps create a checklist to test our assumptions/discoveries against when the next great insight comes in.
Dont you think that what you are describing sounds like a huge overhead. Rather then tweaking the product you have to "trade features" with customer.
It's also something that is very difficult to scale. It's hard to expect that every person who is good on the job is also good in negotiating with customers.
Love this quote: "The second we are in consulting, we're in business, not an hourly employee. It's a comfort net to say otherwise of not having to learn business skills."
I think a lot of freelancers (myself included) go through the following process:
1 - Start out with fixed price estimates based on time (I think this will take 10 hours, so I estimate £1000)
2 - Develop good relationships with clients and start just charging hourly for work done (This took 12 hours, so here's a bill for £1200)
3 - Take patio11 (et al)'s advice and start charging based on value (this 10 hour job will increase your profits by £100,000 so I'll charge you £10,000)
In short, hourly IS better than fixed price time based estimates, but fixed price value based estimates are even better.
But than you are introducing overhead of deciding this. For obvious reasons this is something that needs to be negotiated with a client and documented.
The only problem with value pricing is its not for every client. Its very hard to sell a client on value - especially if they are skeptical. And if your work doesn't increase value then your in a sticky situation.
There are a lot of counterpoints here saying that fixed-price is better for us as consultants.
But this article is saying hourly-billing is better for the CLIENT.
I think this is an important distinction. Obviously there are advantages for us to doing value-based fixed-price billing, but that says nothing about the merits to our clients. If you don't do hourly billing, you should be aware of these potential gotchas, and be aware that some clients won't work with you.
If you are ten times faster than other developers, fixed price per milestone lets you charge ten times as much. If I'm writing a custom map screen for the first time it is going to take me all day. If I'm writing it the 12th time it is more like an hour. I can charge a lot more for a custom map screen than an hour, however, even an hour at the highest hourly rate the market would bear.
1) Something that use to take me 10 hours to design may now take me 2 hours. Should I discount the knowledge and skill it took to learn that? I'd be earning a fraction of what someone else gets because I'm more efficient.
Raise my hourly rate you may say? You can really only go so high with your hourly rate until clients will look at you funny. $100, $125, $150, $200 - anything above that as a freelancer and you'll have problems landing clients.
2) Hourly rates also limit how much you can bill - there are only so many hours and days in the year. I prefer fixed pricing as well as calculating in variables to increase the price. So if I can tell a client takes long to respond or give feedback, I add on 10%. If there are 3 or 4 people who are giving feedback, I add 5% - etc.