VC Due Diligence

Hidden Risks for VC Investmet in Techs?

Posted on Posted in PE, Private Equity, Venture Capital

The rapid pace of innovation in the Technology sector is attracting both venture capital (VC) and private equity(PE) investment into UK companies and the bulk of that investment is in London based organisations. Q1 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 inundated with dealflow. This is driving how investors exercise risk assessments. Early stage investors would be 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 then there is unlikely to be investment in the organisation.

Risk versus Reward

There are good reasons why a VC should be cautious with their investment money. Generally they are taking 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 being a sound investment if reasonably straightforward as there is a track record of sales, profits and cash flow with early stage ventures a VC will delve deeper into the business, the opportunity and the underlying technology behind the business.

The key considerations by late round investors will be:

  • Management – Who is the team behind the organisation and what is their track record?
  • Size of market – Demonstrating the target market opportunity which will indicate the returns investors might expect from any investment.
  • Great Product – Investors want to invest in great products with a completive edge that are long lasting and sustainable.
  • What is the current revenue status of the early stage company? Are they generating sales and future pipeline prior to any investment.
  • What are the risks – a VC  is taking on risk and their skill as an investors is understanding all risks and making fully informed decisions for a successful outcome. The two main areas a VC will focus.

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:

  • Board member status for investor a requirement.
  • 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 an investors look at will depend on whether it is an early stage investment or a late round investment.

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

Outside of the technology early stage investors would 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 would 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?
  • Regulatory or legal risks

Technology Risk

Following from the strategy review will be a technology review. Typically the focus will be on the ability of both the software and the development to team to deliver on the products 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 that software development leverages open source software. There may well be a valid reasons why a start-up would not use open source software but in the due diligence of a dealflow the start-up would 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
  • Intellectual property value – an objective view of the software’s unique value in the market
  • Intellectual Property 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 code review can either be initiated by the technology organisation prior to 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 the investors will view the investment as risky regardless of the functionality of the technology in question

Why VC Due Diligence Should Include an Independent Source Code Review?

Apart from identifying current issues in the source code such as licensing irregularities, problematic IP or potential security vulnerabilities in software components which typically can be remediated, reviewing the source code could identify inefficiencies or flaws in the development process.

It could identify the need to have a proper code inspection process during the development cycle, thus eliminating the issues earlier.

It may be appropriate to create an open source software adoption process with proper tooling can help lower your costs of compliance, not to mention minimising disruptions during key transactions. Similar to bugs in software 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 a 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, PHP. The Source Code is compiled into an executable which the target device will execute.

What is a Source Code Review or Audit?

A Source Code review or audit should be performed by an independent third party specialist in this area of expertise. If you are a VC or private equity firm it is unlikely that you would have these skills in house. If you are a software company seeking investment it is likely you would have somebody in house who would have the skills needed to perform the review however they may not be able to produce a reliable and objective report.

Why is a Source 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 very dynamic and agile development but with it there are 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 will 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 – Can the application be evolved over time
  • Viability of the open source community around the components being used

Fundamentally it boils down to assessing the overall quality and consistency of the source 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 the personal style and approach but in line with the organisations standards which all developers should follow.

What is the Process for a Source Code Audit

  • First an 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 then produced and agreed. This will include:
    1. A breakdown of Software Portfolio into audit segments
    2. Full automated source code scanning, analysis and reporting
    3. Resolve copyrights, standard headers and author tags discovered in the portfolio
    4. Analyse, verify modules and issue regular audit progress reports
    5. Quality review and sign off of licensing and copyright attributes of every software file in Software Portfolio
    6. Delivery of audit report(s), review of the reports
  • The report will be reviewed and signed off by the organisations 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 high level information and graphic representation of licences, copyrights, OSS projects, security vulnerabilities and encryption content within Software Portfolio. Source Code Control Audit report is delivered in pdf format.
  • Overview Report and Detailed file-by-file Reports: verified machine-generated reports on Software Portfolio. Overview Report shall be delivered in pdf format. Detailed file-by-file Report shall be delivered in in CSV (readable by Microsoft Excel application) format.
  • Concatenated Licence List report: containing a consolidated text of all available licences within 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: list of OSS projects detected in the portfolio that could be subject to export control, in pdf format.

Conclusion

Whether you are a technology organisation seeking investment or a VC or PE organisation investing in technology organisations there is a typical process of due diligence reviewing business strategy, business risk, technology risk, technical architecture and source code risk.

It is imperative that there is transparency of the make-up of the underlying source code related to the technology. Any undeclared risks in the code could potentially devalue a return on investment. A code audit should not be a one off exercise but should be part of all stages of the development process. The end result will be quality code, secure code and licence compliant code.

2 thoughts on “Hidden Risks for VC Investmet in Techs?

  1. Well constructed and very relevant article, thanks Martin Callinan. This is an area that is frequently missed, even in corporate companies developing their own internal apps miss the point.

  2. Great article, thanks Martin. The number of times I’ve heard developers say “its a great plugin, and its free” – but their definition of “free” is that they didn’t have to pay to download it. They definitely haven’t checked whether its free for commercial use, whether a license is needed per developer, per site or per application. Or maybe it just needs fair attribution. If I had to guess I’d say most custom developed software has unlicensed components in them somewhere because it’s just almost impossible to stop them being introduced accidentally.

Leave a Reply

Your email address will not be published.