Charging clients by the hour
Moderator: General Moderators
Charging clients by the hour
How do you guys handle charging clients hourly? Assuming your working off-site... what do you do to keep your client at ease, knowing your not over charging? Do you itemize everything you do during the given period of time?
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
Honesty and trust must exist on both sides before I'll even start a project. Then while the work is being done I find that constant communication and short iteration cycles tend to work best.
It's good to log your hours, but it's easy to over-do. I usually log a period of several hours with a summary of the work being done, like:
1100-1330 / interface design
1330-1500 / front-end development
..etc...
It's good to log your hours, but it's easy to over-do. I usually log a period of several hours with a summary of the work being done, like:
1100-1330 / interface design
1330-1500 / front-end development
..etc...
There's also the issue of how you bid your project. This topic is often controversial. Where possible, I used to (I'm retired now) prefer to make a fixed price bid, then not have to account for hours. That often makes sense to the client because they know upfront what the cost is and can decide whether it's worth it or not. That requires that your specs be really clear and specific. The client must know that all changes will be extra! Some projects just can't be defined well enough to do this, so then you just have to bill at an hourly rate. If you decide to make a fixed price bid, you have to have confidence that you know what it will require of you, and you should "pad" your private estimate for contingencies. That's ethical, because you are assuming the risk, if it turns out to be more complicated than you thought.
In any case, Kieran Huggins is absolutely right, everything must be based on trust and a shared understanding, or it's just not good business.
In any case, Kieran Huggins is absolutely right, everything must be based on trust and a shared understanding, or it's just not good business.
I spec out the project functionality very specifically down to each and every field that will be stored in a database and every feature that will be available. If its a large project I might bill hourly to do these functional specs. After that is complete then I can make a detailed estimate. Specific details include things like - The list of customers in the admin tool will include customer name, login, and signup date and can be reordered by last name or login - or - Customer fields include First Name (max 40 characters, required), Last Name (max 50 characters, required) etc.
If the project is large then it is split into stages, each stage is a defined deliverable with its own set of specs and its own estimate. The stages are testable on their own and generally dependent on the previous stage. For instance an e-commerce site might be split into product administration, product catalog, shopping cart, and order management.
Stages have some advantages. For instance if you spec out the product administration and then code it, at that point the client might realize that they forgot to tell you to include dimensions as part of the product entity. This might only be an extra hour of work at this point but may have been many hours of work if the entire site was done.
Secondly any changes to a stage will allow you to take those change into consideration for future stages. At the end of each stage you review what has been done, then make any necessary changes. After that you can redo the estimates for future stages.
If you want to guarantee an estimate that is fine, but its of upmost importance that the specific details of what you are providing are rock solid and clear to both you and the customer. If they are expecting one thing, and you deliver another because you weren't crystal clear you are going to be eating your time.
Above all, be very clear both in writing and orally, that you bill for your time and thats it. Bug tracking and changes are part of the development process and also should always be billed.
If the project is large then it is split into stages, each stage is a defined deliverable with its own set of specs and its own estimate. The stages are testable on their own and generally dependent on the previous stage. For instance an e-commerce site might be split into product administration, product catalog, shopping cart, and order management.
Stages have some advantages. For instance if you spec out the product administration and then code it, at that point the client might realize that they forgot to tell you to include dimensions as part of the product entity. This might only be an extra hour of work at this point but may have been many hours of work if the entire site was done.
Secondly any changes to a stage will allow you to take those change into consideration for future stages. At the end of each stage you review what has been done, then make any necessary changes. After that you can redo the estimates for future stages.
If you want to guarantee an estimate that is fine, but its of upmost importance that the specific details of what you are providing are rock solid and clear to both you and the customer. If they are expecting one thing, and you deliver another because you weren't crystal clear you are going to be eating your time.
Above all, be very clear both in writing and orally, that you bill for your time and thats it. Bug tracking and changes are part of the development process and also should always be billed.
Thanks, these are all great points... I think the main things are
1. Be specific on requirements
2. Have both parties agree to those requirements, with a strict understanding that additional work will not be "free" as it comes
3. Regarding payment, charge either per job or per hour, but stay strict to the agreed requirements
4. If any additions are to be made that are not in the original requirements, have a clause which details x dollars per hour
Anything I'm missing?
1. Be specific on requirements
2. Have both parties agree to those requirements, with a strict understanding that additional work will not be "free" as it comes
3. Regarding payment, charge either per job or per hour, but stay strict to the agreed requirements
4. If any additions are to be made that are not in the original requirements, have a clause which details x dollars per hour
Anything I'm missing?
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
- I often put "site maintenance" as a separate contract that way, if they want, they don't need to use me (as my price is fairly high) .. but they also must have the understanding that I won't support the code if it has been modified without my approval of said modifications.
- While it may be seem a bit expensive, have a lawyer on retainer that can look over the contracts that they want you to sign. If alterations are made to your boilerplate contract (which this lawyer should have had a hand in) he'll also need to read those to make sure you don't get screwed. In the end, it's business, nothing personal.
- When I do a job level payment, I get certain percentage up front which will often be nonrefundable once work has begun. Sometimes the quote is merely a pool that I have them set up. I eat up my normal rate until it's empty at which point I halt work until more money is deposited.
- Having a strict spec is the greater saving grace really. Any alterations they make after the fact need to be incorporated into the spec as soon as possible (this has higher priority than the work itself) because it should go through a round of sign-offs again.
I've been working off of basically a template system. You can't really just say I'll charge you this much to make a website. I see way to many people doing that.
I've setup a system where I charge a set rate for 1-9 pages and a set rate for 10-20 pages with a cost for every extra page. Of course there are many other things that you charge for and limit ontop of that but I find that way to be easiest for the client.
I do small business websites and it's been working out well.
I've setup a system where I charge a set rate for 1-9 pages and a set rate for 10-20 pages with a cost for every extra page. Of course there are many other things that you charge for and limit ontop of that but I find that way to be easiest for the client.
I do small business websites and it's been working out well.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
I've always found 'page-by-page' pricing awkward. My clients are generally in small businesses who aren't even sure of the advantages of going online, so they rarely know "how many pages" they'd like to have. I just show them a bunch of flash features, a few design ideas, a few logo remakes, and describe interesting modules that they could add on. I charge more in terms of functionality than pages, as I don't like to encourage wasted space and repetition from page to page.
I make the majority of my money from setting up an articles system (watered-down blogging), RSS feeds (that they'll rarely update enough to need), and "SEO enhancements," which basically means that I remind them to update their site every once in a while, use valid markup, and "submit" the site to Google. I hate telling them that, but every SEO company says it, so if I don't they start asking.
I make the majority of my money from setting up an articles system (watered-down blogging), RSS feeds (that they'll rarely update enough to need), and "SEO enhancements," which basically means that I remind them to update their site every once in a while, use valid markup, and "submit" the site to Google. I hate telling them that, but every SEO company says it, so if I don't they start asking.