Technical Due Diligence
Technical due diligence you can put in front of the investment committee
An independent assessment of a target’s technology - architecture, code, data, security and team - performed by senior CTOs and architects and delivered as a decision-ready report before you sign.
For private equity, venture and growth investors, and corporate acquirers assessing technology risk before a deal.
- Senior-led
- Architecture-first
- Investment-committee ready
Powered by Comtau Inc.
Risk rating
Sample format
- Deal-breakerUndermines the thesis. Walk away or restructure.
- Price / termsReal cost to fix. Reflect it in price, SPA terms or conditions.
- 100-day fixManageable. Budget it into the post-close plan.
- NoteRoutine engineering work. No deal impact.
- Deliverable
- Committee-ready report with a risk rating
- Performed by
- Senior CTO and architect practitioners
- Confidentiality
- Scoped under NDA before access is granted
What technical due diligence is
Technical due diligence is an independent assessment of a target company’s technology - its architecture, codebase, data, security posture, team and roadmap - commissioned before an investment or acquisition to surface risk that financial and commercial due diligence do not cover.
It complements, rather than replaces, financial and commercial due diligence: those workstreams validate the numbers and the market; this one validates whether the technology can actually support what the deal assumes.
It is forward-looking. The question is not only “is this well built”, but “can it scale to the plan, integrate with what you already own, and survive the people who built it leaving”.
Who it is for
Built for each side of a deal
Private Equity
A platform or add-on acquisition where the thesis depends on scaling the technology or integrating it with a portfolio.
Diligence focus
Scalability against the value-creation plan, carve-out dependencies, and integration cost.
A risk-adjusted view of the technology before the deal is priced.
Venture & Growth
A pre-investment company whose architecture and team have not been stress-tested at scale.
Diligence focus
Architecture runway, founder and team depth, and the technical decisions the round will need to fund.
A clear view of what the round needs to fund on the technology side.
Corporate M&A
An acquisition that must integrate with existing systems, teams and standards.
Diligence focus
Integration fit, technology overlap, and key-person or knowledge risk.
An integration-ready risk picture, not a stand-alone assessment.
Sell-side readiness
A company preparing for a raise or exit that wants to know what a buyer’s diligence will find first.
Diligence focus
The same nine assessment areas, run before the buyer’s, so issues are fixed or explained ahead of time.
Fewer surprises - and a stronger negotiating position - once diligence starts.
What we assess
Nine areas, three groups: product & architecture, operations & risk, organisation & plan
Every assessment covers the same ground, adjusted for the deal. Each area has a defined goal and a set of concrete checks - verified hands-on in the code, the cloud account and the interviews, not a generic questionnaire.
Product & architecture
3 areas · 13 checks
01Architecture & scalabilityWhether the system can support the plan behind the dealArchitecture-first focus
- Component boundaries and coupling
- Scaling limits against the growth case
- Single points of failure and failover
- Multi-tenancy and data isolation
- Build-vs-rewrite exposure over the hold period
02Code quality & technical debtThe condition of the codebase relative to what it needs to do next
- Code structure and hotspots in core modules
- Automated test coverage on critical paths
- Dependency age and upgrade backlog
- Size and cost of the technical debt register
03Data architectureHow data is structured, owned and governedArchitecture-first focus
- Data model and schema health
- Data ownership and lineage
- Backup, restore and retention
- Data quality in the systems the thesis depends on
Operations & risk
4 areas · 16 checks
04Infrastructure & DevOpsHow the system is built, deployed and operated
- Hosting setup and cloud cost profile
- CI/CD pipeline and release frequency
- Monitoring, alerting and on-call
- Incident history and recovery practice
05Security & complianceExposure to security and regulatory risk
- Authentication, authorisation and secrets handling
- Vulnerability and patch management
- Personal-data handling against applicable regulation
- Customer security commitments already signed
06IP & open-source licensingWhether the technology is actually owned and safe to use
- Open-source licence inventory
- Copyleft exposure in distributed code
- Contractor and agency IP assignment
- Third-party and vendor lock-in dependencies
07AI systems & model riskWhether AI claims hold up under technical scrutinyArchitecture-first focus
- What is a production model versus a wrapper or prototype
- Model and data-provider dependencies
- Evaluation of output quality
- Training-data rights and inference cost
Organisation & plan
2 areas · 8 checks
08Team & key-person riskWhether the team can execute without the people who built it
- Team structure, seniority and gaps
- Knowledge concentrated in one or two people
- Retention exposure through the deal
- Reliance on contractors or agencies
09Delivery process & roadmap feasibilityWhether the roadmap behind the investment thesis is realistic
- SDLC and planning practice
- Delivery against past roadmap commitments
- Roadmap capacity versus the current team
- Technology investment the thesis assumes
Process
From NDA to read-out
The process runs on the deal’s clock, not the other way round. Scope and access set the pace - a limited-access red-flag review moves faster than a full diligence with data-room access.
- 01
Scope & NDA
Agree the scope, sign confidentiality terms and confirm what access is available.
Inputs
- Deal thesis and timeline
- NDA
- Initial document request
Owner
- Investor
- Comtau
OutputConfirmed scope and access plan
- Red-flag review
- Full technical due diligence
- 02
Data room
Review the target’s own documentation before any conversation.
Inputs
- Data-room documents
- Repository and cloud read access, where agreed
Owner
- Target
- Comtau
OutputQuestion list for interviews
- Red-flag review
- Full technical due diligence
- 03
Interviews
Talk to the people who built and run the system.
Inputs
- Interview slots with technical leadership
- Architecture and code walkthroughs
Owner
- Target
- Comtau
OutputAssessment working notes
- Not in Red-flag review
- Full technical due diligence
- 04
Analysis
Assess findings against the nine areas and the investment thesis.
Inputs
- Risk and severity rating
- Remediation cost and effort estimate
Owner
- Comtau
OutputDraft findings and risk register
- Red-flag review
- Full technical due diligence
- 05
Report
Write a committee-ready report that separates deal risk from routine work.
Inputs
- Executive summary and risk rating
- Deal implications
Owner
- Comtau
OutputInvestment-committee report
- Red-flag review
- Full technical due diligence
- 06
Read-out
Walk through the findings with the deal team.
Inputs
- Read-out session
- Q&A with the deal team
Owner
- Investor
- Comtau
OutputDecision-ready view before signing
- Not in Red-flag review
- Full technical due diligence
Which phases each tier runs
- Red-flag review
- Limited access: public information, limited documentation and a short set of interviews.
- Full technical due diligence
- Data-room access, interviews and code walkthroughs, ending in a read-out.
Access limited, or pre-LOI? The red-flag review runs outside-in on what is available and says clearly which conclusions still need verification.
Engagement options
Scoped to the deal, not a fixed package
The right scope depends on deal stage and how much access you have.
limited access
Red-Flag Review
- When
- Before a term sheet or LOI
- Access
- Public information, limited documentation, a short set of interviews
- Output
- A fast read on deal-breaking risk
standard
Full Technical Due Diligence
- When
- After LOI, before close
- Access
- Data room, interviews, code and architecture walkthroughs
- Output
- The complete nine-area assessment and a committee-ready report
post-close
Post-Deal 100-Day Plan
- When
- After close
- Access
- Full access as the new owner
- Output
- A prioritised remediation and stabilisation plan, with optional hands-on leadership
Have a deal on a clock?
Tell us the target and the timeline. We’ll tell you plainly what scope fits before you sign anything.
Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.
Red flags and how we rate them
What actually threatens the investment thesis
Not every finding is a red flag. Each one is rated by what it means for the deal - the same issue can be a deal-breaker in one target and a 100-day fix in another.
- Deal-breakerUndermines the thesis. Walk away or restructure.
- Price / termsReal cost to fix. Reflect it in price, SPA terms or conditions.
- 100-day fixManageable. Budget it into the post-close plan.
- NoteRoutine engineering work. No deal impact.
Architecture that cannot scale to plan
The growth case assumes throughput or reliability the current system was never designed for.
- Deal-breaker
- Core platform needs a rewrite to reach the plan
- Price / terms
- Re-architecture needed within the hold period
- 100-day fix
- Single-region database with no tested failover
- Note
- Isolated legacy module off the growth path
How we assess it: Assessed directly against the investment thesis, not against generic best practice.
Hidden or unquantified technical debt
Debt that has never been measured is treated as if it does not exist - until it blocks the roadmap.
- Deal-breaker
- Debt blocks the roadmap the thesis depends on
- Price / terms
- Remediation cost material to the valuation
- 100-day fix
- Low test coverage on critical paths
- Note
- Moderate debt in a reporting module
How we assess it: Measured and costed as part of the assessment, not left as a narrative claim.
Key-person dependency
Critical knowledge lives in one or two people who are not covered by the deal.
- Deal-breaker
- Sole builder of the core system leaving at close
- Price / terms
- Retention packages needed for named engineers
- 100-day fix
- Undocumented knowledge of one subsystem
- Note
- Thin documentation in a stable area
How we assess it: Named explicitly, with a knowledge-transfer plan proposed for the first 100 days.
Security or compliance gaps
Gaps that surface after close cost far more than they would before signing.
- Deal-breaker
- Regulated data handled in breach of obligations
- Price / terms
- Customer security commitments not met
- 100-day fix
- Secrets and access control need an overhaul
- Note
- Patch backlog on non-critical services
How we assess it: Checked against the target’s actual regulatory and customer obligations, not a generic checklist.
Unclear IP or licence exposure
Open-source or contractor-built code without clear ownership can block a deal or a future raise.
- Deal-breaker
- Core product not owned by the target
- Price / terms
- Copyleft code in the distributed product
- 100-day fix
- Missing IP assignment from former contractors
- Note
- Licence inventory incomplete
How we assess it: IP and licence position confirmed as part of the standard scope.
AI claims that do not hold up
“AI-powered” can mean anything from a production model to a prompt wrapper.
- Deal-breaker
- Core AI capability does not exist as claimed
- Price / terms
- Differentiation depends on one model provider
- 100-day fix
- No evaluation of model output quality
- Note
- Inference cost not yet monitored
How we assess it: AI components are assessed for what they actually are and what they depend on.
What the committee receives
A report built for a decision, not a shelf
Findings are rated by severity and tied to the deal, not delivered as an undifferentiated list. Material deal risk is always separated from routine engineering improvements.
- 01Executive summaryThe answer to “does the technology support the thesis?”
- 02Risk register with ratingEvery finding rated deal-breaker, price / terms, 100-day fix or note.
- 03Findings by assessment areaAll nine areas, with the evidence behind each.
- 04Remediation estimatesCost and effort to fix what matters, not a list of complaints.
- 05Deal implicationsWhat the findings mean for price, SPA terms, conditions and the post-close plan.
- 06100-day plan outlineThe first remediation steps after close.
- 07Read-out sessionA walkthrough and Q&A with the deal team.
Technical Due Diligence Report
Illustrative example · not client material
Investment committee findings - platform acquisition
Draft for read-out- Audience
- Investment committee
- Confidentiality
- NDA-covered
- Scope
- Full technical due diligence
Executive summary
The core platform can support the growth case for the near term without re-architecture. Two findings are material to the thesis; the rest are routine engineering work.
Material risk
- materialSingle-region database with no tested failover - a scaling and reliability risk if the growth case is met.
- materialTwo senior engineers hold undocumented knowledge of the billing system.
Routine findings
- routineModerate technical debt in the reporting module - manageable within normal roadmap capacity.
- routineTest coverage below target in one service - flagged, not blocking.
Deal implications
Recommend a remediation budget line for the database failover work and a knowledge-transfer plan for the billing system, both foldable into the 100-day plan.
After the deal
The first 100 days
Diligence is only useful if the findings turn into action. The same team that ran the assessment can lead the plan that follows.
From data room to a post-close plan, without losing the evidence
Every conclusion in the report can be traced back to what was examined, and the recommendations are written so they can become the post-close roadmap directly.
Evidence collection
Gather documentation, code and data-room material, and interview the engineering team.
Output
- Gate
- Access gaps recorded, not guessed around
- Why it lowers risk
- Gaps in access show up as named limits in the report.
Output becomes the input to Technical assessment
Technical assessment
Assess the nine areas against what the deal needs the technology to do.
Output
- Why it lowers risk
- Every rating points back to the evidence behind it.
Output becomes the input to Risks
Risks
Classify red flags by type and severity, with the cost and effort to fix each.
Output
- Gate
- Walked through at the read-out
- Why it lowers risk
- The committee sees deal-relevant risk, not a list of code smells.
Output becomes the input to Recommendations
Recommendations
Say what to do about each material risk: price it, condition it, or fix it after close.
Output
- Gate
- Each tied to a severity rating
- Why it lowers risk
- Findings turn into deal terms or a plan, not an appendix.
Output becomes the input to Post-deal execution roadmap
Post-deal execution roadmap
Post-close, agreed separately
Break the fix-after-close items into scoped work for the first 100 days, ready for controlled execution.
Output
- Gate
- Order and scope agreed
- Why it lowers risk
- Integration starts from the diligence evidence instead of a fresh discovery.
01
Stabilise
Address anything time-sensitive the assessment flagged - access, on-call coverage, immediate risk.
02
Secure & document
Close security gaps and put the missing documentation and knowledge transfer in place.
03
Re-architect where needed
Sequence the structural work the findings called for into the post-close roadmap.
04
Organise the team
Fill the leadership and key-person gaps the assessment named, so the plan has owners.
Independence. The assessment stands on its own. Execution is optional and agreed separately, so findings are never shaped to create follow-on work.
Remediation work can be sequenced through technical debt assessment & remediation . A deeper software architecture review can come first.Post-close leadership can continue through an Interim CTO or Fractional CTO engagement.
FAQ
Technical due diligence questions
What is technical due diligence?
An independent assessment of a target company’s technology - architecture, code, data, security and team - commissioned before an investment or acquisition to confirm the technology can support the deal.
How does PE, VC and corporate M&A diligence differ?
The nine assessment areas stay the same; the emphasis shifts. Private equity weighs scalability against a value-creation plan and carve-out risk. Venture and growth diligence looks harder at team and architecture runway. Corporate M&A weighs integration fit and overlap with existing systems.
What access do you need from the target?
It depends on the engagement. A red-flag review can run on public information and limited documentation. A full technical due diligence needs data-room access and time with the engineering team. We scope access to the deal stage and confidentiality constraints, not the other way round.
How long does it take?
It depends on the tier and on how quickly access is granted. A red-flag review is shorter than a full technical due diligence. We agree the read-out date against your deal timeline before work starts.
What if access to the target is limited?
Pre-LOI or in a competitive process, access is often limited. The red-flag review runs outside-in on what is available and states clearly which conclusions still need verification in a full diligence.
Do you review source code?
Yes, where access allows it. Code review sits inside the code quality and technical debt area of the assessment, alongside architecture and delivery process review.
How is confidentiality handled?
Findings are shared under the terms agreed with you before the engagement starts, including any NDA covering the target and any restrictions on sharing with co-investors or lenders.
What is the difference between a technical due diligence and an architecture review?
Technical due diligence is commissioned by an investor or acquirer ahead of a deal and covers the target’s technology as a whole, including team and delivery risk. An architecture review is commissioned by a company on its own system and goes deeper on architecture alone. See Software Architecture Review & Assessment.
Do you support remediation after closing?
Yes. Findings can turn into a prioritised remediation plan (see Technical Debt Assessment & Remediation) or ongoing technical leadership through the transition (see Interim CTO or Fractional CTO).
Scope your deal
Tell us about the target and where you are in the process. We’ll propose the scope that fits - red-flag review, full diligence, or a post-deal plan.
Direct conversation with a senior CTO/architect. We’ll review your situation and determine the useful next step.
What happens next
- 01You describe the target, the deal stage and the timeline
- 02We propose the scope and confirm access needed
- 03We agree the read-out date before work starts
Talk to a senior CTO/architect
Book a call