When I, ahem, “left” StreetWise a couple years ago and started freelancing full time one of the first things I did was change up how I bill from, the traditional, project based scale into an hourly rate. I did this for a variety of reasons, mostly having to do with a lot of issues I see with the project pricing model. It certainly wasn’t an easy thing to do, but after a couple years of this I have to say it’s been very good to me and something I think every freelance developer should at least look at.

If you don’t know, the traditional way of pricing out a web development project (at least in my experience) is for a client to contact an agency (or freelancer), tell them what they want and the agency telling the client how much it’ll cost at a flat rate. There’s usually a back and forth over cost and features, time and expense, and shaving features accordingly to meet some predetermined budget, and there’s certainly a lot of minutia in between the parts, but those are the broad strokes (again, in my experience).

Every agency I’ve worked for and with, and every freelance project I’d previously taken on, had been priced using this model. From a client perspective it’s a winner; the client has an expectation of what a project will cost and the agency can manage expectations and allot resources accordingly. Considering most agencies have their employees on salary, where the employees make a set rate regardless of work, this can work out nicely for the agency, from a bottom line stand point, as well. When things go outside of scope, and they will go out of scope, your employees work more with no additional investment from a raw cost standpoint.

The obvious downside though is that the principals of a project, the people who actually create the damn property or concept, are treated as replaceable commodities. The effect this can have on morale within an agency can not be understated. But, and this is important, within an agency, that’s the job. In my opinion, that’s why good principals can easily make 6 figure salaries with sick benefits and bonuses; you get worked like a dog.

To be fair, I have heard stories of agencies where treating principals as disposable isn’t the norm but those are usually the smaller, boutique firms, and I haven’t had much experience with those.

In freelancing though this model doesn’t hold up even a little. There is no salary safety net. When a project goes out of scope, and again, it will go out of scope, you’re fucked as a freelancer. You’re no longer being paid without then negotiating for overages (which carries it’s own risk). Plainly, agreeing to a set price as a freelance web developer is a sure fire way to go hungry. Yet so many of us work that way it’s simply amazing, in hindsight, when I think about it.

The biggest challenge to charging hourly is actually finding clients who are willing to pay an hourly rate. It was pretty surprising to realize just how ingrained the project pricing model is within client’s expectations. Loads of potential clients love having a set price. That said, an unexpected benefit of the hourly model is that those clients who are willing to pay hourly are much more disciplined and knowledgeable about the medium and what’s in store. Simply, just having an hourly pricing model weeds out the ignorant and unrealistic clients. I found that it’s a nice way to keep the nonsense in check.

When I find a new client who’s willing to pay hourly (with a couple exceptions) the first thing I do is get a retainer. The retainer basically gives me the confidence in the client to be able to pay my rate, as well as giving me motivation to start work with the confidence of continued payment. Plus, if a client can’t, or won’t, pay the initial retainer than I know right away they aren’t worth working for. Harsh, maybe, but the initial retainer is important above and beyond the money involved. It shows respect and trust, and provides motivation for the work ahead. The retainer is only required up until trust is built; future projects don’t require it.

Once the retainer is agreed to, though not paid, the next thing to do is figure out how long it’s going to take to do what the client needs done. Basically, how much are things going to cost. This is where the process is very similar to the project pricing model; you still have to know ahead of time what’s expected so you can say how long it’ll cost. The big difference here though is that your estimate needs to be flexible. Instead of saying, and sticking to, a project will cost, for example. $15,000 you say it’ll take around 100 to 150 hours likely costing $10,000 to $15,000.

The “to 150” hours part above is important. Always overestimate. What I do is imagine how long something will take and then, seriously, multiply that by 3. For example, if I think a project would take me 50 hours I say it’ll take 150 hours. Why? Three reasons; shit changes, there’s more involved than just development, and experience has taught me that I, personally, suck at estimating timelines (I’m an optimist). You have to take into project design, account emails, phone calls, client visits, project management, quality assurance, and client hand holding. The back and forth can kill a budget but my time isn’t free; the client pays for all of that.

Plus, from a client relations stand point, being under budget is always a good thing. If you can get the client to expect, and agree to, a cost that’s more than expected, they’ll love you to death when their budget isn’t tapped.

This leaves the question of accountability. To make sure the client has the confidence in me to do what they need I’ve found it’s important to provide as detailed an accounting as possible for all hours worked. Everything gets documented and passed to the client with invoices. When I send an invoice for 60 hours you can bet there’s a breakdown of every single hour worked, what was done, on what project/task, and when. Honestly is critical. If a client decides to audit your invoices, and you need to defend what you’ve done, you don’t want to go head to head with someone who knows it shouldn’t take 40 hours to install the core of ExpressionEngine (for example).

In terms of deployment process I’m not a fan of holding projects hostage from a client. By this I mean, keeping the client from having access until payment is received. My thought is that if I have a client that requires this sort of shenanigans than they shouldn’t be my client. Even entertaining the idea is a red flag so when/if it does come up I try to recognize the end is near. Further, that’s just dirty pool in my opinion.

With all that said, to me, it’s a wonder why any freelance dev would ever opt for a project rate (outside of panic mode, “I need money NOW”, freaking out). It’s just a losing proposition and one that I’m glad is off my table.