How do you go about charging for building a website?

Question

Someone has approached me to build a website for their small business. What is the protocol for laying out an offer for building a website in terms of pricing?

Do I charge for number of pages? If they want advanced features (Flash, Ajax, etc.) is it just price per hour of development? What if I have no idea how long it will take? Are there any good ways of looking at a similar website to help determine if something is going to be a 20 hour job or a 100 hour job.

Are there any standard templates that are used when determining scope and pricing for a website development job?

Answer 1

I would most definitely charge by hours of work, if at all possible. You don't know much time you need to put into the individual pages; so depending on the requirements the customer have, they can get it cheap (ie. you use less hours), or better and more expensive (you bill more hours).

Answer 2

Try charging in two week blocks. Commit to delivering a certain amount of functionality in those two weeks and at the end of the two weeks you both get a chance to re-assess the situation and change direction if needed. You are never out of pocket more than two weeks, the customer gets something useful once a fortnight and can change their minds about what they want done without you having to worry about scope creep.

Answer 3

This question is exactly the same as "How much does it cost to build a house?" In both cases, the answer depends on what the customer wants. You can build a "house" for less than $100, especially if the person living in the house has four legs and a tail.

Before you talk about cost, get specifics on what that business wants. Customers will have very different ideas of what a "page" is than you do. ("What do you mean that you're charging me extra for a shopping cart that automatically queries and updates my inventory, that contacts my suppliers when I get low, and that sends out a thank-you note with a survey? That should all be in one page!")

If the business doesn't know what they want (and that will happen often!), then charge them for one day to mock up many different ideas. (You will need to emphasize what a mock up means. Many people think that once it displays a page, all the work is done.)

Once you know enough information to reach a goal -- even if it's not the final goal of the web site -- you can then estimate your time and effort.

I highly recommend the book Software Estimation: Demystifying the Black Art by Steve McConnell. Good luck.

Answer 4

mostly client paid for hours if you not like it then you got paid for a project means Big project give you big money & small project give you small money

Answer 5

What I usually do is just my hourly rate that I charge times what I estimate to be the hours to completion.

Then I usually pad about 1 - 2 weeks onto the end of my estimate (depending on how complex the job is), because I always underestimate the time required. I usually end up estimating low even taking into account that I'm estimating low (Hofstadter's law).

Answer 6

My advice would be not to quote until you know exactly what you'll be required to write, and get the customer to sign-off on the scope. If they change their mind, make sure they understand your quote is no longer valid and it will cost them more money.

Depending on what's required, you might want to stick to raw html/css, utilise a CMS, or even write a web application from scratch.

Based on the above decision and your previous experiences (if any) with those technologies, you could categorize each function or page required so that you can estimate how long it will take. Overestimate rather than underestimate. Add on overhead for styles and layout, and some more for deployment and bug fixes and use that as your basis for estimation.

For example, if you're asked to write a site that has 5 fairly static information pages, 10 pages that the customer needs to be able to update, and two pages with fairly complex functionality (e.g. mapping of outlets and and service calculator), you might break it down as follows:

• Style and layout overhead: 5 days
• Static Pages x 5: 1 day per page = 5 days
• Editable Pages x 10: 2 days per page = 20 days
• Complex Pages x 2: 6 days per page = 12 days
• Deployment and changes: 3 days
• Total: 45 days

Multiply this by an hourly rate you're happy with, and there's your quote.

That said, if you honestly don't know how long things are going to take, you'll be providing a ballpark estimate anyway. Make your best effort at estimation (break things down as much as you can), provide a quote, and cross your fingers you haven't seriously underestimated it. If that happens, make sure you learn from the mistake.

---

Update: I stumbled across blog post from The Design Cubicle which you might find useful as well. Questions to ask clients before designing their website.

Answer 7

You can do this in a number of ways depending on the client and how sure they are about what they want. I would suggest giving them a number of options for:

