Not every transaction warrants a full technology due diligence. Deal size, timeline, and available budget all shape what is proportionate. But going into a technology acquisition without any structured view of technical risk is a different problem — and one that tends to surface at the worst possible moment.
This self-assessment is for investors, acquirers, and founders who want a structured starting point: something to work through before commissioning a full TDD, to decide whether one is warranted, or simply to know which questions to be asking.
It covers six dimensions. Three questions each. For each question, four possible answers — and a plain-English explanation of what each answer tells you about the risk.
How to Use This Assessment
Work through the questions with whatever information you have available. Where you cannot answer a question — because the information has not been shared, or because the target has not assessed it — treat that as a signal in itself. Undisclosed or unknown answers are often the most telling.
This assessment will not give you a risk rating or a go / no-go recommendation. What it will give you is a clearer picture of where the questions are — and which dimensions warrant closer inspection.
Dimension 1: Architecture & Scalability
How would you describe the platform’s overall architecture? A modular, service-oriented architecture that can scale components independently is the baseline for any platform with growth ambitions. A tightly coupled monolith isn’t automatically disqualifying — but it limits integration flexibility and creates scalability constraints that will cost money to address.
What is known about the platform’s scalability under load? “It handles current load” is not an answer if the investment thesis involves 3× growth. Quantified load testing data — or its absence — tells you whether the team has actually tested its assumptions.
Is there a documented technical roadmap? A team that cannot articulate where the architecture is going is building incrementally without a plan. That compounds technical debt faster than almost any other factor.
Watch for: monolithic architecture with unknown scalability limits — a combination that frequently creates expensive surprises post-close.
Dimension 2: Code Quality & Technical Debt
What is the level of automated test coverage? Low or absent test coverage means every change carries hidden risk. Post-acquisition development velocity will be constrained until coverage improves — and building a retrospective test suite across a mature codebase is expensive.
How is technical debt managed? Ask to see the backlog. The existence, quality, and prioritisation of that artefact tells you more than any verbal answer about how the engineering team approaches technical risk.
Are third-party dependencies current? Outdated or end-of-life dependencies carry known CVEs that may already be publicly documented and actively exploited. Dependency scanning is one of the fastest early-assessment steps available and should be standard practice.
Dimension 3: Security & Compliance
Does the company hold relevant security certifications? SOC 2 Type II, ISO 27001, and their equivalents are not just badges — they are evidence of a structured security programme. In enterprise or regulated-sector sales, absent certifications are often a commercial constraint as much as a risk.
Has the platform undergone independent penetration testing? No certification combined with no penetration testing is a combination that warrants independent security assessment before close — particularly for platforms handling financial, health, or personal data.
How is GDPR / data privacy compliance handled? Privacy non-compliance transfers unconditionally to the acquirer at close. Verify that data processing agreements, retention policies, and subject rights procedures exist as implemented controls, not just as policy documents.
Dimension 4: Engineering Team & Capability
Is there significant key person dependency? Model the scenario in which the founding engineer leaves within 90 days of close. If the answer involves significant disruption, that risk needs to be addressed in deal structuring — through retention packages, earn-outs, or contractual commitments — before signing.
Is the team appropriately staffed for the platform’s complexity? A lean team maintaining a complex platform is a latent risk that often surfaces as burnout-driven attrition in the 12–18 months post-acquisition. Current capacity tells you little about sustainable capacity.
What is the team’s retention risk over 12 months? Engineer retention is a negotiating point, not just a diligence observation. Change-of-control clauses, unvested equity, and competing offers are all addressable pre-close if identified in time.
Dimension 5: IP Ownership & Vendor Risk
Is IP ownership clear and unencumbered? Verify assignment agreements for all founders, employees, and contractors. Open source licence compliance — particularly around GPL and copyleft licences — should also be assessed, especially where AI-generated code is in use, which can carry unclear licence provenance.
What is the level of dependency on third-party platforms? Vendor lock-in is particularly acute in no-code and low-code platforms. Assess not just contractual terms but the practical cost of migration — what would it take to rebuild if the vendor was acquired, changed pricing, or pivoted?
Are there open source licence compliance issues? GPL licence contamination can constrain how acquirers commercialise or distribute the product. A licence inventory should be a standard component of any codebase assessment.
Dimension 6: AI Readiness & Data
How is AI capability delivered in the product? A thin wrapper over a third-party foundation model is not defensible AI capability. If the investment thesis rests on AI differentiation, verify specifically what makes it difficult to replicate — fine-tuning, proprietary data, RAG architecture, or genuine model capability.
Is training data provenance documented and compliant? Undocumented training data is an IP and compliance liability that transfers to the acquirer. Under the EU AI Act, high-risk AI systems require documented data governance — assess the remediation cost if this is absent.
Is the platform compliant with applicable AI regulation? The EU AI Act is enforceable. For platforms classified as high-risk AI systems, the compliance obligations are substantial: ongoing monitoring, human oversight requirements, and conformity documentation. This should be assessed pre-close, not post.
What to Do With the Answers
If you have worked through these questions and found multiple areas where the answer is “unknown / not disclosed”, or where the honest answer sits in the poor or mixed category, you have two options: commission a full technology due diligence to quantify the risk, or factor the uncertainty into the deal structure.
A good TDD does not just surface problems. It quantifies them — translating technical findings into remediation costs, timeline impacts, and deal terms that reflect the true risk profile of what you are acquiring.
At VeryDiligent, we work with PE firms, VCs, and strategic acquirers across all six of these dimensions, with direct access to the codebase, infrastructure, and engineering team. If this assessment has identified areas that warrant closer inspection, we would be glad to discuss what a proportionate engagement looks like for your transaction.
This assessment is indicative only and does not constitute professional advice. It does not replace a full technology due diligence conducted by qualified practitioners with direct access to the target’s systems and team.
Related reading: Red Flags in Startup Codebases: A Technology Due Diligence Guide | Technology Due Diligence vs. Technical Audit: What Buyers Get Wrong | How to Choose the Right Technology Due Diligence Partner