Better call ZDA: Technical Due Diligence for Investors

You wouldn’t buy a building without a structural inspection. Yet every week, VCs and acquiring CEOs close seven-figure software deals based on a pitch deck, a P&L, and a gut feeling about the founding team. That is not investing. That is gambling.

Technical Due Diligence (TDD) exists precisely because software hides things. Not always intentionally. Sometimes a well-meaning CTO built something genuinely clever but never anticipated what happens when ten engineers leave and the only person who understands the authentication layer is now at a competitor. Sometimes “proprietary AI” is three Python scripts and a prompt template duct-taped together. Sometimes the architecture diagram in the data room was drawn six product pivots ago and bears no resemblance to what is actually running in production.

We have seen all of it. More than once.

At Z Digital Agency, our technical due diligence practice operates on a simple premise borrowed from the American real estate market: we are the home inspectors for tech. You call us before you sign. But also after. It is never too late, until…

The blind spot at the center of M&A

Only one in four CEOs report conducting technology due diligence for most of their deals, even though 74% call technology a growth enabler. The gap between those two numbers is where value gets destroyed.

Financial due diligence is non-negotiable. Legal review is standard. But technical review? Still treated as optional by a surprising number of otherwise sophisticated investors. The reasoning tends to be: “our partner has a technical background” or “we’ve spoken extensively with the CTO.” Neither of those is a code audit. Neither catches a critical dependency on an unmaintained open-source library with three known CVEs. Neither tells you that the database has no disaster recovery plan, or that the entire DevOps setup is maintained by one person who is quietly negotiating an exit.

One private equity firm invested in a logistics tech startup without inspecting its software architecture and codebase. Post-acquisition, they discovered severe scalability issues and security flaws that required millions in remediation costs, significantly delaying go-to-market plans and eroding projected returns.

This is not a rare edge case. It is the norm for deals where TDD was skipped.

What technical due diligence actually covers

TDD is not a code review. It is not an IT audit in the traditional sense. It is a structured, multi-phase evaluation of everything technical that underlies a company’s ability to operate, scale, and deliver on its roadmap.

At ZDA, our process covers eight distinct assessment areas, each with its own methodology, tooling, and scoring criteria.

Architecture and infrastructure

The first question is always: what are they actually running, and can it survive what comes next? We map the full system architecture, evaluate the technology stack choices against current standards, assess cloud infrastructure setup across AWS, GCP or Azure, and look specifically at where the system will break under growth. A company claiming it can scale to 100,000 concurrent users needs to prove it with configuration, not confidence.

We look at vendor lock-in risk, data residency compliance for Swiss and EU regulations (GDPR, nDSG), multi-region strategy, and cost structure. A CHF 3,000/month infrastructure bill that becomes CHF 30,000 at 10x users is not a scalable business.

Codebase analysis

This is where the real forensics happen. Using tools like SonarQube, we extract objective metrics: cyclomatic complexity, code duplication rates, test coverage, maintainability index, security hotspot density. Our benchmarks are specific: test coverage below 50% on critical paths is a red flag. Code duplication above 3% signals a team that has been shipping without discipline. A maintainability index below 80 means the next engineer who touches that codebase will spend their first three months deciphering it.

We also examine the Git history. Commit quality tells you more than the team will. Infrequent commits, no branch strategy, missing code review records — these are cultural signals, not just technical ones.

Security assessment

We run every OWASP Top 10 check. Injection vulnerabilities, broken authentication, sensitive data exposure, broken access control. For Swiss and European targets, compliance posture matters: SOC2, ISO 27001, GDPR and nDSG all have technical requirements that either exist in the codebase and infrastructure or they do not. Compliance claims without evidence are common. We verify.

Secrets management is consistently one of the worst areas we find. API keys hardcoded in repositories, database credentials in environment files committed to version control, no certificate rotation policy. These are not theoretical risks. They are the entry points for breaches that happen within six months of an acquisition.

DevOps, CI/CD and disaster recovery

Deployment maturity is one of the clearest indicators of engineering culture. A team that can push to production reliably and frequently, with automated testing gates and rollback capability, is a team that can execute post-acquisition. A team deploying via SSH and a bash script maintained by one person is a liability.

