What is a Technology Due Diligence?

Investing in technology companies or “tech-enabled” companies involves the classical due diligence work streams such as commercial DD, legal DD and financial DD. But nowadays, these are typically complemented by a Technology Due Diligence a.k.a. “Tech DD” - or to be more precise: Technology and Product Due Diligence. Conducted to ensure that technology and product development setup of a company are sound, it analyzes the impact of technology on the investment opportunity.

The idea is to have subject matter experts (usually former CTOs or CPOs with a strong technology background) inspect all relevant aspects of the technology and product value chain (sometimes also “value stream”). The experts typically uncover a variety of technologically rooted insights that support the investor or other stakeholders in making a fact-based investment decision and to identify value creation levers or even synergies for the time after the transaction.

What is typically covered?

While TechMiners assesses over 100 “Maturity Topics” (along Technology, Team, Product and Scalability), possibilities are endless and need to be tailored to every investment case.

Read more
Which common risks are assessed?

Beyond obvious risk classes like cybersecurity or open source licenses, indirect risks from team scalability or foreseeable dead ends in data architecture carry more immediate business impact.

Read more
What to
expect as a deliverable?

While content cannot be altered, structure can be tailored to specific audiences and make a difference, e.g. internal investment committee vs. a local bank that provides debt on the deal.

Who performs a Tech DD and when?

There are different scenarios in which a Tech DD is commonly considered. The obvious one is an upcoming transaction: the buy-side, i.e. investment teams of funds (mostly VC or private equity) are seeking a detailed understanding of a company’s product and technology setup. Their goal is to reduce the risk of investing into that business on the one hand, but also to uncover competitive advantages and opportunities for value creation. The desired outcome is to raise red flags (if any) and to receive actionable recommendations on prioritized initiatives for the post-transaction phase (e.g. process automation or more efficient use of data).

There are also situations in which the “sell-side” is interested in performing a Tech DD, i.e. internal stakeholders are seeking tech insights on their company. The focus here is less on understanding the technology, and the Tech DD will rather focus on potential optimizations to increase product development speed, or on alleviating growth pains. Such a Tech DD is sometimes also referred to as a “technology health check” spanning development practices, team structure, and processes. Apart from seeking advice or sparring from a seasoned CTO, a technology health check can also prove useful in preparation of a fundraising or sale of a company. When a business enters a new growth stage, it is worth having a look at available and required skill sets for certain key positions (e.g. CTO, CPO) and consider filling gaps by training or adjusting hiring goals.

TechMiners can support your Tech Due Diligence process.
Let's talk about your needs and expectations.

Which topics should a Technology DD cover?

The range of topics assessed during a Technology Due Diligence can be both varied and complex, and it largely depends on the ultimate goal of the specific DD. While there are an infinite number of approaches and even specific Tech DD checklists to be found, several topics will most likely be covered by most of them. Here’s a high-level overview of areas and topics that TechMiners will typically look at, accompanied by a non-exhaustive set of selected questions we will seek to answer during an assessment:

  • Infrastructure scaling: “Can infrastructure support a 10x / 100x user base? How much manual work is required?”
  • Team scaling: “Is productivity likely to increase/stall/decrease when adding people or teams?”
  • Scaling cost: “How will infrastructure costs change at scale?”
  • Business continuity & disaster recovery: “How much data could be lost in case of disaster (e.g. datacenter fire), how is redundancy ensured in the system?”
  • Monitoring & alerting: “How quickly and comprehensively is the team informed about infrastructure metrics?”
Tech Team
  • General team structure: “Are teams sized to ensure productivity? Is the structure allowing for ownership and responsibility?”
  • Team autonomy: “Do all teams have the roles required to reach their goal without bottlenecks?”
  • Processes & workflows: “Is there a clear approach to collaboration and do the chosen methodologies match the context?”
  • Meeting culture & efficiency: “How are effective, goal-oriented meetings ensured in practice?”
  • Recruiting, onboarding processes: “How is talent attraction, selection and retention ensured operatively? How do they get up to speed as quickly as possible?”
Tech Stack
  • Tech Stack choices: “Does programming language X provide a suitable ecosystem of frameworks and libraries?”
  • Architecture: “How easily can parts of the software be adapted upon changing requirements?”
  • Security considerations: “Are common security pitfalls avoided and systems / data kept secure?”
  • Technical debt: “Is the team aware of the trade-offs and shortcuts taken? Are they paying off that debt continuously?”
Tech Stack
Legal & IP
  • GDPR compliance: “Are essential roles and processes in place to ensure users can exercise their basic rights?”
  • IP ownership: “Does the company actually own all IP, even when engineers or freelancers move on?”
  • Patent strategy: “Are opportunities for protecting company assets via patents evaluated in a structured fashion?”
  • Open source licenses: “When using OSS libraries and tools, do all developers know about potential implications? Are license checks enforced?”
Legal & IP
Tech Assets
  • Documentation: “Does a structured knowledge base enable swift understanding of core components and reduce dependency on individuals?”
  • Software development life cycle (SDLC): “What is the path from requirements to deployment of new features (and beyond)?”
  • Code quality, test coverage: “Are standards on code quality and automated testing established and enforced automatically?”
Tech Asset
Product Management
  • Product strategy: “How is the roadmap aligned with company vision/mission and influenced by which stakeholders?”
  • Product discovery: “What experiments are conducted to find out what to build (and what not)?”
  • UX capabilities: “Are experts on user experience methodologies involved in the product management process?”
  • Product intelligence: “What metrics and data inform decisions product ideas?”
Product Management

Depending on a variety of factors that affect deals between investors and acquisition/investment targets (e.g. industry specifics, company stage and market dynamics) , additional analyses are necessary beyond the “typical” scope laid out above. The specific hypotheses, questions and analyses to be carried out should closely mirror both due diligence requirements (what do we need to be sure of?) as well as being integrated with the core scope and the overall maturity rating of the business.

As examples for industry specifics, a Tech DD on a company that handles personal data as a core of their product should contain additional deep dives on security and compliance. A fintech company on the other hand, handling payment transactions, has additional, complex requirements when it comes to (technical) transaction security, business continuity, and API scalability, which obviously influences DD scope.

A business' current development stage also has implications for the DD scope. Clearly, an early-stage venture looking to find product/market fit and employing only few people (sometimes just the founders) requires focus on efficiently creating and evaluating experiments to (dis-)prove and move forward quickly, whereas a growth stage venture has likely confirmed one or several markets for their product.  When scaling quickly to secure market share is the central investment goal (and this can also be motivated by market dynamics), a suitable team structure and stable processes, as well as advanced infrastructure automation and quality assurance are key enablers of success.

At TechMiners, we ensure adequate scope early on  during kick-off meetings, preliminary research and involvement of industry experts, generating an understanding of the business we are assessing and its individual challenges and opportunities. Our due diligence framework leverages modular of assessment areas and analyses that can be configured to meet the requirements of the case at hand, from a very basic DD focusing on just key insights on core topics up to a full-fletched confirmatory Tech DD with additional deep dive sessions, and expert involvement guided by our data analyses.

Example Technology Due Diligence Process
Example Technology Due Diligence Process

TechMiners can support your Tech Due Diligence process.
We are happy to provide further references from your industry or sector upon request

Common risks a Technology Due Diligence should cover

Technology companies face different types of specific risks, with impact on business ranging from cost disadvantages and productivity issues to exposure to security incidents. A Tech DD should provide insights into what the specific risks are and how impact can be mitigated. The following (non-exhausting) examples illustrate typical findings and their potential impacts in 2 areas: productivity in development (“can we deliver what’s required to create value, on time?”) and security, as a potential source of incidents disrupting business operations.

Organizational structure and processes inhibiting efficiency in development

Effective yet efficient communication keeps teams aligned and aware without constantly interrupting them with details. Unnecessarily complex collaboration models and organizational structures result in procedural resource waste, which ultimately demotivates and lead to talent churn.

Efficient processes typically rely on goal definitions and road mapping, explicit models of collaboration between the teams and a clear organizational structure that is tailored to the company’s goals. The multitude of different options when it comes to structuring “Product and Development” departments makes finding the sweet spot of optimal team size, collaboration model, and reporting hierarchy anything but trivial.

In very early company stages, when the team is mostly the founders, there is no need for sophisticated structure. However when business picks up, this changes fairly quickly. Experience shows that more than 8 members per team come with significant drawbacks, which would also be the typical limit for direct reports a team lead or manager can handle (this “rule of thumb” limit is higher for a team of very homogenous roles of course).

At scale, this means that some level of distribution (we’re deliberately not saying “hierarchy” here) of staff into groups of contributors is required. Larger organizations often struggle with strong dependencies between teams, regularly blocking each other’s work. Often, this is caused by teams who are assembled around skill sets, not domains, which ultimately leads to significant improvement potential in collaboration efficiency.

Although there is no “one size fits all” model for team structure and collaboration models, a good starting point is usually a specialized team for product management and product discovery, accompanied by autonomous, cross-functional domain teams who can deliver results autonomously.

Regular synchronization between the product management team and a product owner (or equivalent role) implanted inside the domain team ensures alignment with roadmap and product strategy while still enabling focused work within each team.

Limited access to existing knowledge impacts autonomy

