6 Replies - 24844 Views - Last Post: 23 June 2010 - 01:58 PM

#1 Nykc  Icon User is offline

  • Gentleman of Leisure
  • member icon

Reputation: 737
  • View blog
  • Posts: 8,648
  • Joined: 14-September 07

Hourly Rate -vs- Flat Rate

Post icon  Posted 27 May 2010 - 08:01 AM

*
POPULAR

I have been resurrecting my freelance career and one of the biggest hurdles I stumble upon is a pricing structure that is attractive and more apt to close the sale. Today I stumbled across an article on Dzone and it got me to start thinking about my pricing strategy.

It is common for a freelancer, especially in web design/development to follow an hourly billing model. For example $25 - $50 an hour depending on the project size and what technologies are required, domain registration, hosting (if applicable) as well as a buffer for unexpected code disasters, missteps and client woes.

Letís take a look at an example that covers a typical scenario when dealing with a client:

You are approached by a client to create a basic website roughly about 5 pages. The goal is to give the client a web presence advertising their services, a simple contact form, an about us page etc., when quoting the client you inform them the site will cost $25 an hour and it will typically take 10-15 hours to complete. At best you just gave yourself a ceiling of $375. You could have billed the same site a flat rate of $500.00 which is not unreasonable for a simple business website, setup fees and troubleshooting and I usually throw in a few months of support to make sure everything transitions smoothly. It also sounds more appealing to the client to tell them you can build the website for $500 than to tell them you will do I for $25.00 an hour.

I had a client once whom I charged an hourly rate of $30.00 the total bill for the site came out to be $810.00 and the client refused to pay. After a few weeks of going back and forth I scrapped the project completely and decided never to do a project without a ceiling amount in writing and also to make sure I sign an agreement with the client before beginning work. I also like to try and get a percentage of the funds up front billed as setup fees.

Here is the article from DZone.
http://www.dzone.com...rge_hourly.html

Is This A Good Question/Topic? 6
  • +

Replies To: Hourly Rate -vs- Flat Rate

#2 baavgai  Icon User is offline

  • Dreaming Coder
  • member icon


Reputation: 6979
  • View blog
  • Posts: 14,605
  • Joined: 16-October 07

Re: Hourly Rate -vs- Flat Rate

Posted 27 May 2010 - 09:06 AM

*
POPULAR

The point about hourly having an invisible ceiling is spot on. You often add up the time taken in good faith and then say, "Crap, they're going to have kittens." You knock off some time and they might still look like they'll pop something. Flat rate means you're not afraid to give them the bill. It might also mean they get extra, since you're not worried about doing some more tweaking if you have the time.

The trick with a flat rate is to define, in no uncertain terms, the scope of the project. It's five pages, they are simple content and layout, here's the price. Wait, a shopping cart isn't just content. No, that guest book is not just a simple page. And on it goes...

Once the price is quoted, don't let extra stuff sneak in that goes beyond the original request. Unfortunately, after you say "that's outside the original scope" one to may times, clients will get irked. On a small project, you can say something like "I'd love to do that for you. Keep that in mind and once I get this project done we can go over all those great ideas."
Was This Post Helpful? 9
  • +
  • -

#3 macosxnerd101  Icon User is online

  • Games, Graphs, and Auctions
  • member icon




Reputation: 12149
  • View blog
  • Posts: 45,169
  • Joined: 27-December 08

Re: Hourly Rate -vs- Flat Rate

Posted 27 May 2010 - 05:32 PM

Let me emphasize on the specifically and in no uncertain terms define scope so the clients understand it. For my Nonprofit website project in web design class (my group is composed of high school juniors in the web class, and high school sophomores in the PM class), our clients don't understand scope. They love to creep with additional scope. Yesterday, they were like "and we need you to add about 50% to the scope of the project a week out from the deadline. I was like, yah not happening. To put things in perspective, they are getting upwards of 15 pages with a ton of functionality and intricate/complex design on their front end, as well as a 15 page management system that I'm writing on my own from the ground up.

So cost-wise, they are getting two $3000-$5000 websites absolutely free, and this is my final exam grade in web design. Not really a fair trade, but good experience and something really good to put on my resume.

Anyways, the point is to be wary of creeping, as some clients are worse about it then others, and then try to tell you how long it will take to make the changes (as I have experienced on this project).

Lastly, with some clients, better to cut your losses at a point, as it is impossible to please certain people.
Was This Post Helpful? 4
  • +
  • -

#4 dsherohman  Icon User is offline

  • Perl Parson
  • member icon

Reputation: 227
  • View blog
  • Posts: 654
  • Joined: 29-March 09

Re: Hourly Rate -vs- Flat Rate

Posted 28 May 2010 - 05:22 AM

The actual article (which is on FreelanceFolder and just linked to from Dzone) is at http://freelancefold...-charge-hourly/ I commented there a couple days ago when it first appeared and, well... I still disagree with the assertion that you should never charge hourly. It depends heavily on the type of work you do.

If you're doing graphic design, web sites, copy writing, building houses, fixing pipes, or something else where every project uses more or less the same processes and same technology, then, yeah, flat rates are absolutely the way to go because you know what the job will involve and about how long it should take.

If you're doing custom software development - including web applications - then you are, by definition, doing something that has never been done before, so you cannot have that certainty. A watertight spec may make flat rates a bit more feasible, but custom software is essentially a research project (the knowledge of exactly how to produce the final deliverable is itself the final deliverable) and the amount of effort needed to complete research projects is inherently unknowable in advance.

To repeat the example I posted over there, earlier this week, I was working on a project for a client who wanted a feature that required two libraries to work together closely. I had used each individually in the past and, on their own, both worked great. Put them together, though, and the app went off into space somewhere, producing no output, but remaining active enough that the normal timeout mechanism didn't fire.

