Independent, read-only review for investors and acquirers. Each material finding links evidence to the investment thesis, deal exposure, and the action required.
A software target can pass a demo and still miss the deal thesis. Technical due diligence tests whether the deployed system, delivery team, operating controls, and cost base can support the buyer's growth and integration plan.
The work begins with the investment thesis and the decisions still open. Those questions determine the evidence request. A product-led SaaS acquisition, a minority growth investment, and a regulated carve-out do not need the same review.
Interviews explain how the company believes its system works. Repositories, infrastructure, records, contracts, logs, invoices, and operating evidence show what can be verified.
Missing access remains a limitation. It is never converted into a green score. The decision memo separates verified facts, management statements, reviewer inference, and open evidence so the investment committee can judge confidence.
We have no economic interest in a recommended vendor or later remediation. Any implementation work after the transaction is separately scoped and approved.
Use this engagement when software, data, infrastructure, or the engineering team is material to value, integration, growth, resilience, or exit.
Legal, financial, commercial, privacy, and offensive-security specialists remain responsible for their workstreams. Technical diligence can coordinate those findings while leaving each conclusion with the qualified owner.
Can the current architecture, product boundaries, and delivery model support the growth, market, and integration assumptions in the deal?
Which security, resilience, privacy, access, recovery, or incident exposures could affect customers, operations, insurance, or contractual commitments?
Where do code ownership, review practice, release controls, documentation, on-call coverage, and key-person concentration constrain the plan?
Which cloud, licence, data, migration, re-platforming, and remediation costs belong in the value-creation plan or purchase assumptions?
Who owns the code, data, accounts, domains, models, licences, and critical vendor relationships, and what happens if a supplier or key person leaves?
The output is designed for an investment decision and the first operating plan after it. Detailed evidence remains traceable behind the executive view.
Each finding records the deal assumption tested, evidence inspected, result, confidence, exposure, action, and any limitation. The review asks for the smallest access needed to reach a defensible conclusion.
A short scope call should narrow the review before anyone opens a data room. These answers control depth, specialists, timing, and evidence.
The scope follows the investment thesis. It commonly tests product and architecture fit, security and resilience, engineering delivery, operating economics, data and vendor dependencies, ownership, and integration exposure. A software acquisition and a technology-enabled services company require different evidence.
The schedule is set after the transaction stage, target shape, open decisions, access, specialist needs, and investment-committee deadline are known. The scope note states what can be verified in that window and what will remain a limitation. We do not promise a universal duration before those facts are available.
A technical audit is typically commissioned by the company itself for internal improvement. Technical due diligence is conducted by or for an investor or acquirer to assess commercial and technical risk before a transaction closes.
Yes. Founder-side work should be identified as pre-DD or readiness work so the later investor review remains independent. Start with the technical due diligence evidence checklist to identify missing records and ownership before deciding whether an external review is needed.
We use standards to structure questions; they do not substitute for transaction evidence or certification. NIST SP 800-218 informs secure-development evidence, CISA SBOM resources inform software-component transparency, and OWASP SAMM informs lifecycle practice. For an in-scope financial entity, DORA may add ICT third-party questions. Legal counsel determines applicability and legal conclusions.
Technical DD is one engagement type within our Tech Strategy & Consulting service line. Related engagements include standalone tech audits, vendor due diligence, and build vs buy memos.
Start with the free technical due diligence evidence checklist to track requests, gaps, confidence, and deal-thesis exposure. If you are an investor evaluating a target, see investor and portfolio teams. If you are a founder preparing for a raise, see startup and scale-up work.
Read the fractional CTO guide for technical advisory in a fundraising context. If AI systems are part of the risk profile, see Some Tech Work in AI.
Tell us what needs fixing
We read every brief and reply within one business day.
Prefer to talk first?or request a tech stack audit →or email us directly →
Not sure where to start? Send the stuck decision, workflow, or page. We will say whether you need a diagnostic call, a tech stack audit, or a different first step.