Project budgets

Chris Gibson  —  July 5, 2012 — Leave a comment

Since rebranding as an agency, we’ve had a general rule that we (almost always) ask a client what their budget is, before we provide them with a proposal or even costs.

This article aims to explain why, and the benefits that we feel that this approach offers.

A little history

When I first started freelancing, I’d reply to pretty much any enquiry, without any quality control. I’d put a lot of effort into these responses, practically writing a full technical specification for each one.

I eventually learned – and this took me far longer than it should have done – that there are some leads that will never lead to any paid work. Some “clients” literally have no money to spend. Others are under the impression that websites are cheap to build, and that they can somehow build a booming online business in their spare time, for an outlay of £500. Asking for a client’s budget immediately filters these people out; indeed, you’ll almost certainly never hear from them again.

Other clients do have some money to spend, but simply can’t afford the website they want. In such cases, asking them to define their financial limits immediately makes it clear if the project will be viable.

Some common examples

Over the past few years, two types of enquiry have been very common (and always without a defined budget in place):

“I need a website building, and it must have a CMS”

As a freelancer, I’d spend a long time compiling a list of questions in response. How big is the site? How much of it needs to be under the control of the CMS? Do you need to add pages, or just edit existing ones? How many users will the CMS have?”, and so on.

Now, by establishing the budget up-front, we can instead just advise the client on exactly how comprehensive the CMS can be, or whether a CMS is even a viable/cost-effective option.

“I’ve had a great idea for a project — it’s a bit like [insert name of large, successful website here]”

This was very common. I’ve previously been approached for websites that were “Facebook… for brands!” and (even better) “Facebook… for dogs!“.

In both cases, I’ve explained that these projects would need huge amount of planning and R&D, and that they’d be expensive. Facebook… for brands! didn’t even bother to reply, despite the fact that I’d taken the time to include some helpful pointers in my email.

Facebook…for dogs! explained testily that their budget was only £3k, but that they had now found an alternative developer, who had “the right attitude” and who could deliver the project within budget. One year on, I’m still waiting to see the finished website.

The client’s concern

Of course, the client’s concern is always that by stating a budget (say, £10k), they’ll receive a quote from their agency of exactly (or perhaps just under) £10k. My view is that this is exactly what will happen — and, exactly what should happen.

By setting out a budget, the client is asking “What can you offer me at this price?”. The onus is then on the agency to come back with the best possible solution, for that cost. If the solution meets all the client’s requirements, then any concerns about costs have already been addressed, because the solution already fits the budget.

The inverse approach, which is more common, is for the client to effectively say, “Here’s a summary of what I want; please go away and guess what I want to spend, and then give me a specification that meets that budget”. This is often counterproductive, as per the next example.

A better case-study

More recently, a project came along that illustrated exactly why a predefined budget is important.

We were approached by an organisation who asked us to pitch for the rebuild of their website. The project was going to tender, but they knew of us via an existing client and thought we might be a good fit.

I went down for an initial meeting, and the project (a large CMS job) sounded ideal for us. However, when I asked them about budget, I was told that there was no fixed budget, and the client was “looking for best value but doesn’t want to limit the project at this stage”.

It then transpired that another of our clients, a much larger agency, were also pitching for the work. After consultation, we decided to present a joint tender document. This made a lot of sense — they had a lot of resource, not to mention an existing relationship with the client, but were short on the specific technical know-how. We had exactly the right skills, but less resource.

In fact, the unofficial feedback I received from the client after our first meeting, was that that they had reservations about using such a small company. A joint proposition with a larger partner agency therefore seemed ideal.

However, after submitting a joint tender document, the eventual response from the client was that the cost we’d quoted was above budget — and what’s more, that most of the proposals they’d received were also too expensive.

Clearly, the client had in fact been allocated a budget for the job, but were reluctant to share this with us. This was a mistake for three reasons:

1. It wasted their time.

The client will have spent considerable time meeting agencies and reviewing proposals, only to find that they were too expensive. If they’d given a fixed budget, either the proposals would have been under budget, or some agencies may have chosen not to pursue the work.

2. It wasted our time

To an extent, this is the nature of pitching for work; we frequently discuss projects with potential clients (or, existing clients) that come to nothing. That’s part of the job.

However, in this specific instance, we spent a good amount of time with our partner agency, producing a proposal that was always going to be too expensive. The client sabotaged their own process by aiming to bring in a large company, but then balking at the associated costs. Defining their (limited) budget in advance would have made it clear that the project was too small for the larger agency. We could then have potentially pitched a more cost-effective solution ourselves, giving the client another option (see below).

3. It ultimately limited their options.

For our proposal, we pitched a comprehensive CMS that would have been very powerful and flexible, but one which came at a price. Had we known that they had a smaller budget, we could have proposed a CMS that was more limited, but which would still have served their purpose and have been affordable.

If the lower-cost solution had been insufficient, or weaker than the competition’s offering, then the client would (and should) also have rejected our proposal. However, they would at least have had a range of options to look at. Instead, most of the tender documents they received were out of budget, and therefore had to be ruled out — leaving them with presumably only around two or three suppliers to choose from.

If the client had been up-front about the fact that they did have a budget to work within, this would have all been avoided, to the direct benefit of the client.


In our experience, asking for a client’s budget up-front is very beneficial, for three main reasons:

  1. It filters out clients who claim to want a website, but who actually have no money to spend. (They actually just want to know what the site would cost, if they ever did have any money; the equivalent to having your house valued when you have no desire to move).
  2. It encourages other, genuine clients to think about their budget, and what they can afford, as opposed to what they want.
  3. It allows you to define a website that is the very best that a client can afford.

Most clients have been very willing to discuss budgets once asked, and all of our most successful recent projects have started in this way.

Fundamentally, pitching for work can all too often involve guessing what the client has to spend, and then proposing a site that you hope will be affordable. Asking for budgets up front inverts the process; rather than allowing the specification to dictate the cost, you allow the cost to dictate the specification.

Chris Gibson


My Google Profile

No Comments

Be the first to start the conversation.

Leave a Reply


Text formatting is available via select HTML.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>