If this were a flat-rate project, I'd be stuck with burning as much time as it took to work out the bad interaction and fix it, even if just getting that one piece working ended up taking longer than I had originally estimated for the entire project. Note that no amount of scope-proofing up front could have saved me from this result, as it is purely an unforeseen incompatibility, not an expansion of scope. On the contrary, the only way to avoid having to dump time into fixing it is to reduce the scope of the delivered functionality.

Instead, being an hourly project, I was able to go to the client and say, "We can either drop one of these two aspects of the function, or I can dig into it and find a way to make them work together, but I have a feeling that could get a bit time-consuming." In the end, they dropped one aspect rather than paying for me to fix third-party libraries and we were able to proceed with everyone happy.

In another case, a couple years back, I was writing a monitoring daemon for another client on a fixed bid. His budget was very limited, so I included in the contract up front that it would include no web-based administrative interface. As things developed, the client declared that the email sent to admins needed to include a clickable link to blacklist IP addresses. I said, "Sorry, out of scope. No web-based admin functions." He said, "That's not an admin function!" We argued back and forth about it for a couple days before I finally gave in because it was becoming clear that, if I didn't, then I wasn't going to get paid for the project.

I believe that both examples clearly show the importance of the one deciding what does and doesn't need to be done also being the one who pays the cost of doing it. In the first, the client is paying, so they made the decision and everything turned out great. In the second, the client demanded something which was (to me, at least) clearly out of scope, but refused to pay the cost of adding it because he believed it was in scope (or at least he claimed to), which created a situation in which at least one of us was guaranteed to come away unhappy.

These days, I will do some things on a fixed bid if the requirements are sufficiently standard and well-defined, but, as things start to get larger and move from "construction" into "research", then I need to either burn a lot of (non-billable!) time up front to negotiate a project scope defined down to the smallest details ("the definition of an 'admin function' is...") or just charge hourly and tell the client that the project scope includes anything they're willing to pay for. I generally opt for the latter, because it makes my life so much easier.

This post has been edited by dsherohman: 28 May 2010 - 05:31 AM

Was This Post Helpful? 3
  • +
  • -

#5 arthurakay  Icon User is offline

  • D.I.C Head

Reputation: 22
  • View blog
  • Posts: 226
  • Joined: 17-February 09

Re: Hourly Rate -vs- Flat Rate

Posted 04 June 2010 - 04:40 PM

I use both methods (flat rate and hourly), but the decision to use which one depends on each project.

For example, if I'm building a website from start to finish, I usually quote a flat rate - but I specify, in writing, what that price includes (as baavgai says in his earlier post). If clients go beyond that scope, they pay extra in a separate invoice.

On other projects where I do hourly work, I always provide a quote up-front... though I guess it's basically the same as a flat-rate. That way, my client is protected from an invisible ceiling and a clear expectation is set for the work in question. I generally don't agree to hourly projects that involve more than 10 hours of work, because the risk of going beyond the original scope is too great. In that case I'll ask to break the project into phases.
Was This Post Helpful? 0
  • +
  • -

#6 fallenreaper  Icon User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 240
  • Joined: 19-June 10

Re: Hourly Rate -vs- Flat Rate

Posted 23 June 2010 - 03:17 AM

I use both methods... If it is something new, i would go with an hourly wage as you are spending time to figure out and implement a new design and item all together.

If it is something that i have done previously and only needs minor tweaks here and there, i would give a set price = for example 75% of the origional creation cost as it was paid for previously. If they seem desperate and you are more of a greedy dick you could tell them that if they want it before a certain date, say.... in < 3 days fully functional, i would charge up to like 300% of the origional creation cost.

I dont fall on the greedy side as it may not get repeat customers, throwing that option out there for the customer is always something to do and let them choose.

A downside to hourly rates, working as a freelancer, doing exploratory material may end up being more time consuming then origionally planned and could have some nasty feedback. From that point the customer will most likely try to knock you down a bit and you would, like contractors, come to a middle ground. "hey listen this took longer then expected and you said you dont want to pay all this extra, so how about we come to a happy median for both of us." While this would prove a loss upfront, having the material covered for later projects would allow you to get the money back that you lost quite easily.

Granted as freelancers, you dont get anywhere unless you are all business men, and im sure you all already knew this. I didnt really see it all written up there so i thought i would at least say it. :)
Was This Post Helpful? 0
  • +
  • -

#7 husseycoding  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 52
  • View blog
  • Posts: 174
  • Joined: 23-June 10

Re: Hourly Rate -vs- Flat Rate

Posted 23 June 2010 - 01:58 PM

I think the key is just to use common sense and be reasonable with what you charge the client for. Personally, I use both flat and hourly rates, for the smaller projects, flat, the larger projects hourly because they are much more fluid and it's virtually impossible to put an accurate figure on what things will actually end up costing. In that case I provide and generous estimate, but state clearly that it is just a guideline and could change up or down.

Also if for instance there is some learning required to complete a project, then I will never charge them for the time spent learning. They are paying you for what you already know, they aren't paying you to learn how to build something you have already effectively told them you can already do (by taking the contract).

I never construct my quotes/estimates based on previous work, no job is ever going to be exactly the same twice so I just think through all the steps that are going to be required (breaking it down as much as is required to do this), put a figure on them all based on the time I predict I will spent on them, and then combine them to a final figure.

Also I am always very clear as to exactly what any work I commit to doing will be, if you are hazy and unclear as to what you are actually being paid to do, people will always try and get extra work done under the same quote, and potentially decrease your pay dramatically because of the hours you spend doing this.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1