We all dream of creating the next big thing: getting that investment that will help us over the finish line, landing a partnership with one of the big players, or getting acquired by a global enterprise. But as we race to keep ahead of the market and surprise our customers with bigger and better offerings than they ever 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 an M&A of a company or an investment in it.
Reasons for a technical due diligence process may vary. They could come from a VC firm, an investment bank, an M&A, or a possible OEM (original equipment manufacturer) deal, but they all aim at answering these questions:
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.
This is part of an extensive series of guides about Compliance Management
While there is no industry standard for a technical due diligence checklist, there are a number of areas that interested parties will inquire into. We’ve put together a checklist of factors you will be required to address in a technical due diligence process, The checklist includes prep tips so that you can present interested parties with a comprehensive and clear picture during the technical due diligence process.
You need to present and describe your technology and provide documentation. This includes 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 application security has become a top concern, documentation of security vulnerability scans and penetration tests that your teams have performed is necessary. Today, many automated application security testing (AST) tools are capable of collecting this information for you and swiftly providing reports.
Mend pro tip: Don’t forget to track and report the security of the open source components in your code. Vulnerable open source components have become a popular attack vector for hackers who are often quicker to follow-up on newly published vulnerabilities than the organizations that use them.
We all know that the secret sauce in tech offerings is 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 software development processes are effective, cost-efficient, and that they can support the 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 (market requirements document) /PRD (product requirements document) 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 — also known as an attribution report — 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 your 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.
There you have it, our checklist for getting your technical due diligence off the ground. It might look like mountains of documentation, but in actuality, if you use the right processes and tools, it’s not as hard as it seems to remain compliant throughout operations and document 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, security vulnerabilities, compliance, and more. If you make sure the right tools and policies are in place, you can breeze through your company’s technical due diligence process and be one step closer to closing the deal.
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of Compliance management
Authored by Stoke
Authored by Stoke