As teams grow, knowledge tends to accumulate among the most active, ambitious or experienced engineers, resulting in knowledge silos. If knowledgeable engineers leave the organization at a later stage, progress on building the product will likely slow down, while service stability and availability may be affected as well.

The effect is unfortunately self-reinforcing: poorly distributed knowledge in the heads of a small number of senior tech staff makes it increasingly hard to mitigate that risk itself, as significant dedicated efforts will have to made (instead of a constant, manageable effort built into the processes). Even in early stages of a company, a structured, minimal documentation allows for quick understanding of key concepts, components, and algorithms - but is often neglected in favor of creating a product.

While that may be a valid trade-off, the price normally becomes evident once trying to scale development teams, when documentation needs to be created to get new staff up to speed as quickly as possible. So documentation should not be seen as a pure accountability obligation, but rather as a productivity lever that is used to not block experienced engineering staff too much once growth kicks in.

Later-stage businesses often face the same problem, it just manifests differently: over time, a lot of documentation on various topics is created, sometimes even using multiple different systems (e.g. Wiki systems, email lists, personal notes). In absence of a clearly defined structure that applies for all teams and a constant review of the key pieces being up to date, it becomes virtually impossible to distinguish important pieces of knowledge from “noise”. The effect is ultimately the same: new hires have a hard time figuring out how things work and rely on resident staff to get help, ultimately leading to two (or even more) blocked engineers.

To avoid this knowledge access trap, it is vital to choose a documentation systems and set a clear structure on how to use them. It helps a lot to establish a clear culture of documenting what’s important in the right type of system e.g.

To support the companies we assess, we provide an example structure, containing bare minimum items we consider essential to every tech company’s documentation.

Security vulnerabilities

Security incidents may compromise the confidentiality, integrity, or availability of information assets or systems. The effects of such incidents range from downtime and data loss to exposure of sensitive information or loss of intellectual property. The ultimate  impact will manifest as customer churn, damage to reputation, or even legal action - which all stakeholders would like to avoid of course.

Even in environments that are considered highly secure, some residual risk always remains, as new vulnerabilities and attack vectors are constantly being found. So even though most companies consider security a crucial factor to protect their business, practically every Tech DD uncovers improvement potential.

It pays off quickly to include solutions for dependency management and monitoring to avoid missing an important update to third party libraries, potentially fixing security-relevant bugs. Regular penetration tests by experts to increase resilience of systems deliver great value for the investment, considering that unavailability of high-load components quickly leads to lost revenue that exceeds the cost of regular penetration testing.

Especially larger systems with outdated dependencies may suffer an upgrading deadlock caused by version incompatibilities, leaving the company in a state where it cannot fix publicly known vulnerabilities in time. It is vital to leverage tools for dependency monitoring and regularly set aside time to stay up to date.

A general understanding of common issues when building web based applications must be established in development teams to keep up with the latest threats. Following OWASP and registering for security mailing lists of core components is a very good start.

Data privacy issues, GRPR non-compliance

The General Data Protection Regulation (GDPR) is a regulatory requirement of the EU that mandates certain protections are in place to safeguard personal information. Companies are required to take regular GDPR compliance audits, especially when business grows and customers become larger, as enterprise clients often require suppliers to be GDPR compliant.

Non-compliance can result in monetary penalties and especially in environments with large amounts of data, the effort required to establish compliance at later stages can be enormous. Countries all over the world are creating legislation quite similar to GDPR, increasing the pressure on businesses as regulation lets service users keep ownership of their personal data.

Service providers must disclose what types of data they collect and use, why they do it, and who they share the data with. Any user can request information on the personal data that has been stored about them, service providers must provide that information within a short amount of time. After contracts end and data is no longer required, users can request the deletion of all associated data. The responsibility for being GDPR compliant is assigned to a company’s Data Protection Officer (DPO).

Even though GDPR has come into effect in May 2018, many companies are still behind on implementation and the list of potential fines is growing. Quite regularly, the role of the DPO is either missing entirely or the role assignment leads to a conflict of interest and is considered illegal (e.g. the DPO is also a director).

Ventures at later stages usually have the role assignment covered, yet lack proper ability to provide information on user’s rights in due time or aren’t able to state what type of data needs to be deleted or anonymized upon account termination. Often it is a good starting point to outsource GDPR basics to a specialized service provider.

They will take care of training employees regularly to provide an auditable log, act as a DPO, and have everything available to help businesses focus on their core product. These specialists are also able to identify special requirements (e.g. for ventures that heavily rely on personal data and need to do more than just “basic compliance” work).

When growing further, consider implementing Information Security Management Systems (ISMS), or even get certified (e.g. ISO 27001) to increase trust from clients.

Inefficient structure inhibiting development efficiency

