Husein wrote: Once I read somewhere (and I really don't know where) that software, being an intelectual property, should be looked at the methods developed, time taken to develop the methods and some other things, multiplied buy some third thing, and when you add everything together you you would get the approximate price. Well, if the only variables you have are the development costs, you'll end up having only a cost assessment. Anything that is bigger than your costs will give you profit. There's no such a thing as a "fair price". IMHO, the determining variable for your software's price is how much value your customer sees on it, no matter how much effort you put on it. As a sample, two extremes: Software A: Done in 3 days, poorly documented, buggy, ugly, lots of features are missing. You were the only programmer on the project. But it saves half a million dollars per day, if used by your customers. Your customers nor your competitors have no idea on how to create such a software. Software B: Done in 3 years, throughly documented and tested, design by Pininfarina, every possible feature is implemented. It needed a 80 programmer effort. But there are another 432 competitors in the market, all cheap, selling their software for $20. The software doesn't save the customer a cent. Which software do you think the customer will pay more? So, function point counting or estimation (I think it's what you referring to), is only used when you are doing custom development, i.e., you're only making a development task for someone. But, for determining the price of a product it helps nothing. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn