Herding Pixels

When you work for a company, you don’t generally have to worry about how to price things. Your boss will do that for you, likely at a considerable markup. But as a freelancer, that responsibility (and profit!) falls on your shoulders.

There are two common approaches to billing clients that I use:

Billing Hourly

This is my preferred method of billing clients. You work a certain number of hours, you get paid for those hours. If you can find clients who will agree to this, this is the approach I would recommend, as it protects you from getting screwed. It helps if you have established a base of trust between you and the client.

When taking this route, clients will sometimes want to specify a certain maximum ceiling. This is definitely an understandable reflex; however, if you go this route you have to be careful not to box yourself into doing the work at a flat rate. I generally will leave some wiggle room at the top to account for unforeseen issues arising, while setting the expectation with the client that the actual work will likely come in under the maximum.

Billing at a flat rate

A flat rate puts more of the risk for the project on your shoulders. If you fully understand the scope of work and trust your estimation abilities, then this can be a viable option, and clients generally prefer this option over the former.

If you don’t have much experience putting together quotes, this can be a harrowing experience. And you will probably have at least a screw up or two. When I was starting out, I once estimated a project at 18 hours that ended up taking over 60; I took my lumps on that one.

It will also fall to you to make sure the client sticks to the agreed requirements you agreed on, and avoid any scope creep. Since you’re basing your estimate on the clients’ initial list of requirements, any additional changes not on that initial list are going to eat into your profit margins. So any additional changes the clients request will need to be billed extra. This can be a delicate topic to raise, as there can be a lot of confusion, especially with web development, as to how easy or difficult things are. So it’s good to suss out any hidden assumptions as early as you can.

For larger projects I will generally establish milestones and break up the overall scope into smaller estimates. I’ve found this is a good balance; it protects against too much scope creep, and allows you to continually reevaluate your estimates as the project proceeds.

Obviously, every project and client is different, so there’s no “right” way to price out a project. You can mix and match these as well, perhaps with a certain flat rate and an extra retainer for additional enhancements they want done. It’s up to you.

Be sure to stay tuned for my musings about how to price things out as a team.

No related posts.