When you buy a software company, you are buying it for the customer base, market opportunity, and the solution. You are not just buying a set of assets, but rather you are buying value creation capacity. The solution is a mix of the team, the codebase, and the way of doing business – People, Product and Process. All three have combined to create the company you are now targeting, and to foster the customer relationships that represent the revenue being generated by that company.

The classic technical due diligence focuses on things like Open Source licensing, automated code scans, scalability concerns, source code commenting, intellectual property agreements, etc. These are all important (well maybe not as much for source code commenting), but for most companies the bulk of the risk lies elsewhere.

Three key bets to think about are:

- Do you have or can you find the people you need to take the product forward?

- Can the product change without starting over or having to significantly rework the current shipping version to meet the new customer segments that you're targeting?

- Can you grow the customer base profitably and not have to "throw bodies" at process-related issues?

In coming posts, I'll share questions you can ask in each of these key bet areas early in your evaluation process (even if you don't have a technical background) to surface potential show stoppers sooner and head off costly discoveries closer to the transaction.