We all dream of creating the next big thing, getting that investment that will help get us over the finish line, landing the partnership with one of the big players, getting acquired by one of the global giants. But as we race to innovate, stay ahead of the market, and surprise our customers with bigger and better offerings than they even imagined, we have to pass that dreaded series of hurdles: technical due diligence.
Technical due diligence is the process of analyzing and evaluating the technology, product, architecture and processes in an organization prior to the acquisition of a company or an investment in it.
Reasons for a due diligence process may vary, they could come from a VC firm, an investment bank, an acquiring company, or a possible OEM (Original Equipment Manufacturer) deal, but they all want to get down to the nitty gritty: How much are you really worth? How much can your offering bring in? Is your organization equipt to deliver on all of your promises? Are you really a lemon dressed up in a new paint job?
Whatever the deal, you can be sure that investors, buyers or potential partners will want to take a close up and personal look under your technology’s hood, not to mention give the tires a few good kicks, to make sure they know what they’re getting into and how much they can get out of it before taking the plunge.
Any interested party will require analysis of the technology and product development used by a company seeking funding or for sale, to make sure that their investment is solid.
We’ve put together the top five factors that we recommend you consider to make sure that you can present interested parties with a comprehensive and clear picture during the technical due diligence process.
You need to be prepared to present and describe your technology, as well as provide documentation, including architectural charts, scalability, and performance indicators. Another issue that’s commonly addressed is how your technology and product compare with your competition’s offering.
For infrastructure, be ready to explain the underlying technology choices, like programming languages, databases, app servers, and other tools and technologies that compose your product.
Make sure that you archive documents. Think anything from product design documents, architectural descriptions and API documentation that you have created over the years, to PoC results, and operational metrics.
You also need to be prepared to describe the development and deployment environments and the tools used. Keep in mind that in addition to configuration management and build tools, an interested party will also want to hear about open source components, and third-party tools, deployment, and patch tools. Where relevant, you will need to show interoperability with common standards and integration with other products in your ecosystem.
When possible, present the technology’s past, showing what led your team up to this point. Provide a history of the problem, failed attempts to solve it, and what has changed that enables addressing the issue now with your technology.
Scalability is also a major area of concern, especially when assessing startups that have yet to deploy their solution with larger customers and systems. Make sure to keep the data of all empirical tests that your team has performed.
A copy of all source code will also be requested, but in most cases this doesn’t require preparation and should be easy to provide.
Since security is always one of the top concerns, documentation of security vulnerability scans and penetration tests that your teams have performed is necessary. Today, many automated tools are capable of collecting this information for you and swiftly providing reports.
WhiteSource pro tip: Don’t forget to track and report the security of the open source components in your code. Vulnerable open source components are increasingly becoming a popular attack vector for hackers (who said Equifax?), who are often quicker to follow up on newly published vulnerabilities that the organizations than use them, making the stragglers into easy targets.
We all know that the secret sauce in tech offerings is always the team creating and maintaining the product. So do the investors. You will need to provide an organizational chart with roles, highlighting your key players. In addition, you’ll need to provide a list of contractors and outsourced resources and roles.
Keep an updated organizational chart. Keep the resumes of all employees and contractors, as well as their contracts, along with anticipated employee and contracted costs for the current year.
Maintain a list of people and their skills, matched with the different parts of your product, and development, maintenance, operations, and support roles. It also helps if you provide details on staffing or contracted roles that you wish you could invest in, and how you think they would help your organization.
Managing people to create and maintain your best-in-class innovative offering requires a plan and a system. This is where you need to provide the information about your organization’s development, quality assurance, and security testing processes, as well as deployment, operations, and support processes. You need to prove that your processes are effective, cost-efficient, and that they can support continued development of your products.
Once again: be proactive with your documentation. Document all of your organization's processes, the people involved, resources, costs, and timetables. Keep all MRD/PRD documents that you have created and implemented. If you can, use automated systems like bug tracking and QA to track each of these processes.
Be prepared to provide reports on performance metrics and KPIs like time to version release, time to support request response, and time to fix critical bugs and security issues.
Some see intellectual property as one of the most important assets in an acquisition or investment. As part of the technical due diligence process, it’s imperative that you show the strength of the technology that you’re developing.
You will need to present the patents that protect your IP, as well as the freedom to operate, meaning that you are not infringing on intellectual property that isn’t your own. You will also be required to include an exhaustive list of the third-party components that are a part of your software, including free and open source components and commercial libraries.
Compliance with the licensing of all your third party and open source components is also mandatory, and you will need to prove that your organization is compliant with outside licenses.
Stay on top of documenting your organization’s patents, as well as patent searches that demonstrate freedom to operate. Track the open source components used by your team, including all dependencies, licenses, and source, and be ready to show that your organization is compliant. Third-party components, come with agreements and payment documentation — be prepared to present all of these documents.
Your potential acquirer or investor will need to know the specifics of your plans for the future of your offering, as well as which new products and features you think are important to the continued success of your solution.
Document release history as well as planned versions of your solutions. Prepare documentation of all roadmap options that were considered by your organization, along with an assessment that shows which options are both strategic for you and beneficial for customers. You can also provide PRD/MRD documents for future product directions. Keep a wish-list of features requested by your customers.
If you need help tracking the open source components as part of your technical due diligence — and let’s be honest, it’s a mammoth task if you’ve never done it before — you might want to call in an expert to perform an open source audit.
An open source audit identifies all the open source components, licenses, and security vulnerabilities in your proprietary software. Done by a certified auditor, an open source audit gives you a risk analysis of your open source use with actionable insights.
There you have it, our cheat sheet for starting the technical due diligence process off on the right foot. It might look like piles of documentation, but in actuality, if you keep your eye on the prize, it’s mostly a matter of remaining compliant throughout your operations and documenting as you go.
There are more and more tools today for managing, tracking, and reporting the state of your software’s bugs, releases, versions, licenses, vulnerabilities, compliance and more. If you make sure the right tools and practices are in place, you can breeze through your company’s due diligence process and be one step closer to closing the deal.