• Fixed cost site - based on a specific number of pages and a standard design. You have to emphasize that this is a less flexible option but they can change to an hourly rate once complete.
• Custom template - based on an hourly rate, then a fixed cost for each page that follows.
• **Custom site- based on an hourly rate.

If you're working off an hourly rate and they require some sort of guideline price then try and break it down into a number of work items and estimate the time and cost per item:

• Basic template design - 4 hours - $200
• CMS Setup - 2 hours - $100
• Contact and About Page - 1 hour - $50
• News Page - 1 hour - $50
• Total Cost $400 @ $50 per hour

You should negotiate an hourly change fee for updates also.

There are a number of different ways to estimate the amount of time for the above. The best metric is prior experience of how long an item will take, but if this is the first time you've done this then that's not possible. If you have another web design friend who can help validate your numbers for you then that's also useful. Hope that helps.

Answer 8

Charge a rate x hour with a weekly billing cycle (this is what I use all the time).

From my answer to what are the most common problems you encounter in freelance web development

poor payment structures - I do weekly cycles, I deliver weekly so I expect to be paid weekly as well. This is a fully automated thing (part of the service I use for the projects), I am unsure how this would go outside of there, but you Really want to get as close to this as you can. You will know for sure you are getting paid right from the first 7-12 days (there is a delay involved, for reviews and the like). Also if, along the way, something goes wrong economically with the client, you will find out for sure in a couple weeks, as opposed to a couple months. Of course, you try to find out sooner, but if it goes wrong you get minor impact.

This means that you'll need to deliver value from the start, which is healthy. Have a conversation with your client, well focused on identifying what are the major pieces that they want to achieve and what is the best place to start. This is based both on your client's priorities & your own knowledge of what it takes to do it - even if you don't know specifically how much effort it takes, you usually have an overall idea of how complex different major requirements are vs. each other.

Explain them that the best way to proceed, is to break the problem down & focus on a subset of features that'll start generating value for them. Advice them on where to focus & try to keep the other features completely out of the picture.

Form an overall idea of what'll take for the ones that'll be in the scope ... only go on detail on the stuff you'll do the first 2 weeks / which you need to estimate & commit to. Use any deviation you got when going into the detail of the first weeks items, to get an idea of your overall deviation - using this adjusted overall estimate will increase (a little bit) the accuracy.

If they'll not go for the value vs. cost of the first 2 weeks items, it'll usually be best to walk away (see the answers by others in that link above - learn to say no) ... its very likely it'd end bad because of wrong expectations by the client. Don't let them play down on the effort involved, it takes what it takes, if you still want to go for it - let them know you'll discount them x number of hrs / or x $ in the rate for the first x weeks.

Use what you learn of the first week(s) to guide your way forward on the other weeks. Keep constant communication with your client. If you establish credibility with your client, they'll be less concerned with estimations & will be more talking about what'll they get next. Make sure to raise any trouble you see asap, never wait to the end of the week for that.

Make sure to remember you'll be estimating v. broad pieces (as few of them as possible) & more detailed for just a couple weeks, we are talking hrs estimating not days.

Answer 9

For the first build I estimate the number of hours/days it would take, then charge a fixed price based around my hour/day rate*.

Stock photography and hosting is charged direct to the client and any changes to the agreed first build are charged at my hourly rate.

As a freelancer I also always try to charge in weekly/fortnightly blocks if possible, not only does it get the money flowing early, but it also focuses my mind and the clients.

Clients will always try to wriggle more out of you, so you must be strict about what's in the first build and what's not.