We evaluate RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets against actual backup infrastructure. The number of companies we assess that have no tested disaster recovery plan — not just undocumented, but genuinely untested — is consistent enough that we now consider it the default assumption until proven otherwise.

Performance and scalability

Load testing reveals what architecture diagrams conceal. We establish performance baselines across API response times (p50, p95, p99), run stress tests to identify breaking points, and examine database performance specifically, including slow query logs, connection pool configuration, and indexing strategy. A SaaS platform that performs well at 500 users and degrades catastrophically at 2,000 has an infrastructure story that should materially affect your valuation model.

Team and knowledge concentration risk

The bus factor question: how many people need to be hit by a bus before this company’s technology becomes unmaintainable? We map knowledge concentration systematically. If one engineer holds the institutional memory for the authentication system, the data pipeline, and the deployment process, that engineer is not a senior employee. They are a single point of catastrophic failure.

We assess team structure, skill distribution, development methodology maturity, and the quality of documentation and onboarding material. A codebase that requires tribal knowledge to navigate is a codebase whose value degrades the moment key people leave.

Product and roadmap feasibility

The pitch deck roadmap versus the technical reality is often the most revealing comparison we make. We evaluate planned features against the current architecture, estimate effort honestly, and identify where the roadmap is technically feasible in the stated timeline and where it is not. We also verify IP ownership: who actually owns the code, what open-source licenses are in play, and whether any GPL-licensed components create downstream exposure.

Risk scoring and remediation planning

Every finding feeds into a risk matrix scored by severity and probability. The output is not a list of issues. It is a prioritized remediation roadmap with effort estimates, organized into 90-day critical actions, six-month improvements, and twelve-month architecture optimizations. This gives you a direct input for valuation negotiation and post-acquisition planning.

What we actually found: a real TDD engagement

In 2021, ZDA conducted a technical due diligence assessment on a Swiss professional services SaaS platform ahead of a significant investment decision. The platform handled sensitive HR and consulting workflows, operated across multiple enterprise clients, and had been developed by a small but experienced engineering team over several years.

The summary was clear: the codebase was solid in structure and showed genuine engineering competence, but it carried meaningful technical debt and several operational risks that needed addressing before or immediately after any deal closed.

Specifically, we found that the login page alone was loading over 7MB of JavaScript — a combination of a 2.8MB PDF rendering library, a 2.5MB application bundle, and a 2.2MB vendor chunk. For enterprise users on corporate networks, this was creating significant latency. Not a fatal flaw. But not a “we’ll fix it later” issue either, because “later” in post-acquisition integration timelines means twelve to eighteen months.

The platform’s Node.js and Vue.js stack was sound in principle, but almost every dependency in the package.json was one to two years out of date. The Sequelize ORM was throwing deprecation warnings on string-based operators — a known security concern the library had already addressed in newer versions. The Docker setup was running two processes in a single container, which violates container hygiene and creates unpredictability in production environments.

We also flagged that developer documentation was insufficient for onboarding. A new engineer joining the team would have needed weeks of tribal knowledge transfer to become productive. In a world where integration requires adding engineers, that is a hidden cost most buyers do not quantify.

The recommendations: upgrade Vue 2 to Vue 3 before the codebase became genuinely legacy, implement code splitting to address the JavaScript bundle problem, establish a CI/CD pipeline to replace the existing manual deployment approach, and migrate from Forever JS to pm2 as the process manager. None of these were insurmountable. All of them were quantifiable. That is exactly what a TDD engagement is supposed to produce.

The investment decision proceeded — with a clearer picture of what would need to happen in the first ninety days, and a negotiating position grounded in actual data.

The tools behind a professional TDD

Our technical stack for due diligence is not a checklist of buzzword tools. It is a deliberate combination of automated scanning and expert interpretation.

SonarQube handles code quality metrics and complexity analysis. OWASP ZAP scans for application-level security vulnerabilities. Snyk and Dependabot examine dependency trees for known CVEs. For infrastructure, we use cloud console access directly, combined with Nessus for network-level vulnerability scanning. Performance baselines come from k6 for load testing and Google Lighthouse for frontend performance. BuiltWith and Wappalyzer help identify the actual technology stack from the outside, which often differs from what the team documents internally.

