What I'm going to cover here is nothing new to me and probably many other coders out there. To others though (both clients and designers in the business) it can be quite eye opening when I first tell them about it. All through the following post, remember the point below is what we do and what we give our clients.

We always want to give the client the best website we can for their available budget. Offroadcode

Talking about budget shouldn't be a secret! Asking a client what their budget is can come across as either rude or plain money grabbing. They hold back the true amount thinking we will quote back to them the full amount when we say how much it will cost. Difference is though, we don't give fixed quotes.

We will work up to the amount of budget the client is happy to spend. That to us makes sense. The clients gets the best site they are happy to pay for at a fair price.

We don't deliver rubbish for that money, we deliever the best we can to the amount of budget/time the user has. At the end of that we will have delievered the best, most feature rich site we could. All the client need do is pick and choose which features they want on their site.

What does a website cost?

When asking clients which features they want they do tend to always says "All of them". This is not helpful. Stalemate. So we need explain a little more to try to get our point across here.

When someone asks us the question "[what does a website cost?](whatdoesawebsitecost.co.uk "What does a website cost?")" we can't give them a straight answer without first discussing what they're looking for and what they need and no two sites are the same so a boilerplate costing template doesn't work for us.

It really is that simple. Even asking something "how much did it cost for , can I have something similar?" still does not allow us to give you a straight answer, things will always differ, we can give you a rough idea but no fixed cost.

The opening descriptions we get for some sites range from simple one liners like "How much for a basic website for a small company?" to epic word documents listing wish list items that the writer has stolen from (sorry been inspired by) a mildly related multimillion pound rival with years of development behind it.

Specifying driver needs

Each client has different needs, wants, wishes and targets that they want their site to perform. Trouble is those four driver (needs, wants , wishesand targets) often get mixed up into one big ball of a mud called "the website". They are all actually quite different things and all have different effects on the cost and time a project might take. Trying to work out what "the website" will actually do or who it is going to target etc. can take some detective work.

The four drivers

1. Needs
2. Wants
3. Wishes
4. Targets

The danger here is that large chunks of functionality can be masked by sweeping statements like "the site must have a shopping cart". Sounds innocent enough, but thats the point and the danger. From two extremes ecommerce can be as simple as a few Paypal buttons cut and pasted within a an hour or it can go right up to many months of development, testing and setup on secure servers with encryption and the works.

You can't quote for a "standard ecommerce system" as there is no such thing. Then the buttons for managing the cart are not all that is involved with a shopping cart, view the products, invoicing, stock control, all needs to at least be thought about with a little bit more care that that one sweeping statement.

If you agree to it then as a developer you could be agreeing to a whole load of extra work or if you are the client you could end up with a lesser version of what you wanted or additional costs and delays.

If the developer is cocky or not paying attention they might be tempted to come up with a gut feeling figure for these sort of sites. Its easy to do, it is work after all, it pays the bills and you don't want to lose the job or put the client off with too many questions before you've secured the work. The developer can end up giving a figure and a time frame based on too little information or even worse, all the best information available at the time which turns out to not be enough (and this is part of the problem).

A good spec solves everything … not entirely

Some of you will be screaming out "yes but that is what a good spec is for!" and you are right, you should of course have a spec. But again there is this issue that no one can think of everything up front, what the client thinks they need might not be what they really need when the site is build 6 months further down the line.

Spec by all means but expect it to change and embrace that don't fight it. Pete Duncanson

By being feature led you can grow or shink features as budget, needs and wants dictate.

On a side note, some agencies wow their clients with huge boiler plate specification documents, we recently got one that weighed in at 48 pages for what was a simple website. Yet at 48 pages it still didn't really say what the site would do, it played a lot of lip service to (very outdated) SEO and best practises yet didn't contain what we needed. Its main job seemed to be to wow the client and justify the inflated fee the agency was going to be charging the client, the client who was paying them to write the spec and do the work yet this same agency was try to farm the work out to us.

Incomplete requirements throw a spanner in the works

I was recently asked to find a car for the wife of a non petrol head friend of mine, he told me she wanted something small, had to be a diesel, tidy and about £1000. Tall order, suitable run arounds are hard to find running on diesel. After about 3 weeks we tracked one down that fitted all the criteria. However she turned it down flat because it was silver, she apparently has a thing about silver. See what happens when you have a middle man doing the spec, incomplete requirements.

"It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them."Steve Jobs

