Software product pricing/cost estimation_问答_开发者

I always 开发者_如何转开发had trouble with estimating cost/price of finished software (or programming work), so here are two questions about it.

question 1:

You're asked to write a piece of code for cash (all rights to the code belongs to buyer once you're done). You know approximate number of hours it will take (+-25%), and approximate complexity (i.e. whether you can write it in your sleep or will suffer severe mental burnout once you're done). Product is written in compiled language (C, C++, etc.).

How do you(would you) pick price for the job?

question 2:

Let's say you spend a few months writing something, this thing is now finished, and now want to (try to) sell it.

Product will be extremely "Niche", and it won't be possible to sell it for large numbers of people (it is SDK, game engine, library, or something like that, not a text editor - number of people that would want it will be small). "opensourcing" it is out of the question.

You know approximate number of hours you spent, total size of files, LoC, and you have a repository with entire development history.

The result can be sold with or without source code access, for commercial or non-commercial use, or you can (try to) sell software rights.

How do you determine price for:

Rights for that piece of software?
Commercial use with source code access?
Commercial use without source code access?
Non-commercial use?

Product pricing has nothing to do with cost estimation, except for the fact the price should generally be more than the cost.

Pricing is more to do with: how much will the client pay for this software? Pricing is a difficult skill to get right - if you say a price and the client doesn't blink you've probably gone too low...

So the advice for single client (bespoke) software is to set the price at the highest you think they'll pay. If the cost of writing the software (in terms of man hours) is higher than the price they'll pay, don't take the job.

For off-the-shelf software it's just as tricky, as you need to know the size of your market. Say there are 1000 potential customers, you then need to know how many people will buy your product at a particular price. Obviously, as the price goes up you'll get fewer buyers. Again, the pricing has nothing to do with how much the software will cost you to build, it's to do with how much people will be willing to spend on it.
So if 500 people will buy it at $20, but only 200 will buy it at $30, it becomes more obvious how to price it(*). The only absolutely accurate of finding out these figures is to actually sell your product, but you can do market research (eg. ask your potential customers) to find out what they'd be willing to pay. (Contrast this with single client projects where you can't ask your client how much they're willing to pay...)

So, once you've got your optimum price, you can calculate your expected return (expected number of sales multiplied by price). If this is lower than your cost, don't write the software...

(*) I should say how knowing the size of your market is important here. If you ask 20 people from your market about whether they'll buy it at $20, and 10 say yes, you can assume 50% of your market will buy it at $20. By knowing your market is about 1000 people, you can then multiply this up to know 500 people will buy it at $20. Without knowing the size of your market, knowing that 50% of people will buy it at $20 is irrelevant.

You can find some interesting insights gathered in a (free) book of Neil Davidson: http://www.neildavidson.com/dontjustrollthedice.html

You really do need to read Joel's [/rant/humor/froth] on this http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html

For question 1, it's not that hard to find the regular hourly rate in the area you are in, just remember to add all the hours you spend on the project, not just the actual hours spend writing code... also, when estimating how long it will take to implement a software project, always have Hofstadter's law in mind ;-)

"It always takes longer than you expect, even when you take into account Hofstadter's Law."

For question 2, even though it's a bit dated by now, I still find "Information Rules" by Carl Shapiro and Hal R. Varian to be the best book on the topic. There really is no easy answer for this question, but this book will give you a good understanding of the factors you should take into account when setting a price.

Google books: Information Rules