The automation layer matters as well. Our n8n workflows handle the intake, scan orchestration, and preliminary findings aggregation, which allows our senior engineers to spend their time on interpretation and judgment rather than data gathering. This is the only way to run a rigorous TDD process at the pace deals actually require.

For companies with AI-native products or those claiming significant AI capabilities, we conduct an additional evaluation layer. As artificial intelligence and machine learning become increasingly relevant, assessing a company’s foundation for AI is a critical component of technology evaluation. We regularly encounter companies where “AI-powered” in the pitch deck translates to a third-party API call with a prompt template around it. That is not a competitive moat. Our team’s deep experience with enterprise AI architectures, including recursive AI orchestration patterns we have implemented for Swiss enterprises handling large-scale AI workflows, allows us to evaluate these claims with the precision they require.

The 2026 dimension: AI infrastructure as acquisition risk

The TDD landscape has evolved. In 2025 and into 2026, the single most common overstatement we encounter in tech company pitches is around AI capability. Understanding what Swiss and European SMEs are actually doing with AI versus what they claim to be doing has become a critical competency for any investor in this market.

Our assessment of AI adoption and implementation across Swiss companies shows a consistent pattern: the gap between stated AI capability and actual AI infrastructure maturity is significant. A company that has integrated OpenAI APIs into a product is different from a company that has built proprietary training pipelines, fine-tuned models on domain-specific data, and developed defensible IP. A TDD engagement that cannot distinguish between those two situations is not protecting your investment.

We evaluate AI infrastructure for scalability, data quality, model governance, cost-per-inference trajectory, compliance with Swiss data residency requirements, and the technical depth of the team actually building it. In a market where “AI company” can mean anything from a genuine ML engineering team to a sophisticated API wrapper, this distinction matters.

What the deliverable looks like

A ZDA technical due diligence report is not a document you read on the flight home and file. It is an operational instrument.

The executive summary runs two to three pages: overall risk score on a 1-25 scale, top three critical findings, top three recommendations, and an estimated remediation investment. Clear enough to take to a board. Specific enough to negotiate with.

The full report covers all eight phases with findings ranked by severity, supporting evidence from our tool outputs, risk implications, and remediation steps. The risk matrix is visual, severity-weighted, and tied directly to a phased action plan organized as 90-day, six-month, and twelve-month priorities.

We include architecture diagrams of the actual current state, not the idealized version from the data room. We include SonarQube exports, security findings with CVE references, and team assessments with honest bus factor analysis.

The process typically runs two to three weeks for a standard SaaS acquisition. Accelerated timelines are possible. Skipped phases are not.

You need this. But you cannot do it alone.

Financial modeling you can hire for. Legal review you have counsel for. Technical due diligence requires something different: engineers who have actually built the things they are evaluating, who understand both the technical reality and the business implications, and who will give you a written, defensible assessment under time pressure.

Our team at ZDA is composed exclusively of former entrepreneurs and senior practitioners. Nobody here has only read about codebase architecture in a textbook. The same team that evaluates your target’s CI/CD pipeline has built and managed CI/CD pipelines. The same engineers who assess your target’s CRM and tooling stack have evaluated, implemented and integrated enterprise tech stacks across dozens of Swiss SME mandates.

That is not a credential. That is a methodology.

Companies that conduct comprehensive technology due diligence are 28% more likely to achieve their projected synergies and 32% more likely to retain key technical talent post-acquisition. We would add one more data point from our own experience: the clients who have called us before signing have never come back to us with a post-acquisition technical crisis. The ones who called us after, frequently have.

The conversation is free. The consequences of skipping it are not.

Better call ZDA.

Z Digital Agency provides technical due diligence for investors, VCs and acquiring CEOs across Switzerland, France and Germany. Our assessments cover architecture, code quality, security, infrastructure, performance, team risk, product feasibility and AI capability. Contact us to discuss your upcoming transaction.