Reducing risks in VC investments Part II: investing in software

"finance & Insurance" due diligence risk software Venture Capital

Reducing risks in VC investments Part II: investing in software

Here's the second part of a two-part feature on venture capital, risk and investment, by Martin Callinan (Source Code Control) and Kate Andreeva (Protecode). Their first post dealt with general issues regarding due diligence. The sequel, below, focuses on the special issues facing anyone thinking of investing in innovative software.

Technology risk

Not just the software: the business
strategy must be robust too 

Following the strategy review comes a technology review. In the case of a software-driven enterprise, the focus is typically on the ability of both the software and the development team to deliver on the product roadmap in line with the investor’s timelines. There will be a detailed review of the software architecture, code quality, software engineering quality, scalability, and robustness. 

If the company is a software start-up, an expected pre-requisite is that software development leverages open source software. There may well be valid reasons why a start-up would use open source software but, in the due diligence of a deal flow, the start-up will need a clear and strong justification as to why open source software has not been used. 

The reality is that many young companies do not understand the value of intellectual property and risks that can be engineered into software applications.  The types of risks that investors will look for are: 

• Software architecture, scalability, and extensibility

• Exposure to third-party platforms

• IP value: an objective view of the software’s unique value in the market

• IP and patent evaluation – are there any patent infringements?

• Third party dependencies

• Open source software risk exposure

To identify these technology risks, typically a third party specialist will be contracted to perform a source code review. This review can be initiated by the technology organisation before seeking investment, by the VC or private equity organisation as part of the due diligence process, or both. If the organisation goes into a funding exercise without visibility of the quality of their code and associated risks, there is a good chance that investors will view the investment as risky, regardless of the functionality of the technology in question 

Why due diligence should include an independent source code review

Apart from identifying current issues in the source code, such as licensing irregularities, problematic intellectual property, or potential security vulnerabilities in software components, which typically can be remedied, reviewing the source code can identify inefficiencies and flaws in the development process.  It can also identify the need to have a proper code inspection process during the development cycle, thus eliminating problems before they arise. 

It may be appropriate to create an open source software adoption process with proper tooling, which can help lower compliance costs, not to mention minimising disruptions during key transactions. Similar to bugs in software, it is far more efficient and cost-effective to catch issues early. 

Before discussing source code reviews it is important we are clear what we mean by “source code.” 

What is source code? 

Source code is a set of programming language statements and commands a software developer creates that becomes part, or all, of the applications that use website or device runs. There are a plethora of languages used by developers such as C, C++, C#, Java, or scripting languages such as JavaScript, PERL, Python, or PHP. The source code is compiled into an executable which the target device will execute.

What is a code review or audit? 

A code review or audit should be performed by an independent third party specialist. VC and private equity firms are unlikely to have these skills in-house. A software company seeking investment is however likely to have somebody in-house with the skills needed to perform the review – but that person may not be able to produce a reliable and objective report. 

Why is a code review imperative? 

Developers today rarely code a complete application from scratch. Applications are made up of components of code from a variety of sources which are stitched together to create the finished application. This makes for dynamic and agile development, but with it comes a number of inherent risks. Each component will have a number of attributes, such as how it is licensed and its version. 

Outside of the function of the application(s), investors need to have details of the make-up and provenance of the code components in the following areas: 

• Intellectual property and licensing

• Security of the software

• How the software be maintained and supported

• The capabilities and maturity of the components being used

• Ability to integrate with other applications

• Quality of the components that make up the application

• Innovation – if the application be evolved over time

• Viability of the open source community around the components being used

Fundamentally, the review boils down to assessing the overall quality and consistency of the code. The source code is an indicator of the quality of the organisation seeking investment. Software development is a creative exercise and developers should be allowed to express their personal style and approach, but in line with the organisation’s standards which all developers should follow. 

The code audit process 

First, a non-disclosure agreement (NDA) must be in place between the reviewer and the organisation. Once the NDA is in place, the reviewer will question key stakeholders in the organisations to ensure there is a clear understanding of the reasoning behind the audit and the organisation’s environment, such as the size of the portfolio, languages, and tools in use particularly any automatic code generators. A Statement of Work is then produced and agreed upon. This includes:

• A breakdown of the software portfolio into audit segments 
• Full automated source code scanning, analysis, and reporting 
• Resolve copyrights, standard headers, and author tags discovered in the portfolio 
• Analyse, verify modules, and issue regular audit progress reports 
• Quality review and sign off of licensing and copyright attributes of every software file in the software portfolio 
• Delivery of audit report(s), review of the reports.

The report will be reviewed and signed off by the organisation's management. Once signed of the final reports will be completed and delivered to the organisation. The reports will include:

