How to present your code to potential buyers?

Answer 1

If they're non-technical, it won't matter. It will be like trying to sell a high-end bike to people who don't know a bike from a car. 15k lines of code won't matter to them any more than 300k lines of code will.

You need to find something other than the actual code to wow them with.

Can you code up some demos and tell them how short time it will take them to build similar applications with your code? Like "If you use my code, you can build this multimedia application in 15 minutes without writing more than a few lines of code". Non-technical people generally love saving time and money.

It probably depends on how "slightly" they are in the non-technical department.

Answer 2

"good code" doesn't matter unless you are demonstrating the medium and long term advantages of it - enhanced flexibility, simplicity, which saves customer time/money while adding agility.

Answer 3

I think explaining the more complex aspects of the code and the work that went into it to any audience will help show how much work and effort have gone into a project.

Hours spent coding could be a good metric to give them.

Answer 4

I wouldn't use code per se, since a non-techie wouldn't understand it. Boasting about quantity is probably meaningless (how does a non-techie know that a 1MLOC project is significant? As for quality, you can present, e.g., maintainability metrics, test coverage, things like that. Feel free to show off your excellent toolchain too (continuous integration and all that), your mastery of various performance-testing tools. Also, showing things like Workflow Foundation helps - customers like to see how their business processes can be turned directly into code with a diagram notation.

Answer 5

Talk about the features. Explain what you have working or almost working. Go at it from what they are interested in.

Try to show them visuals that they care about if you can. I think a few minutes doodling on a board would be better than showing lines of code.

Answer 6

The only thing that is likely to matter to a buyer (particularly a non-technical one)is functionality. I would concentrate on selling the features. You might consider discussion how you have tested it to verify that it performs as you claim.

Answer 7

It's not clear to me from your question whether you're talking about people who would buy the use of your product or ownership of your product.

In either case, ask yourself these questions:

• "What problem(s) does this product solve for my users, from their point of view?"
• "What does this product let the users do, that they already want to do, but can't do without it?"
• "What does this product let the users do, that they already want to do, but can't do as easily without it?"

Features don't matter. Menus and dialogs don't matter (unless they require explanation, in which case they matter in the negative sense).

If you want numbers that interest a potential buyer of (an instance of) the product, talk in terms of how much time or money the buyer can save by using your product.

If you want numbers that interest a potential buyer of shares in your company or product, talk in terms of the size of the market, how you've analyzed that market's needs, and the ROI of any investment.

Answer 8

EDIT modified to reflect OP's clarification (in comment here) that these potential buyers are looking to re-sell the software

Re-sellers are going to be looking for three things:

1. Is anyone going to make something better, cheaper or more quickly?
2. Is this guy going to be able to use our investment effectively to produce more?
3. Can we sell what this guy has produced, and will produce?

How to address points 1 and 2 have been very well addressed in other answers, but it's question 3 which is the hardest to prove for us techie people. It's also extremely important - if you can go to these buyers and hand them 3 killer benefits which they can repeat with more flair and Powerpoint when they're doing their sales calls, you'll be off to a good start :)

The main thing you have to do is to take a step back from your work and look at the:

• features: what does it do
• advantages: why is it better
• benefits: why should the customer care

Features are closest to what you care about as a developer, but are pretty much irrelevant to non-technical buyers. Advantages are an essential step in understanding your competition and the customers' alternatives.

By putting features and advantages together, you can hit the customer with a number of benefits, e.g.:

• using my software will save you $0.01 per transaction, or $40,000 p.a.
• my software will increase customer retention by 5%
• your admins will need 15% less time to deploy changes using my software

These are the things that customers care about: what's going to be good for the company, and good for them.

To be brutally honest: the end customer don't care how much effort you put into it (LoC or any other metric), they don't care how well it's written (comments, tests, any other metric), they don't care how hard a problem it is to solve, they don't care about features.

Their only requirement is that it will save them time / effort / money. You know that how hard you've worked to solve the problem, and solve it well, is key to their requirement, but it's secondary. You need to make it perfectly clear why them buying their stuff will mean they'll get promoted.

Answer 9

I've had success showing potential customers our automated build cycle, in slideshow form. I took them through our "production line" as if it was a factory tour, and showed the nice colored bars of coverage reports, uptilted lines of historical lines of code, pie charts of breakdowns of lines of code per module.

Then I did the same for everything aroung the actual building. So there's a requirements pipeline where they are involved, and a test/validation cycle where they are again involved.

It may not mean anything to them, but it shows them you have control over your process, and control over the quality of the delivered end product.

Please note that although people may be non-technical, try to be as honest as possible. As soon as they discover one single tiny lie in your story, you're lost. And chances are that there's that one technical guy in the back who can ask that one question which makes your house of cards fall down.

Happy sales!

Answer 10

An investor only cares about money. Investors start at the exit and work backwards. Knowing this, pitch your project in terms of the return they will get in their investment.

Key points would include:

• Your expertise: Do you know the market you want to sell in to? Are you leveraging your expertise in some way to make the project a reality?
• Risk: Using your already existing code base lowers risk in terms of both time and money. They will probably do technical due diligence to validate your claims, so be honest here.
• Time to Market: Having a code base in place will reduce their time to market, which may be significant.
• Vision: They need to know that there is a future for your product. This is your chance to get them excited!

Investment is about the future, not the past, so understand that you need to achieve what you are promising. The path you trod to get to where you are now may be interesting, but largely irrelevant to the investor. What I'm trying to say is sell the vision, not where you are now or where you've been.

Good luck and hope you get what you need!

Answer 11

For COCOMO - Project Cost Estimation

I found this website, it's kind of a manual process but it'll do.

http://www.cms4site.ru/utility.php?utility=cocomoii