Comment by saranagati | Hacker News Reader

Comment by saranagati | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com