Technical Due Diligence

Technical due diligence that tells you what you are actually buying.

Before you invest, acquire or sign off on a platform, know what sits behind the demo. We review the agreed code, architecture, security posture and delivery process, then hand over a written report that ranks the risks and explains what fixing them involves.

Scope a technical due diligence →

DIRECT ANSWER

Technical due diligence is an independent review of the software behind a company or product before an investment, acquisition or board decision. It ends in a written risk report with severity, evidence and remediation options, not in legal or financial advice.

Best for

  • Investors, acquirers and boards who need an outside view of a software asset before a decision
  • Founders who want their own platform reviewed before investors ask the questions

Consider another approach

  • Legal, tax or financial due diligence, or a statement on valuation
  • Taking over and running the code after a provider change

Start with the decision the report has to support

An investor before a round, an acquirer before signing and a board reviewing its own platform need different depth. We agree the decision, the systems and repositories in scope, the access available and the recipient of the report before work starts. Commercial, legal, tax and financial diligence stay with your counsel and advisers. Where a technical finding touches their work, such as unclear code ownership or open-source licence obligations, the report flags it for them instead of drawing a legal conclusion.

What the review covers

Coverage follows the agreed scope. Each area records what we inspected, what we could not access and how confident the conclusion is.

Code and architecture

Structure, test coverage and quality, documentation, key-person dependencies and how hard the system is to change.

Security posture

Access to code and infrastructure, secret handling, dependency vulnerabilities and obvious exposure. This is a review, not a penetration test.

Delivery process and team

How changes reach production, release and rollback practice, incident history and who holds the knowledge.

Scalability, operations and cost

Hosting setup, monitoring, recovery readiness and the infrastructure and third-party costs behind the product.

AI-specific evidence

For AI products, evaluation design, model and prompt records, provider concentration, failure handling and task-level cost. Our [AI MVP due diligence checklist](/blog/technical-due-diligence-ai-mvp/) lists the evidence we look for.

Dependencies and tech debt

Outdated frameworks, unsupported components and the debt that will slow the roadmap, with a rough sense of what each item costs to address.

A report that ranks risk instead of listing everything

Every finding has a severity, the evidence behind it, its likely impact on the business case and the realistic options to fix it. Where you ask for remediation effort, we give ranges, clearly marked as estimates under assumptions agreed for the engagement, not as quotes. The report separates deal-relevant risks from normal engineering housekeeping and lists the questions management still needs to answer. It does not predict valuation, deal terms or the outcome of a transaction.

How a due diligence runs

Scope, timeline and fixed price are agreed in a signed statement of work before work starts. Timelines depend on the size of the system and how quickly access and interviews are available.

  1. Scoping and access

    Agree the decision, systems, recipients and confidentiality. Receive read access to repositories, the data room and relevant documentation.

  2. Review and interviews

    Inspect the code and infrastructure, and talk to the people who build and run the system. Open questions go to management in writing.

  3. Report and readout

    Receive the written report and walk through it with your team. Factual corrections from the company under review are handled as agreed up front.

After the report, choose the right next step

Diligence ends with the report. If you then inherit the code or change provider, access recovery and stabilization are Software Takeover. Ongoing release testing is Software Quality Assurance. Adversarial testing and hardening of an AI feature belong with AI Security; the running cloud environment with Cloud Security. If the product was built with Lovable, Bolt or similar tools and needs fixing, see Vibe Coding Rescue. If the company needs a technical leader on its side through a raise or a sale, that is a Fractional CTO seat. If we may be asked to quote for remediation, we say so before the review starts.

Preparing your own company for diligence

Founders can commission the same review on their own platform before a raise. The goal is to find the gaps while there is still time to close or explain them. Useful preparation includes a dated architecture diagram, a dependency inventory, access ownership in company accounts, release and incident records and, for AI products, versioned evaluation results. If the product came out of an AI builder, read due diligence on a Lovable, Bolt or Replit app first.
// proof

Assessment work in existing engagements

None of these cases is a formal investor or M&A due diligence. Cedars documents a technical assessment with architecture and requirements records, targeted source review, a scoped AI review and prioritized actions with recheck criteria. Polity documents traceable analysis that identified and prioritized remediation across seven services. Soundromeda documents risk triage and hardening of a prototype before grant committees reviewed the build. They show the review method, not a diligence outcome.

Cedars

Live
Evidence trail Architecture, requirements, assets and responsibilities organized for review.

Documentation structures, targeted source checks and scoped AI assessment gave Cedars a prioritized basis for technical decisions.

PHP JavaScript Python
ENTERPRISE 2026

Polity

Live
7 services Unified Testing

1.5 years owning QA across seven services and multiple vendors. Quality stayed shippable through every refactor.

React Java/Kotlin Go
ENTERPRISE 2026

Soundromeda

Live
Production Vibe-Coded → Hardened

QA-led hardening took a vibe-coded game prototype to a state grant committees backed.

BLOCKCHAIN 2025

These are selected projects, not our full portfolio. We have shipped 100+ products since 2018.

Questions before you start

No. We review the software, its delivery and its operation. Contracts, IP assignments, licences, tax and financial statements stay with your counsel and financial advisers. Where a technical finding affects their work, the report flags it for them without a legal conclusion.
No. The report describes the technical risks we found within the agreed scope and the evidence behind them. How that affects price, terms or the decision to proceed is yours and your advisers’ call.
It depends on the size of the system, the depth you need and how quickly access is granted. After a short scoping call we agree scope, timeline and a fixed price in a signed statement of work.
Read access to the repositories, infrastructure configuration and the data room, plus time with the people who build and run the system. If some access is not granted, the report states which conclusions are limited because of it.
Yes, as a separate engagement after the report, and only if you want that. If there is any chance we will quote for remediation, we disclose it before the review starts so you can judge the independence of the findings.

Choose your next step

Scope a technical due diligence

Describe the decision, the company or system under review and your timeline. A short, non-confidential outline is enough for the first conversation; we sign an NDA before any data room or repository access.

Scope a technical due diligence →