*(Then my project manager/wife multiplies it by 3. Seriously, developers are awful at predicting how long something will take - See also the already cited Hofstadter's law)

Answer 10

Here are the steps I usually follow :

1. List the various tasks the project includes
2. Evaluate how many hours each task will take me
3. Sum the hours, and probably add or remove a few ("H")
4. Think of an acceptable hourly rate ("R")

At this point you can see how much you should ask theorically : H * R

But that price isn't necessarily the price you have to ask. You will probably want to play with R (up or down) depending on the wealth of your customer, the fact he's a friend, how much your competitors are asking, and whatever parameters you have to take into account...

Golden rule : If you know you can get the job done with a good level of quality, don't be afraid to ask (what looks to you like) a lot.

Answer 11

I would either determine what your normal hourly rate would be and use that, or discuss the client's set of needs and determine what an appropriate "flat" rate would be. Don't go the route of charging per page.

Personally if it were me I would determine the "scope of work" for the project and give it a flat rate, but inform the client that the rate can change if (when?) they decide to change things.

Answer 12

Per-hour is generally lower risk for you, because slippage and feature-creep therefore become the client's problem.

On the other hand, it is generally much easier to negotiate a fixed-cost project with clients: far lower risk to them, and they don't need to think about how to figure out whether you really are working those hours you are claiming or just answering StackOverflow questions :-P

If you have to compete with other people for the project, fixed-cost tends to be more competitive, but riskier. You might end up taking ten times as long as you estimated to complete the project...

Fixed-cost does have one major advantage for you though: flexibility. What if the project only takes you 1 hour, and you billed a fixed-cost for ten hours? You've just earned yourself 9 hours to browse StackOverflow at your leisure. or put it another way: you no longer are under any obligation to account for your movements or actions, or log your hours, or not to chat to people in googletalk or whatever whilst you're working. Which is rather nice I feel...

As far as 'per page' or whatever... more generally, I would try to divide the project into smallish chunks, with specific technically objective measures at each point, and get the client to sign-off and pay for those chunks as you complete them. That way there are few surprises, for you and the client. The client gets a warm and fuzzy feeling that you're working on things and progressing in a timely manner: he/she can see that, it's fairly transparent. You in your turn get a similar reassurance that the client is not just going to run off with the code at the end, since the client is paying in small amounts along the way. Finally, if you find that you're over or underestimating the time, you have some leeway to revise them somewhat for later chunks, via negotiations with the client of course, but the situation is fairly transparent for both of you. It's not like you work for months and then realize actually it will take years...

Summary:

• fixed cost is riskier but gives you more flexibility, and tends to be much more competitive
• per-hour is low-risk, but, not as exciting: there is no direct reward for coding quickly, and you're under the obligation to make time-sheets, not do anything except work during those times, and so on
• for fixed-cost, to keep risks low, and the client happy, breaking the project into smaller chunks lets the client see that work is progressing, and means that you can bill the client as you go along, rather than presenting a huge bill at the end, and the stress and risk associated with that

Answer 13

Charge according to the mental strain and work you requires. For somw web pages, it might more time, but we won't have much stress. Similarly for some others, you need to work really hard, out of your screws, but for a lesser period of time. So you have to give weightage for both when charging your work.

Answer 14

Here is the process:

1) Determine your worth in the market. If you are confident in your skillset, have a solid portfolio, and experience working the market then you should charge like a lawyer. There are costs to doing business like promotions and advertising that you must make up in your billing. If you lack the confidence to start a company and bill like a lawyer then you are not ready to perform as an independent consultancy. If you charge like a professional you will be treated like a professional. If you charge like a child you will be treated like a child. If I were a freelance business agent I would charge $150 per hour for my time, which is a fairly standard rate for external business services in many different fields. If you are a programmer or database architect you get to charge more. You have to remember as a free agent you have no 401K, health insurance, or other corporate benefits.

