SaaS Technical Due Diligence: What Investors and Buyers Check

SaaS technical due diligence checks three things: whether the product can grow without a rewrite, whether the code and IP are clean enough to own, and what fixing the gaps will cost. Investors and buyers review architecture, code quality and tests, security, open-source licences, IP ownership, delivery metrics, cloud cost and key-person risk, and ask for evidence rather than assurances.

If you would rather have the gaps fixed for you before the review, see how RAITHub would build this below.

This guide is written for founders and CTOs on the receiving end: a term sheet or letter of intent has arrived, and a technical review is next. It explains what reviewers look at, the evidence that answers each question, the findings that most often change a deal, and how to prepare in the weeks before. It is engineering guidance, not legal or financial advice; deal terms belong with your advisers.

What is SaaS technical due diligence?

A structured review of a software company's product, codebase, infrastructure and engineering team, carried out for an investor or acquirer before a deal closes. The output is usually a written report that lists risks, rates their severity and estimates the effort to fix them.

Depth depends on the deal. An early-stage round may involve a one-hour call with a technical adviser and a look at the architecture diagram. A growth round or an acquisition usually involves read access to repositories, automated scans, interviews with the team and a written report, sometimes from a specialist firm.

What do investors and buyers check in a SaaS technical review?

Eight areas come up in almost every review. The right-hand column is what lets you answer with evidence instead of an interview.

Area	Questions reviewers ask	Evidence to have ready
Architecture and scalability	Can it handle 10 times the customers? How are tenants isolated? What are the single points of failure?	A current architecture diagram, data model, tenancy model and load-test results
Code quality and tests	Is the code maintainable? How much is covered by automated tests? How often do releases break?	CI history, test counts by type, coverage on critical paths, a list of known technical debt
Security	How are authentication, access control and secrets handled? When was the last security test?	Security test reports and fixes, dependency-scan results, access reviews, incident log
Open-source licences	Are any licences incompatible with how the product is sold? Is there unlicensed code?	A software bill of materials and a licence report
IP ownership	Did every employee and contractor assign their work to the company?	Signed IP assignments for every contributor, including agencies and freelancers
Delivery and process	How fast and safely does the team ship?	Deployment frequency, change fail rate and recovery time for the last quarter
Infrastructure and cost	What does hosting cost per customer, and how will it scale? Are backups tested?	Cloud bills by service, a cost-per-tenant estimate, a dated restore drill
Team and key-person risk	What happens if one engineer leaves? Is knowledge written down?	Runbooks, onboarding docs, access held by the company rather than individuals

Why do open-source licences matter so much in due diligence?

Because almost every codebase uses open source, and licence problems are common and slow to fix after signing. Black Duck's 2026 Open Source Security and Risk Analysis, based on 947 codebases its audit team reviewed, including 197 merger and acquisition transactions, found open source in 98% of codebases, licence conflicts in 68% and at least one known vulnerability in 87% (Black Duck 2026 OSSRA).

The usual remedy is a software bill of materials (SBOM), a machine-readable list of every component and its licence. CISA's 2025 draft of the minimum elements for an SBOM adds component hash, licence, tool name and generation context to the required fields (CISA 2025 Minimum Elements for an SBOM). For a Node.js product, generating one is a single command with the CycloneDX tool:

# From the project root, after a clean install
npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.json

# Production dependencies only
npx @cyclonedx/cyclonedx-npm --omit dev --output-file sbom-prod.json

Run it in CI so the SBOM always matches what ships, and review any component whose licence is missing, custom or copyleft against how you distribute the product. Licence interpretation is legal territory; confirm anything unclear with your adviser.

What security evidence do reviewers expect?

Proof that security is a routine, not a one-off. Reviewers commonly measure against OWASP guidance; the Application Security Verification Standard, now at version 5.0.0, is a widely used checklist for what to verify (OWASP ASVS). Expect questions on:

• How authentication and sessions work, and whether access between tenants is enforced in the database or only in application code.
• Where secrets live and who can read production data.
• The date and findings of the last security test, and whether each finding was fixed.
• Dependency updates: how quickly known vulnerabilities are patched.
• Formal assurance. A SOC 2 report is an examination of controls relevant to security, availability, processing integrity, confidentiality or privacy (AICPA SOC 2). Not having one is normal for early-stage companies; having a dated plan helps. See SOC 2 for early-stage startups.

RAITHub's security testing, part of its QA as a service, is application-level testing against OWASP guidance. It is not a CREST- or PCI-certified penetration test and produces no compliance attestation; if a buyer requires one, use a certified provider. The checks are listed in the OWASP Top 10 testing checklist.

Which delivery metrics do reviewers ask for?

Usually some version of the DORA metrics. DORA defines change lead time, deployment frequency, change fail rate, failed deployment recovery time and deployment rework rate; change fail rate is "the ratio of deployments that require immediate intervention following a deployment" (DORA software delivery metrics). You do not need to be elite on every metric. You need to know your numbers and show that releases are tested and reversible.

