Hi Zeero, oldguy has asked me to guest answer your question.
I’ve had some interesting adventures with web design contracts. I refer to my two favourite contracting customers as California Guy 1 and California Guy 2, and they were the source of much strife and learning in my formative years as a web programmer. I learned some things the hard way from them, so you don’t have to. I shall write about their stories in more detail on AT at a later date.
The first thing to know is that you must (must) not (not) make a fixed bid offer. No really. Fixed bids seem cool, since the customer knows for sure how much they’re paying, and the sound of that chunk of change is pretty exciting to you. Once you’re a big-shot professional who can do accurate measurements and analysis, you can consider fixed bid contracts on things you understand well. If you’re a noob, it’s an enticing trap that can consume your soul in a highly unpleasant manner.
So, you need two things – an hourly rate, and an estimate. The hourly rate depends somewhat on the difficulty of the work, but moreso on what your supply and demand is like. To get this sort of thing professionally done by a company, it tends to cost on the order of $80/hour. Individual web designers often work for more like $40/hour, of course dependent on their experience.
If you’re a great graphic designer, a great programmer, and are driving a whole web application project from start to finish, then that’s worth more than $40/hour. If, however, you’re still learning the ropes, $40 is too much. If you’re feeling really uncomfortable about the your first gig, just lowball $20/hour or something, and if you have troubles down the road, the customer will likely be more patient, knowing they’re getting a good deal.
Estimating is harder – you can take many courses and read many books on this. It’s an art: how long something takes to finish will vary a lot depending on your experience, how you manage the customer, how eager the customer is to change their requirements, and technical issues. The most important part of estimating is to get a detailed list of requirements for what you’re estimating. This includes things like the size of the site, exactly what features it needs, any technical restrictions… as much as you can include. The more detailed and specific your requirements are, the less risky the whole thing will be. You don’t want to end up 60 hours into the project and have your customer say, “well when we agreed the design would work in common browsers, I assumed that included Netscape 4″. Of course, making a site look good in Netscape 4 is virtually impossible and should not be attempted by any sane person.
Three extra tips: Don’t get sucked into doing a lot of unbilled work (i.e. gathering requirements and fixing bugs are billable). Keep track of what you spend all your time on, especially the time caused by last-minute requests or changes. Bill the customer on a regular basis – monthly, for example. That way if the project goes long, you’re not kept waiting. As a side note, that epromos.com site you linked to would be a huge pain to upkeep without a database backend using something like PHP or Ruby… or JSP I guess.
So those are the basic basics of starting a web design contract. Good luck!
ensignyu interjected: Dear Oldguy,
Imagine the following hypothetical scenario: you’re trying to prevent automated creation of accounts by ensuring that a visitor is human. The challenge must be text-only, solvable in about a minute or less by humans and impractical to solve by bots. You have access to only publicly available databases and databases you create yourself, but the attacker has far more time than you and can attempt the challenge a reasonably large number of times.
How do you tell who’s human?
- Allen