2) Initiate every single job with a written contract. This contract must define the following:
2a) Your billing rate. Do not include business expenses as additional charges unless travel is required. Your billing rate should be high enough to offset any business expenses.
2b) If travel expenses will exist then you need to write into the contract that you will provide receipts for travel related expenses that occur outside standard billing. There must be language in the contract that defines if there will or will not travel and that expenses related to that travel will be billed to the client outside your standard billing.
2c) Include language that states no work will be performed until an addition to the contract detailing a list of specifically defined requirements is signed by the client. The completion of the requirements is what they are paying for and indicates the work you will be doing. Do not provide any other work and do not perform any other work. If you act as a charity and give away extra services or work outside the requirements then you are not ready to work on your own.
2d) Define the deliverables and any other external requirements. You probably do not read people's minds. If a client wants something specific then they will provide with you with some sort of rough specification.
2e) Include language that you will not provide additional work outside the defined written requirements.
2f) Include language that a contract may be dissolved by either party at any time. Indicate that the earnest money will not be refunded, but all billing will be refunded if the contract is not completed to specification.
2g) Have a lawyer write the language of your contract and you need to review and question that language for clarity. Lawyers often do not speak human language, and sometimes they must be brought back down to Earth. If a client is not capable of understanding your contract then they likely won't follow it and you likely won't enforce it.

3) Charge earnest money. Some clients believe they have the vision of Leonardo and Michelangelo combined, but are completely surprised when work created to the letter of their specifications does not live up their expectations. Under such conditions the client may want you do the work over without charging extra. You are not a charity. Charge a flat entry rate that is two to three times greater than your billing rate up front. This is investment revenue to ensure that at least you get something if the client backs out before you can finish the project, which often occurs if you refuse to give work away for free.

4) If work is performed to the letter of the specifications provided to you and the client is not happy then submit to the client an additional contract and call it a Change Addendum. If they don't like the result then they can pay you more money to perform more work or they can go forward with the work provided. You are not a charity so never perform the same work twice without billing twice unless the work fell outside the written requirements.

5) Do not sell more than your capabilities allow. If you have been writing JavaScript for a month do not expect to sell your services as capable to build an interactive AJAX ready site based entirely off JavaScript interactions. If you charge high enough and attempt to defraud your client they will likely sue you. If additional skills are required then refer the project to somebody else or hire a partner.

6) Never start any work until all requirements are very specifically defined. This may take several meetings and many communications to the client. Keep track of this time, because time spent planning a project is work that should be billed. There may be dependencies that exist in development necessary to determine requirements at a later stage of the project. In that case break the project down into phases and mandate a list of requirements per project phase. Again, do not perform any work until the requirements are defined, written, and signed off.

7) You are not obligated to take every client that asks for your services. You are free to turn anybody away without justification. If a client does not appear to be reliable or you perceive they will waste your time then don't take their work. Time is money and you are not a charity.

8) If a client endlessly wastes your time then simply dissolve the contract, refund any paid billing, and walk away.

9) Charge like a lawyer, and never provide a quote. A project takes as long as it takes to plan and perform the work. That time is entirely relative to the requirements and nothing to do with the client's checkbook. Tell the client your billing rate and if they are dead set on a quote then you can give them an initial estimate of your time and they can figure out a quote on their own. Just remember to tell them that estimate is not reflective of a quote, and even put such language into your contract.

10) Always provide the best quality work and not the fastest work. This is why you get to charge like a professional. If your work takes a bit longer than some other comparable consultant simply explain the value of your service with regards to accessibility law, adjustable features, and efficiency, security and so forth. Through explaining the importance of these features clearly into the defining of the requirements you may be able to alter planning decisions from the client for the benefit of the project's quality.

11) A client is the boss and pays your bills. Even after you try to talk them out of it they will likely make a very bad decision. Do not argue. Simply do your job and move onto the next project. If you cannot heed this advice then you are not ready to work as an independent consultant.

Answer 15

It's impossible to give a price estimate if you don't know the requirements. First find out what they actually want, then estimate how much it will take time and give your quota according to that.

Hint: Don't give a fixed price for the whole project - that will mean that it will never be finished as the customer will always come up with something to fix, you'll end up doing stuff "for free". Been there, done that.

Rather give a fixed price for a first version and then charge per hour for any modifications they want to make.

Answer 16

I've always been very upfront with my costs. I usually put a spreadsheet together of my costs and what I'm charging for. The general rules it follows are:

My General Rules

