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

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.