• Audit Report: a high level executive report, containing information and graphic representation of licences, copyrights, OSS projects, security vulnerabilities, and encryption content within the software portfolio.
• Overview Report and Detailed file-by-file Reports: verified machine-generated reports on the software portfolio. The overview report should be delivered in pdf format. A detailed file-by-file report should be delivered in in CSV (readable by Microsoft Excel application) format.
• Concatenated Licence List report: containing a consolidated text of all available licences within the software portfolio in pdf format.
• Security Vulnerability Report: a cross reference of all security vulnerability information as reported by the National Vulnerability Database in pdf format.
• Encryption Report: a list of open source software projects detected in the portfolio that could be subject to export control, in pdf format.

About the authors

Martin Callinan has over 20 years’ experience in the software industry with a focus of Software Asset Management, IT Governance, and risk avoidance. He is currently the director at Source Code Control. Martin contributed to Working Group 21, the group responsible for authoring Standards relating to Software Asset Management, such as ISO/IEC 19770-1. In the past, he worked for Microsoft Limited, FrontRange Solutions, Centennial Software, Snow Software, and Express Metrix Limited.

Kate Andreeva is the Director of Solutions at Protecode and has over 15 years’ experience in the technology industry as an engineer and sales professional. With a background in electrical engineering and software development, Kate has honed her skills at companies including Performance Technologies, Level Platforms, Klocwork, and Coverity.

Reducing risks in VC investments Part I: risk and due diligence

"finance & Insurance" due diligence risk Venture Capital

Reducing risks in VC investments Part I: risk and due diligence

If only ...

Here's the first part of a two-part feature on venture capital, risk and investment, by Martin Callinan (Source Code Control) and Kate Andreeva (Protecode). This post deals with general issues regarding due diligence, which this blogger regards as a small headache that one suffers in order to avoid a heavy hangover at a later stage. The second post, which will be published tomorrow, focuses on the special issues facing anyone thinking of investing in innovative software.

What should be included in the due diligence process?

The rapid pace of innovation in the technology sector attracts both venture capital (VC) and private equity investment into UK companies, with the bulk of investment in London-based organisations. The first quarter of 2015 saw London technology smash previous funding records. The amount raised by London companies comprises 80% of all UK companies with a value of $856.7m.With the technology sector being so buoyant, investors are inundated with deal flow, which influences the way investors exercise risk assessments. Early stage investors would review a few good companies each week. With such a competitive landscape, the challenge for technology entrepreneurs is getting the attention of investors. Key to this is clearly presenting the company’s strategy. A solid business plan is important but, if the overall strategy is weak, investment is unlikely to result.

Risk versus reward 

VCs are cautious with their investment money with good reason. Generally, they take enormous risks on untested ventures which they hope will eventually transform into the next big thing. With mature organisations, the process of establishing value and the prospect of a sound investment is reasonably straightforward, as there is a track record of sales, profits and cash flow with early stage ventures, VCs will delve deeper into the business, the opportunity, and the underlying technology behind the business.

Key considerations by late round investors include

• Management: who is the team behind the organisation and what is its track record? 

• Size of market: demonstrating the target market opportunity which will indicate the returns investors might expect from any investment. 

• Product quality: investors want to invest in a great product with a competitive edge that is long-lasting and sustainable. 

• Current revenue status of the early stage company. 

• Generation of actual and pipeline sales prior to any investment. 

• The risks: VCs take on risk; their skill as investors is understanding all risks and making fully informed decisions for a successful outcome. 

The entrepreneur needs to understand that not all money is the same and not all funding sources are equal. The entrepreneur must carefully consider the implications which may follow from the investor and other requirements of various financing sources. Some examples:

• Require board member status for investors.

• Require the employment of advisors.

• Require the creation of an advisory board.

• Investor invests and observes, but does not play an active role.

Business risk 

The business risk investors look at will depend on whether it is an early stage investment or a late round investment. 

The skill of early stage investment funds is being able to identify the potential of a technology even if the product (today) is not right or needs significant evolution to become successful. This way allows an early stage investor to maximise its return while minimising its initial investment. 

Outside of the technology, early stage investors will view the current revenue status of the early stage company to decide which investment fund(s), if any, the company would fit into. 

Late round investors would, by nature of the investment, seek clarity in the company’s business plan, which would include:

• Is this the right product for today and the future?
• Is there enough money in the fund to fully meet the opportunity?
• Is there an eventual exit from the investment, a chance to see a return?
• What are the regulatory or legal risks?

About the authors

Martin Callinan has over 20 years’ experience in the software industry with a focus of Software Asset Management, IT Governance, and risk avoidance. He is currently the director at Source Code Control. Martin contributed to Working Group 21, the group responsible for authoring Standards relating to Software Asset Management, such as ISO/IEC 19770-1. In the past, he worked for Microsoft Limited, FrontRange Solutions, Centennial Software, Snow Software, and Express Metrix Limited.
Kate Andreeva is the Director of Solutions at Protecode and has over 15 years’ experience in the technology industry as an engineer and sales professional. With a background in electrical engineering and software development, Kate has honed her skills at companies including Performance Technologies, Level Platforms, Klocwork, and Coverity.