1. If you have a detailed Functional Specification for the work to be done, I can give you an estimate, at no charge, and we can agree upon a set price for what is contained in (and only what is contained in) that Function Specification.
2. If you don't have a Functional Spec or a design, I can put one together for you for my usual hourly fee (which I sometimes waive), then we can go over it (see #1).
3. If you can't stick to a Functional Spec, or the work is ongoing after the original development is completed, then it's hourly work, plain and simple.

Outside of all of that, there's the level of skill required to do the job that figures into the pricing. Do I just build them an ASP.Net app? Or is it MVC? Does it have any Flash Development? A combination? Is it a really short contract? Those sorts of things raise or lower my prices by a few dollars an hour.

It's also an extremely good idea to put all of this in a spreadsheet and explain all of your charges to your client and why you're charging for it. Be sure to include things like hardware and software use so they understand that you've got overhead on your end too. Some clients don't seem to get that.

Above all, put yourself in their shoes. We've all hired a plumber or electrician once or twice and got a bill and thought, "What the $#@! is this charge for?!"... So be straight forward and transparent with your billing and you'll get repeat business.

One more thing:

When working for a fixed price project, always be sure to write up and sign a contract! You can work out a payment schedule if you like, you can even try to collect up front, but the bottom line is, a contract is the only way you can get money for your hard work if the client backs out. It's not going to offend them, they'll get it.

Answer 17

The first thing that you should do is draw up a Statement of Work document that details what you will be doing for your client, how much you will charge, tentative work schedules and payment schedules. You can give verbal estimates to your client, e.g. "It should only take about twenty-five hours of work, I charge $50 an hour, so $1250" but make sure that you go home, calculate, and add about 25 percent more hours to your estimate.

Here are some things to think about when drawing up a statement of work proposal.

1. Take it seriously. You are drawing up a contract between yourself and your client. It does not have to have any legalese inside of it, but make sure that it is signed by the person that you are doing the work for. You want do get paid, don't you?
2. When doing actual work estimates make sure to into account any time that you should be spending debugging, setting up web servers, deployment and database migrations. Some of these things you may take for granted because you are used to working with LAMP software, but what about if your client wants to run this pig on Windows?
3. Be clear in what you are working on inside of the document. If you state that your web application will run on a LAMP platform and later they tell you that they need it to run on Windows with SQL Server, you are going to be doing more work and charging them for it.
4. Make sure that payments are received after milestones are complete. You might want to charge 25 percent of the fee up front then after the first milestone another 25 percent of the fee and then finally when the project is finished the remaining 50 percent of the fee. These numbers are aribtrary and completely up to you.
5. Install software to track your hours so that you can show your client when you actually worked on their software. I would personally suggest something along the lines of Redmine because you can also print out the bug reports from testing.
6. Always, always, always delegate time inside of the SOW for testing and charge for it.
7. Last but certainly not least be sure that the statement of work document is signed by both parties.

I hope that this helps you out a little. It is up for you if you want to charge hourly or not. What I usually do is estimate the number of hours that it is going to take, lay it out inside of the SOW, and put a single price which reflects an hourly wage that I am used to receiving.

Good luck!

Answer 18

A lot of good stuff here, but mainly coming from the risk limitation POV. So at the risk of being both academic and progressive, I'd like to provide something different by highlighting the phenomenon of the "relational contract" which is easier to find in peer-reviewed economics journals than elsewhere, but was apparently used in the expansion of London's Heathrow Airport.

Instead of defining what is to be delivered, a relational contract defines HOW the relationship or collaboration is to proceed, explicitly including things like releasing work in stages and periodic reflection points (where all parties "settle up" and either party can then exit the relationship if unhappy with the progress).

This is also been talked about by Lean Software Engineering evangelist Mary Poppendieck; here is a slidedeck of her's on "agile" contracts.

Relational contracts are supposed to get both parties pulling in the same direction and of course engender trust, which, ultimately, is the best and most productive partnership that a client and consultant can enjoy.

[Update] See here for how New Bamboo do their contracts (I thought this was pretty cool).