For a client it is rarely any different, they have an idea of what they want but might not be aware of what is possible, what is not. They might not know just how long a simple sounding feature might take or how quickly something which sounds really complicated migth be done. That is where the developer comes in, with that experience and knowledge to shepherd a wish list into a buildable specification. When you start on a site (no matter how well spec'ed out it might be) you find new ideas, improvement or problems as you build it.

Things that seemed so straight forward at first might simply not work when you build them, fixed quotes cause some pain here. Its no ones fault, yet with a fixed quote someone is going to have to swallow the over-sight, either the developer puts in extra hours (or worse, cuts corners) or the clients end up paying more than budgeted for or end up with a rushed product. It is not a realisic stance yet it is how it has always been done, its dogma that stifles the quality of the end product.

The eternal battle between client and developer

This sort of sums up one of the issues with quoting for complete chunks of work like this. Following this way of quoting often (but not always) leads to the following unpleasant yo yo situations:

Soft Developers/Hard Nosed Clients (This is the one clients always aim for):

1. The client writes everything down that they think is important.
2. Developer looks it over and agrees a price/time frame
3. Work starts
4. Client has new ideas and raises them with developer who agrees to fit them in to please client
5. Developer hits unknown problem, works around it as best they can
6. Time is running short, client wants to know what the hold up is
7. Developer works late most nights to catch up
8. Client does not like a part of the site and demands changes ("It says in the spec 'shopping cart' yet I can't browse it or buy easily on my mobile"), developer swallows the word games and promises to be harder with the next client.
9. Developer does an all nighter, code quality slips, errors and bugs creep in
10. Project is over time, buggy and as a result client refuses to pay for the additional features added in earlier or the extra issues.
11. Project launches a little late, mostly finished if a little buggy. Client bad mouths developer at every chance.
12. Developer sulks and promises to be much harder with the next client.
13. Client ends up with a site that is buggy and not as good as it could have been but on budget!

Hard Nosed Developers/Soft Clients (The favourite of bigger agencies):

1. The client writes everything they would like the site to do
2. Developer comes back with a huge specification document (which they have billed the client for writing) mostly made of boiler plate cut and pasting. A hefty price tag is included with plenty of "buffer" build in for the developer.
3. Client is impressed with the professional look of the spec (clearly these guys must have thought of everything, look how long this spec is!) and agrees the job
4. Developers blast out the site as quickly as possible, some corners cut when problems are hit, it was not in the spec so fixes cobbled together to get it out the door. Lots of cutting and pasting from previous websites, money for old rope.
5. Client has an idea but is told "its not in the spec, we'll have to requote for that it will delay the launch", that amazing killer feature will either never happen or will cost a lot to get in
6. Developers finish site which is exactly what they said it would be when spec written and nothing more. Even obvious mods found during the build which would have been nice additions and easy to do have been left out. Lets hope you (sorry they) wrote it well.
7. Client thinks they have a good site, until they need to change it or add in a feature.
8. Developer looks for next client to do souless spec based work for boasting about how their last project was on time and budget (leaving out the fact that it was not really any good and certainly not as good as it could have been).

Hard Nosed Developers/Hard Nosed Clients (Two unmoving forces battle it out):

1. Endless meetings and wrangling about what is in the spec
2. Client tries to get board open statements in the spec so they can use it as an excuse to squeeze more into it later
3. Developer tries to nail down every single feature into the simplest thing they can create with minimal creative thinking
4. Time runs short, project gets rushed out is over budget, buggy, inflexible and will need rebuilding next year
5. Client/Developer both unhappy but neither will let it show

All the above should be familiar either from a previous project or one you've heard of or even seen coming and avoided. We've all probably fitted into at least one of them at some point. Its a very dog eat dog way of doing business and puts a smile on nobody's face. Some make a whole career out of engineering situations like the last one thinking this is where they can get the most ground. I find no pleasure in it at all and walk away from this style of working and negotiation, someone else can deal with that nightmare client.

The paradox of fixed cost quotes

So this is often the parodox of quoted work. Clients trying to get "everything" for the smallest amount possible when they don't really know what everything really is. All they want is an agreed price for that big ball of mud called "the website" and they have a budget in mind but they won't tell the developer what it is as they fear they will spend it all. So we have to waste time doing the spec/quote dance rather than working towards a great site that does as much as we can for the budget allowed.

There is another way though. Rather than quote for this big ball of mud spec, instead the developer works with the client to tease out all the different features and then tries to estimate time for each of them, then the client (with some guidance from the developer) can pick and choose what they really think is important to have on the site by ranking their importance. Before you can do that though you need to know what those features are.

So what makes up "the website" then? How do we go about working out what all the features are? Simple, we ask questions. Lots and lots of them. This is the basis of how we work and it's how we design and develop websites.

We need to know more about the four drivers I mentioned earlier, we need to tease the features (or ideas, comments, inspiration, desires, widgets) of the site from the client and then group them into these drivers or groups. Let me describe each one in a little more detail, I'll purposefully give some grand examples rather than smaller throw away ones, you'll get the idea and the logic still stands even if you are working on smaller sites.

Examples of drivers and groups

Needs - These are things the site MUST do, with out them the site does not do enough to fulfil its most basic purpose. Most "needs" have to be completed to consider the site as functional. "Must have secure login functionality", "Must allow users to view previous orders". If I had to put a gun (well water pistol) to your head and said you can only have 2 of the 10 features mentioned for your website which ones would you pick? Those are the needs (you can repeat this for the remaining 8, 6, 4, etc to get a nice priority of features for the site).

Wants - These are the items that would be nice to have but are not deal breakers, the site could still go live without them and be considered to be able to fulfill its purpose. "Users can cancel orders online", "Users can see all previous orders". Often items which at first are listed as needs get moved into wants once estimates of time/money are put down to them.

Wishes - These are the real wish list items, these only get done after everything else is finished and done. These items are the first to get cut and the last to be implemented. I've no idea why but these ideas tend to come from high up in the command chain too... "Can we play our theme tune when the page first loads?", "Can the logo be animated?", "Can we add a game for people to play while they are on hold with our call centre?" Normally easy to spot, often hard to make go away until you write them down and put an estimate to them. If you don't do this you will catch yourself or your developers saying "erm...yes we should be able to do that" and thats time spent on fluff rather than that secure login you needed.

Targets - These are internal/external factors/constraints which affect how we might implement (or indeed if we implement at all) some of the needs, wants and wishes. These might be time constraits "We have to go live before the big Mega Conference in June" or performance "It has to be able to handle 500 requests a second" or technology "It must intergrate with our 30 year old stock management system which only communicated via the medium of balloon animals". There will always be some of these, time and budget constraints are the two biggest ones.

Clients please take note, you do no one any favours by saying you need a site build "yesterday", plan ahead and you'll get a much better product on time and happy developers. Do us all a favour and get in touch much sooner than you think.

Each item that you put in one of the first three groups is a feature. If a feature is large such as "standard ecommerce functionality" it should be broken down into smaller features, each one of which can again be put into different groups. Just because the initial feature of having a shopping cart was a need, when you break it down it should be obvious that "users shall be able to save items to a basket" is still a need where as "users should be able to click on an icon next to the product name and get a pop up image gallery" is a want and not necessarily essential to the success of the project. Its that sort of detail that can help shape a project and help the client get the best site they can.

These four factors are all important and all interrelated. Its amazing how a target like a tight deadline can have the ability to move what was at first a need into a want or even a wish list item. Once you've identified as many of the factors as you can, then you can start talking about how much time you think each feature (need, want and wish) will take while taking the targets into consideration.

Don't be afraid to ask questions

Ask enough questions to get to the bottom of all the features or at least to identify them all. You can't get all the answers so sometimes you have wing some sections or agree to do a quick sprint of work on them to see what they might take to do. We've lost clients in the past for asking too many questions, some see it as too much effort ("its just a standard shopping cart!"). I don't mind losing those clients. If they can't see what we are trying to do and get frustrated after two rounds of emailed questions then imagine what they might be like a few weeks in when you know what hits the fan through lack of planning. The reason we ask the questions is because there was not enough detail to give you an honest answer about budgets/time frames.

Now you have all the main features of the site you can start estimating how long each will take. Some of them might be easy to do thanks to some software/plugin you are using, feel free to group these together if you want but bear in mind nothing is straight forward, each item will take some time so allow some time for it to avoid being caught out. Clients might be scheduling the release of marketing material, training, press releases etc. based on what the developer estimates so they need to try to include everything of note, you will be doing no one any favours by leaving hours out.

Now you've got a time estimate and hopefully you have an hourly rate too (which might change depending on the targets, if overtime is required to get it out quickly for instance). So it should be simple to see how much work "the website" is really going to actually take you. Allow a margin of error, 10% seems to be about right for us. Avoid doing what I call "geek quotes" where you assume everything is really simple and you'll have no problems (known as the green path), its rarely that easy and there will be issues (known as the red path eg. fixing mystery bugs in browsers…) so add in some slack.

Add in slack - it's a good thing

Slack is good by the way, it allows you to do the job right rather than rushing constantly or you can add in a wish feature to fill an hour here or there or you can bank the time in case you need in on another feature later which over runs. Look after your slack if you have any, its a nice thing to have in any project, even for the client. Non rushed software is good software.

Now assuming the developer been honest with themselves there should now be a full cost of the whole website. This will include needs, wants and wish list items and is the total to get everything in that you know of up to that point. You've looked into each feature and possibly found more while doing it, good stuff. The client can see exactly how much time and cost each feature will cost them and when they can expect it to be finished. Now you can juggle these around and see which ones really are needs, which are wants and which of the "this is a must have feature" is now a wish list item once they see that it will take 20 hours to do.

Now you have a road map, working with the client again the developer ranks the order of the features to do. Work through all the need, expect to add most of the wants while baring in mind the targets. Wish list items only get added once everything else is done, get your hard word done early. If the clients budget won't stretch to all the feature they wanted then they have some choices to make, trim features or increase the budget. Nice and simply really. By having it all laid out in front of them the client can make some real choices about what they insist is on the site. Clients can try to squeeze your estimates ("surely that won't take X hours, a clever guy like you could do it in Y"), don't fall for it/try it for both your sakes.

If the developer does manage to do it quick it simply gives the client more budget to play with and the possibilty of having more features (more wants and wishes) to fit in but we leave that until you've actually done it. Alternatively the client could pocket the change or launch earlier. If developers estimates are good enough then it will be fine and everyone has a clear picture of the amount of work to do, changing estimates now brings the whole process into question so be honest and stick to the original esitmates unless new info comes up to make you want to change them.

This is feature lead quoting/development. It is also know as being LEAN or Agile. Agile has annoyingly become a dirty word in recent years, similar to being branded a "liberal" in the USA I suppose. It has become a hijacked brand/keyword thrown out on websites/sales pitched to act as a tick box for confidence (My friend Brain who does this stuff said I should ask you if you are "Agile"?) rather than actually being followed/imbraced/used as intended by those who use the word. The other danger is people see it's free and easy nature to be an excuse to not bother spec'ing at all and again that is not using it as it was intended. Agile is a term often over used but also little known by some designers/developers who would do well to know more about it, its probably the way you've always hoped you could work. Working in an Agile way helps everyone and leads to better products at the end of the day, mostly delivered on time and budget but certainly they give the best website for the targets the client sets. Listed here is our take on Agile. Remember nothing is fixed in stone here, you can pick and choose any estimating method what works for you that is after all an Agile way of working.

In conclusion - Feature based quoting is quick and more accurate

Its taken a while to get our point across, you might now be worried that if it takes this long to describe it actually doing it would take an age too. That's not the case. For speed the trick is to have all parties are involved. All we need are a meeting or two and to have someone at hand for the odd query that might crop up. Then we can break down a large site into a feature list in a few hours. We can repeat the process to break those features down further if needed.

We've used this process for projects with our biggest clients as well as smaller new clients and it really doesn't take long to build an accurate, feature driven quote once you've got the hang of it. We've gone in depth with the explainations above to give you a reference point to come back to if you need. It often makes sense when reading it but can take a few goes for it to sink in.

One assumption we're making is that you do have an idea of how much actual time a feature might take to complete. If you don't, you really shouldn't be in charge of quoting for a feature. Same goes for you clients, you know what you want it to do and how much you can spend, leave the quoting of time to the developers who know how long it will really take. This is also not really a place for salesmen either, if they have got the pitch in the door that is great but the estimates should really be done by the guys on the ground who will actually be doing the work or you end up with a spec which fits what the client wants but won't actually solve their needs.

We use FogBugz

We create a quick new case in FogBugz with information about that specific task It's fair to say we're FogBugz evangelists and we use it for most of our projects. It allows you to create cases or jobs which you can add a mass of additional information to including estimated time scales and even child cases. For our needs we can also assign it into a custom grouping such asneed, want and wishes. Nice eh?

When we have a new project we will start with creating cases for each of the features we know about then through conversations internally and with the client we will flesh these out with child cases of work that needs doing to achieve the parent case. Cases can be added, deleted and moved around as we please. Once all done we add estimates to each individual case, as we've broken them down to managable chunks of work (longer than a day is too large a job, less that 15 minutes is too granular) it is much easier to give it an estimate from experience. Then fogbugz works out your total hours for each parent feature automatically. This is what can then be used to give a per feature estimate or even a whole project estimate. Use your common sense and experience too!

The main benefit we have with adding quotes into FogBugz is that we can share them with the client, we can ask questions via email from within Fogbugz and track the conversation and thought processes right there in the case. As a result when a project is approved, there is no delay - we've already got a comprehensive job list and spec structure from day 1. Once we start we would move some cases into our Kanban system to then help manage how we do the features and in what order but thats a whole other blog post.

Use a different system you're comfortable with by all means. It might be a note listing app, a spreadsheet, whatever. You just need to detail each feature and assign a time and appropriate cost to it.

How do you estimate and quote?

I know it's been a long post, thanks for reading. Some of it might be old hat to you but enough people clients/designers especially have asked us to explain it that we thought it needed writing from our perpective of Agile estimating and working. I hope it gives you a good insight into our process and how we work to provide the best service we can to our clients. Do you have any questions or comments? [We'd love to hear them!](/contact "Contact")