What findings most often change a SaaS deal?

Findings that are expensive or slow to fix after closing. In practice these come up again and again:

• Missing IP assignments from early contractors or an agency, so the company cannot prove it owns all its code. The clauses to look for are in the offshore IP assignment checklist.
• Weak tenant isolation, where one customer could read another's data through a missing check.
• No tests on billing and permissions, so every change is a risk to revenue.
• Licence conflicts in components the product ships.
• Untested backups. A backup that has never been restored is an assumption; see SaaS backup and disaster recovery.
• One person holds the keys, to production, the domain or the cloud account.

Most of these are fixable in weeks, not months, if found before the review. Found during the review, they become price adjustments, escrow, special indemnities or conditions to close.

How should you prepare for technical due diligence?

Run the review on yourself first, four to eight weeks before you expect it.

1. Inventory. List repositories, environments, third-party services and who has admin access to each.
2. Generate an SBOM and licence report, and resolve anything unclear.
3. Collect IP paperwork for every past and present contributor.
4. Run a dependency scan and an application security test, and fix high-severity findings.
5. Measure tests and delivery: test counts, CI pass rate, deployment frequency and change fail rate.
6. Restore a backup into a clean environment and record how long it took.
7. Write the data room pack: architecture diagram, known-debt list with a plan, runbooks, and cloud costs per customer.

Do-it-yourself estimate: 1–3 weeks for a CTO who knows the codebase, more if documentation is thin. The main risk is marking your own homework; an outside review finds what the team has learned to live with. What an independent review covers is described in what to expect from a code audit.

Buy, build or hire?

Option	Choose this when	Watch out for
Off-the-shelf scanning tools	You need an SBOM, licence report and dependency scan quickly and the team can act on the results	Tools list issues; they do not fix them or judge architecture
Template checklist, self-review	An early round, a strong CTO and time before the review	Blind spots the team has grown used to
Independent pre-diligence review and fix	A larger round or acquisition, thin documentation, or code from several past vendors	Make sure the reviewer also fixes or plans fixes, and that security testing is described honestly

Why RAITHub for this

• Test-heavy SaaS delivery. PropDesk runs 1,024 automated tests; Sundor Skin has 530+ tests and row-level security on 146 PostgreSQL tables; this website has 400+ tests.
• Code rescue experience. RAITHub takes over and stabilises codebases built by other teams; see code rescue.
• Honest about assurance. RAITHub is not SOC 2 or ISO 27001 certified and its security testing is not a certified penetration test. It will say so in writing.

When you don't need us

• The review is a short call at an early round, and your CTO can answer the table above with evidence.
• The buyer requires a certified penetration test or a SOC 2 report. Those come from certified firms and auditors, not from RAITHub.
• You need legal or tax diligence. That belongs with your lawyers and accountants.

How RAITHub would build this

Scope, agreed in writing before work starts:

• A pre-diligence review against the eight areas above, with a severity-ranked findings list.
• SBOM and licence report generated in CI, and dependency updates for high-severity issues.
• Fixes for the findings that would change the deal: tenant isolation, tests on billing and permissions, secrets and access.
• Application security testing against OWASP guidance, and a recorded backup restore.
• A data room pack: architecture diagram, runbooks, known-debt plan and delivery metrics.

Timeline: 2–4 weeks for a review-and-stabilise scope, in line with the code rescue range; larger remediation at 4–6 weeks fixed scope.

You receive: automated tests and CI, handover docs and runbooks, and full IP under NDA.

Next step: a free 15-minute technical audit, then a written fixed quote. See the SaaS development service and QA as a service, or book the audit.

Frequently asked questions

What is checked in SaaS technical due diligence?

Architecture and scalability, code quality and tests, security, open-source licences, IP ownership, delivery metrics, infrastructure cost and backups, and key-person risk in the engineering team.

How long does technical due diligence take?

From a single call at an early round to several weeks for an acquisition, depending on depth. Preparing beforehand usually takes 1–3 weeks for a team that knows its codebase.

Do I need SOC 2 before technical due diligence?

Not usually at early stages. Reviewers want to see sound controls and a dated plan. A SOC 2 report comes from an independent auditor, and RAITHub is not SOC 2 certified and cannot provide one.

What is an SBOM and why do buyers ask for it?

A software bill of materials lists every component in your product and its licence. Buyers use it to find licence conflicts and known vulnerabilities, which Black Duck's 2026 report found in 68% and 87% of audited codebases.

What are the most common red flags in SaaS due diligence?

Missing IP assignments from contractors, weak tenant isolation, no tests on billing or permissions, licence conflicts, untested backups, and production access held by one person.

Is RAITHub's security testing a penetration test for due diligence?

No. It is application-level testing against OWASP guidance and produces no compliance attestation. If a buyer requires a CREST- or PCI-certified penetration test, use a certified provider.