Effective and efficient communications help keep the team aligned and aware without weighing them down in minute details. Is there a structure to getting things done? Is it efficient or overly complex? Unnecessarily complex work models result in procedural deficits that waste capital, demotivate and lead to talent churn.

Output & Deliverable of a Tech DD

Any Tech DD report will summarize findings and provide a clear understanding of the risks and expected impact connected to them. A detailed picture of the existing product, technology and team as well as the company’s capability to move business forward are also typical and an executive summary will allow the reader to understand all major topics within 2-3 minutes.

Example executive summary Technology Due Diligence report
Example Executive summary with short conclusion.

The DD’s findings are preferably ordered by expectable impact on the investment case, touching both areas the experts defined as keys to success in which a venture either outperformed expectations (which may provide opportunities for building competitive advantage) or has clear room for improvement. Each finding should be accompanied by a clear description of why this topic is worth mentioning and what evidence can be provided as a rationale. Next, a clear picture of potential impact is required to help investors and other stakeholders understand the weight of each finding, offering a look into the future in the context of the business objectives and investment thesis. Even a setting that works perfectly well today has a high probability of failing when product usage increases 10x, or when a company wants to significantly increase their development FTEs. Without considering the specific objectives, strategy and roadmaps, any tech assessment will lose a significant part of its value.

As the overall assessment depends on multiple factors, a report should also represent some form of GAP analysis, as expectations vary heavily between cases. A finding in one Tech DD may not be worth mentioning but crucial in the next (e.g. missing ISMS for early stage startup that handles minimal amounts of personal data vs. Series C of a company providing employee benefits, storing data on salaries, social security, etc). TechMiners uses a proprietary maturity model, aiming at an easy-to-understand system for defining expectations for each investment case as well as objective criteria to assess each of our projects with minimal amounts of bias, benchmarking against industry peers wherever possible.

While Tech DD experts may bring sector experience and even benchmarks to support their expectations, they are typically to decide on how to address the identified challenges. Understanding possible impact as well as having received clear and detailed recommendations on how to potentially mitigate these challenges help decision-makers prioritize initiatives and resource allocation, which is why the concluding part of a finding needs to be actionable, specific advice. A professional analyst will provide recommendations from the perspective “If I was the CTO here, what would I do next, how, and in which order?”. Depending on the depth of the DD, these recommendations can range from simple and easy-to-implement tasks like “introduce tool X into CI/CD pipeline to improve delivery speed and confidence” to more complicated initiatives, including re-arranging or introducing entirely new teams. In the best-case scenario, the findings and recommendations are written in a way to be handed over to a company’s CTO without editing and still support his operative work for addressing issues immediately.

Wrapping up a Tech DD includes a report presentation or “read-out”, offering verbal descriptions and summaries of the project to the mandating party. This is the moment to go deep on specific topics, to clarify open questions and to get the analyst’s lateral observations and opinions. It is also quite common to have a second session with the target company’s key stakeholders, explaining in detail the findings are aiming at and how to address it.

Technology Due Diligence finding report with short conclusion.
Example finding summary with short conclusion.

Wrapping up a Tech DD includes a report presentation or “read-out”, offering verbal descriptions and summaries of the project to the mandating party. This is the moment to go deep on specific topics, to clarify open questions and to get the analyst’s lateral observations and opinions. It is also quite common to have a second session with the target company’s key stakeholders, explaining in detail the findings are aiming at and how to address it.

Some Technology Due Diligence providers offer post-transaction technology consulting, leading operative improvement initiatives that address the findings from the DD. While this approach is valid and may provide Investors with efficiency (little handover between transaction work and value creation efforts required), at TechMiners we strongly believe in specializing on the DDs. This is not only for the evident conflict of interest (will the prospect of a “therapy” sale really not influence the “diagnosis”?) but also a deliberate focus of our energy on improving speed, accuracy, and actionability of our Transaction Services to create superior value for all stakeholders involved. Needless to say, our experts are available for questions regarding recommendations or other parts of the report and we regularly offer “CTO sparrings” to former collaborators to provide a second opinion, connect them with the right experts and to discuss approaches, ideas and advice. After all, we love seeing tech companies succeed and build amazing technology, so we are more than happy to contribute to such missions.

Are you planning to invest in a tech company and unsure about how to approach your Technology and Product Due Diligence?
Do you run a venture heading towards a funding round that will likely involve a Tech DD?
Does your business model heavily rely on technology and you want to do a “health check” on how you are doing technologically?
Then don’t hesitate reach out and let’s have a conversation!

TechMiners can support your Tech Due Diligence process.
We are happy to provide further references from your industry or sector upon request

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyse site usage, and assist in our marketing efforts. View our Privacy Policy for more information.