Ten questions to ask during Tech Due Diligence

1. How do you balance architectural trade-offs between scalability and maintainability?

This question strikes at the heart of system design. It acknowledges that every technical decision involves trade-offs and invites the CTO to explain the rationale behind their architecture. For example, microservices architectures are excellent for scalability but can introduce significant complexity in terms of orchestration and debugging. Conversely, monolithic architectures are simpler to maintain in early stages but may falter under scaling pressures.

Follow-ups like “What monitoring systems are in place to identify scaling bottlenecks?” or “How do you manage service dependencies to avoid cascading failures?” show a nuanced understanding of the challenges inherent in modern system design.

2. What’s the most complex bug your team has fixed in the past six months, and what did it teach you about your codebase?

This question serves two purposes: it tests how intimately the CTO understands their team’s recent challenges, and it reveals potential weaknesses or blind spots in the codebase. Complex bugs often surface hidden issues, like technical debt, architectural limitations, or gaps in testing coverage.

By framing the question this way, you also uncover whether the team has effective debugging processes and a culture of learning from incidents. If the CTO mentions they’ve implemented root cause analysis processes or improved automated tests in response to the bug, it’s a sign of a mature development environment.

3. How do you track and manage open-source dependencies to minimize risks?

This question immediately signals a deep understanding of one of the biggest risks in software development: open-source software (OSS) management. OSS is foundational in most modern software stacks, but mismanaging dependencies can introduce vulnerabilities or licensing risks.

Savvy investors might follow up with, “Do you use tools like Dependabot or Snyk to automate vulnerability monitoring?” or “What’s your policy for introducing libraries with restrictive licenses like AGPL or GPL?” These questions demonstrate knowledge of the practical tools and legal implications that come with OSS.

4. What metrics do you use to measure developer productivity and code health?

This question dives into the team’s operational efficiency and their ability to measure meaningful outcomes. Traditional metrics like lines of code written are outdated and misleading. Instead, a sophisticated CTO might point to metrics such as lead time for changes, deployment frequency, or mean time to recovery (MTTR) after incidents.

A follow-up like “How do these metrics inform your sprint planning or technical debt management?” can lead to a discussion of how the team balances feature development with maintaining and improving the codebase. This approach showcases your understanding of both technical and operational priorities.

5. How do you handle rollbacks in production, and when was the last time you needed one?

Production failures happen—even to the best teams. What matters is how they respond. This question uncovers how prepared the team is to handle the unexpected, a critical factor in assessing operational resilience. The CTO’s response might touch on strategies like blue-green deployments, canary releases, or feature toggles, all of which are best practices for mitigating production risks.

A savvy follow-up could be, “What’s your rollback decision-making process, and how do you balance risk versus time-to-fix?” This demonstrates an understanding of the operational challenges in production environments and highlights the importance of minimizing downtime while maintaining user trust.

6. How do you ensure resilience and fault tolerance in critical systems?

This question directly addresses how the system is designed to handle failures and maintain availability, which is crucial for user-facing applications. A CTO might explain strategies such as redundancy, failover mechanisms, or circuit breakers in microservices to prevent cascading failures.

Follow-up: “How do you simulate failures to validate these mechanisms—do you use tools like Chaos Monkey or other chaos engineering practices?” This demonstrates familiarity with cutting-edge approaches to testing system resilience.

7. What are your biggest bottlenecks in the development lifecycle right now?

Every development team faces challenges, and this question encourages the CTO to reflect on operational constraints, whether they’re related to hiring, tooling, communication, or technical debt. Their response reveals not only existing pain points but also their ability to identify and address inefficiencies.

Follow-up: “How are you prioritizing improvements to address these bottlenecks, and what outcomes are you targeting?” This keeps the focus on solutions, not just problems, and shows you understand the interplay between process improvements and business outcomes.

8. How does your team approach technical debt during planning?

This question gets to the heart of whether the team has a disciplined approach to balancing new features with maintaining long-term health of the codebase. It also highlights their ability to quantify and prioritize debt—something that can directly affect future scalability and adaptability.

Follow-up: “How do you quantify technical debt, and do you use metrics like code churn or refactor costs to guide prioritization?” This demonstrates you’re aware that technical debt isn’t just a concept but a measurable, actionable reality.

9. What’s your approach to handling data growth and scalability at the storage layer?

This question dives into the strategy for handling increased data volumes as the product scales. The CTO might discuss approaches like sharding, indexing, database clustering, or the use of scalable storage solutions like Amazon RDS, DynamoDB, or Snowflake.

Follow-up: “How do you handle schema evolution or versioning in your database, especially as the product scales and requirements change?” This question drills into a practical challenge many teams face and shows a deeper understanding of data architecture.

10. How do you prioritize and balance security against development velocity?

Security can sometimes slow down development cycles, but neglecting it risks breaches and compliance failures. This question invites the CTO to discuss how they integrate security into the development process without compromising speed. They might describe practices like DevSecOps or the use of automated security tools in CI/CD pipelines.

Follow-up: “What’s your approach to detecting and patching zero-day vulnerabilities in your dependencies, and how quickly can you respond to them?” This not only signals expertise but also raises a critical issue many organizations face.

Why these questions work

These questions go beyond surface-level curiosity and delve into the complexities of software engineering, operational management, and risk mitigation. They show that the person asking understands the trade-offs, challenges, and tools that shape a modern software company. As Jonathan Berdah, Tech Due Diligence expert at Vaultinum explains, "The goal isn't to do finger pointing at areas that aren't yet state-of-the-art. While not every question may apply to every situation, engaging in these types of discussions provides a well-rounded view of the company's maturity and helps the CTO identify the pillars that need strengthening." These questions also positions you as a knowledgeable and credible stakeholder—one who truly understands the intricacies of building and scaling great technology.

Disclaimer

The opinions, presentations, figures and estimates set forth on the website including in the blog are for informational purposes only and should not be construed as legal advice. For legal advice you should contact a legal professional in your jurisdiction.

The use of any content on this website, including in this blog, for any commercial purposes, including resale, is prohibited, unless permission is first obtained from Vaultinum. Request for permission should state the purpose and the extent of the reproduction. For non-commercial purposes, all material in this publication may be freely quoted or reprinted, but acknowledgement is required, together with a link to this website.