How to Charge for Websites: Pay-Per-Hour Projects

Contributing Editor
This entry is part 2 of 3 in the series How to Charge

How to Charge

In part one of this series we discussed the complexities of determining a website price when your client eventually asks “how much will all this cost?” Fixed-price seems logical and is easy for all parties to comprehend but the process can break down on more complex tasks:

  1. It’s difficult to determine and document all requirements up-front.
  2. Requirements will inevitably change.
  3. It leads to the misunderstanding that a website is a “final product”.
  4. You may incur additional costs and payment can be withheld.

An alternative model is charging per hour: the client pays for the work you do. It’s an attractive option for freelancers because they receive money at regular intervals regardless of whether a project is on-track. While requirements gathering, analysis and revision is necessary, you’ll be remunerated for that work. Clients may also prefer the model because some risk is reduced; they won’t need to pay a large deposit only to find you’ve disappeared with their cash.

Charging per hour is typically adopted by freelancers joining large team projects. If you’re working on a variety of features, it’s easier to pay for your time than to identify discrete chargeable tasks.

However, it’s important to understand the pitfalls of pay-per-hour projects…

It’s Impossible for Clients to Determine Costs
The client doesn’t necessarily know what they need, how it should be implemented or how long that will take. While you can provide estimates, it’s a step too far for those with strict budgetary controls. Consider the following proposals:

  • I will complete your website for $2,000.
  • I will complete your website for $100 per hour and estimate it will take between 18 and 22 hours.

Paying per hour may cost less but unforeseen problems would raise the price. The fixed-price seemingly carries less overall risk for the client.

Your Earning Potential is Limited
There are only so many hours you can work.

Additionally, you’re being paid for effort rather than value. Presume you discovered a way to save your client $500 every week with a three hour development task. You’re paid for those three hours — a value significantly less than the job was worth.

You Become a Temporary Employee
If you started freelancing to escape the rat race, charging per hour makes you a temporary employee. As the IT guru, you’ll soon be solving the CEO’s Blackberry email issues, installing Microsoft Office and changing printer toner. You may be well-paid and willing to undertake those tasks, but is it a waste of your talent?

It Enforces the Notion That You are an Implementor
Who knows more about the web: you or the client who hired you? The answer should be obvious, but clients often think of web design agencies as implementors of their vision.

You’ve probably been asked to implement something you know will fail. Perhaps the client wants splash screens, keyword stuffing, Flash-based textual content, etc. You may eloquently protest but the client is paying you for the work. It leads to…

A Temptation to Wreck Projects
We want to be proud of the work we do. However, if an awkward client is paying for a dumb feature it can be easier to implement it as they want. If you’re paid per-hour the customer is always right — even when they’re not. Fixed-price projects generally grant more control because you have defined the requirements and it’s more difficult for the client to request undocumented ad-hoc features.

Project Delays Cost You Money
The client has an unlimited hold on your services. If they take three weeks to provide content or test a feature, it’s difficult to charge for periods of downtime. If you’re lucky, you’ll have a stream of other tasks or client work to undertake. If you’re unlucky, you’ve just been granted an unpaid vacation.

Time Management is Difficult
Freelancers often work for many clients. If I recall correctly, my record is eight different projects within one month. Ideally, this would have resulted in a series of one-off tasks, but life is never that simple. Every stakeholder presumed I was available the instant they contacted me because they were paying per hour. I had a continual barrage of inquiries, green-light agreements, requirement updates, tweaks, bug fixes and interruptions.

With hindsight, I should never have taken so much work. It was tiring, stressful and my productivity suffered. However, all the projects were speculatively agreed many weeks prior to starting but every client then wanted a January start date. To the other extreme, I may have received no work whatsoever.

Had I offered fixed-price estimates and demanded deposits, the tasks could have been scheduled on a first-come, first-served basis. Of course, I could then have experienced scope creep and other problems.

Charging per hour isn’t perfect. Nor are fixed-price projects. Is there an alternative? In my final article, we’ll examine a lesser-known pricing mechanism: agile charging.

How to Charge

<< How to Charge for Websites: Fixed-Price ProjectsHow to Charge for Websites: the Agile Way >>

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.tailormadesolutions.com.au Bradly Sharpe

    Part 3 of 2? Supposed to be 2 of 3?

  • Russell A. Thompson

    I’m really looking forward to the third article. I’ve used (and still use) both of the methods discussed so far. Even after 12 years of freelancing, adjusting contracts, specifying scope and client responsibilities… I still see project creep or wait long periods of time for clients to decide what they want. It can be very frustrating.

  • http://jessicasutton.com JSGD

    At our studio, we tend to mix these two approaches by documenting all the site requirements and then assessing how many hours it will take the team to tackle the scope of work. We present a range of hours, saying the project will take between x and x to complete, requiring a 50% deposit based on the higher end.

    We then send weekly reports that list out where the project stands and the hours put in. This also provides a way to alert the client if we are projecting to go over in hours, and is useful to reign in the unavoidable added features along the way.

    In the end, if we come in on the lower end of our projection, their final deposit is a bit less and the client is happy – and if it comes in higher, the client understands why and in turn, we do not feel slighted from doing unpaid work :)

  • http://quran.2index.net/ Said Bakr

    This way is suitable for professionals only, because non professional has an important limitation, it is the estimation of time that should be taken to do something.
    Suppose somebody just has learned how to read and you ask him in how many hours he may finish reading a book!
    In many cases non professionals may do great work, but the implementation time is still relatively unknown.