I am so incredibly horrible at estimation that I bid more with emotion.
If I find the project very interesting and I can fall in love with building it, the client is going to get a good deal. Boring or otherwise tedious projects engender some stone-cold, take-it-or-leave-it negotiation. I mean, this is my free time.
A great tool that I've come across for helping out with setting your rate is at http://freelanceswitch.com/rates/. It got me thinking of many areas of expenses that I hadn't considered.
It is geared more to those of us doing it full-time.
It's a good summary on a several techniques, how to apply them, and how to pick how in depth of a one to do, as well as how to talk with people who try to negotiate with them.
it amazes me how few people who do contract work create a requirement docs. Before you even give the potential client a quote, create a requirement doc of every little feature that will be included in the project. Then show it to the client to make sure nothing has been missed or out of scope. Once you have this list you can accurately estimate how long each little piece will be to do. Add in the time it takes to create a requirements doc, an additional % to account for how much time will be spent communicating with the client and anything else that might be specific to that project and you've got yourself a quote.
Another benefit of a requirements doc is if the client later says he expects some additional feature, you can refer to the requirement doc and say that it'll cost extra since it's not listed in there and your original quote didn't include it (or let them know that you're going out of scope for free because you want to help them out which will make them love you [only do this if you're ahead of schedule]).
Also back when I was doing freelance stuff I usually wouldn't even take a gig if I didn't think I would make > $5,000 from it.
The problem is often that the work is not clearly defined. Sitting down and thinking about the project, what the client asked for vs. what they really need, listing the unknowns, doing some tests to validate an approach... this can take a lot of time.
What I want to start doing with projects that aren't clearly defined, is to simply do an initial contract to nail down some of these details. Build a prototype, do some tests and write a detailed spec - and then the next contract will be building it for real. (Maybe with some inexpensive outsourcing.)
so basically what you're saying you want to do is do work for clients who have a high probability of not paying you because they don't even know what they want. This can still be accomplished but it still needs a requirements doc. Let them know that they'll be charged for an initial requirements doc, then you'll create a prototype, then a rewrite of the requirements doc. Also charge these clients a 50% retainer for this part of the project.
Prototypes aren't as useful as you would think. Clients see them and are like "hey that's a nice mock up, now make what I want", then you build the actual application and they say "well where's feature X, Y and Z?!?! when you say it wasn't in the prototype they just say "well I thought it wasn't there because it was just a mock up"
Ideally though, you want to charge them for the requirements doc (and get paid for it) before you start the actual project. You can usually tell the client this and tell them they can use the requirements doc to shop around with other developers so they can get the best deal. Clients are usually happy with this and usually don't bother shopping around.
Best way I've found is to start out on hourly gigs, until you have a sense of how long certain tasks take you. With experience, you get better at estimating your time.
EDIT: Oh and when you start out, if you're estimating time, double it.
Also, start out on hourly gigs - and then always stay with hourly gigs (time & materials). If you fixed price work you end up having to piss off clients with anal scope management (or you take a bath).
What I do for estimations, is to break tasks into small pieces, then estimate each piece, and add the total. As someone said, it is highly advisable to still double the total.
One of my customers, which I greatly admire, is very old guard and don't buy nothing of agile, extreme, scrum, etc. He only accept strict a to b estimates. Working with him, while hard, has made me much better at making estimates.
Heh, I've also got problems with estimating the end price. Mostly I think: WTF?! I can't charge that much for this simple work. I always forget that the "simple work" is black magic to most of my clients.
