Hacker News Reader

Comment by thetrumanshow | Hacker News Reader

My last 3 side-projects (while working fulltime at BigCo): $750, $750, $2700

Over time, I have become less and less interested in these kinds of side-projects as I have become more focused on owning the upside of my own products. But, its occasionally nice to get paid for my late-night coding adventures.

View on HN

How do you go about doing estimation? When you are asked for a bid and have loose requirements what are some good practices for estimating?

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.

Edit: Nevermind that extra bit, however true. :)

I wrote a blog post you might find interesting that talks specifically about quoting web design projects: http://devgrow.com/how-to-properly-quote-a-client/

That's how I go about it and have found it to be the best/only way to ensure I don't overwork myself.

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.

Check out (non-aff link) http://www.amazon.com/Software-Estimation-Demystifying-Pract...

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.

and then switch to next higher time unit (without changing the number)

This has worked for me. I estimate it will take 8 hours - quote 16 days.

I never thought about this before, But surely will keep it on Mind next time i'm quoting a gig.

And then add half again.

that's the secret, 3x.

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).

A number between e and pi.

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.

Do you have projects that generate cash flow? If so, how did you decide on those projects and how long did it take for you to see a meaningful amount of cash flow?

Just a trickle of cashflow, and it took ~2 years of generating enough traffic from various sources (other projects) to drive the trickle that I have now. For a ballpark, if the current growth is sustained, the trickle should be enough to buy a car in just over a year.

The concepts for the things I am building now were distilled from several other failed ventures. The choices were based on the projected market sizes.

Reply on news.ycombinator.com