Agency consulting: Hourly vs. Fixed bids

We currently do all our work with the hourly model, charging $X/hr. $X is the same for all types of work: graphic design, print layout, website design & development, SEO, etc.

But, as we are a small company, we've realized that charging by the hour inherently limits how much money we can make. After all, I can't work more than 24 hrs/day.

So, we've been thinking of moving to a fixed bid approach.

How do other web / programmer / interactive / creative folks do this, and have you ever made the switch from one model to another?

I also run a small agency. You need to stop thinking in terms of costs and dollars and more in terms of values. The work we do is hard, and doing it well takes time and effort that are frequently hidden from clients. So, in order to survive as a business, you have to ensure that the client understands the value of what we provide, beyond just the hours that it took to actually produce it.

If you're at all good at what you are doing there is a fair amount of time that goes into making the design/website/copy good--before you actually start producing anything. Are you charging for this (incredibly valuable) service? If you're like most small agencies, probably not.

It's really easy to fall into the "marketing is a commodity" mindset. It's not, not by a long shot. We enable people to sell stuff faster, easier, and with less friction. The value is incredible. Don't sell yourself short.

Also, I vehemently disagree with the chap who wrote that "Programming should be more than graphic design." NONSENSE. This is obviously from a programmer. As an agency executive my experience is that good designers are much more rare than good coders.

As a programmer, it's fairly impossible to estimate software projects as the client's needs and wants change over time. I sell iterations and deliverable estimates based on Agile principles.

This is a decent overview I found quickly. When deliverables are more concrete - i.e. I want X user stories / functions, here are the mockups, and this is explicitly how I'd like it to work, a fixed cost might be realistic, but I always write proposals as estimates.

I would argue that scaling a team (more talent) would allow you to take on more projects, and incur more fees to increase revenues. Other creative types might be able to do fixed costs, but I would not recommend it for software projects.

A common technique is to charge a different rate depending on the job.

Programming should be more than graphic design. Custom web work should be more than HTML/CSS layout. Writing an article for a magazine from scratch should be more than editing an existing white paper.

This is a reasonable practice and it means you can raise rates.

To your point about making more money, charging appropriately for the work means you can elect to sub-contract work, paying that person less than what you're getting and therefore making money while they work instead of while you work.

I agree with Dan about the perils of fixed-job bidding.

P.S. Lawyers do this all the time.

If you find that you have a lot of very similar projects, this could work, by setting a fixed estimate for each type of project.

For example, it's pretty common for a graphic designer to charge, say $250 for a logo, which includes an initial consultation, and maybe 2 or 3 revisions. Anything beyond that is an extra (negotiated) charge.

A custom programmer might come up with something similar for something like "Setup a Wordpress blog" or "Setup a shopping cart that works with Authorize.Net" - in other words, predictable, standard projects that you understand very well.

You can offer a "menu" of these fixed-rate projects, with extras being negotiable. Assuming you get very good at these projects (by having stock code to use with minor customizations), you might actually increase your margins.

Otherwise, you might wind up losing money, if a "standard" project turns into a highly customized nightmare after you've agreed on the price. In that case, stick with hourly, or define what the base rate covers in great detail.

You'll notice that the tighter you focus the standard project, the more it looks like a "product". That's a good thing. Products can scale more readily than services, even with subcontracting.

One more thing - if you're not quite ready to "productize" your services, you can start now by tracking your current projects more closely to see how long a "typical" project of a certain type takes, and what the common customizations or wrinkles are.

Then you might take the average case (for example - "40 hours for a customized shopping cart using open source software"), add a buffer for your profit margin, (e.g. 20%), and then your "product" might be "Customized shopping cart" - 48 hours x hourly rate (e.g. $100) = $4800 as a base rate.

The software development company I was in complete abandoned T&M (time and materials) and went for per-project/fixed bid pricing. Only government contracts were on T&M, since that is how it works with them. It took a bit of trial and error, but in the end ended up becoming very profitable for the company.

Why do I like fixed-bid?
1. You control who you put on the team and how you manage the work, since client pays you for the result.
2. You are motivated to really nail down the client's pain points and exactly what they want, so you deliver to the client what they really want. This leads to repeat business.
3. As your team gets better, your profitability goes up.
4. Much easier to measure performance of individuals on your team and figure out who the cockroaches are.

Many clients preferred fixed bid and team liked it more too. Agile is one of the easiest methodologies to apply fixed pricing to. Try per-user-story based pricing.

It is usually those too inexperienced that advocate for hourly billing, since it is very easy to dump all the risk on the client. Clients are definitely getting this and are no longer willing to accept that.