Technical due diligence in a SaaS acquisition: how buyers turn code risk into a diligence plan

Technical debt is broader than messy code

The phrase is often used for shortcuts inside a codebase. Acquisition risk is wider.

Architecture debt

Tight coupling, unclear boundaries, scaling bottlenecks, fragile migrations, or a design that depends on one environment.

Security debt

Unpatched dependencies, weak secrets handling, missing access controls, insecure defaults, or no reliable response to security vulnerabilities.

Operations debt

Manual deployments, poor observability, undocumented recovery, weak backups, or incidents that only one person can fix.

Quality debt

Missing tests, unstable builds, long feedback cycles, high change-failure rates, and recurring regressions across the codebase.

Data debt

Unknown schemas, weak retention controls, inconsistent customer isolation, missing lineage, or migrations that cannot be rehearsed.

Ownership debt

Unclear contractor assignments, incompatible licenses, missing provenance, source code held outside company control, or critical accounts owned personally by the seller.

All can create future cost. Not all require rewriting the product.

Begin with business-critical workflows

Whether the target is a bootstrapped startup, a profitable operator, or the technology arm of a larger merger, code review should follow the product's economic reality. Identify the workflows that create revenue and trust:

• Signup, authentication, and permissions
• Billing, entitlement, and cancellation
• Core product job
• Data import, processing, and export
• Customer integrations
• Support and admin access
• Backups, restore, and incident response

Trace each workflow through services, dependencies, infrastructure, ownership, tests, and monitoring. A beautiful low-risk module does not compensate for a fragile billing or data boundary.

Ask what happens when each dependency fails, becomes slow, changes terms, or loses access. Review observed incidents rather than theoretical architecture alone.

Anchor the review in a secure-development standard

The NIST Secure Software Development Framework organizes practices into preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. Version 1.1 includes documenting security requirements, collecting component provenance, and tracking risks and design decisions.

This is useful because it evaluates the system that produces and maintains software, not just one snapshot. A one-time code audit only proves the state of the codebase on the day of the scan; it does not prove the team can prevent, detect, and fix tomorrow's problems.

For an acquisition, request evidence for:

• Development and production access controls
• Code review and release approvals
• Dependency inventory and update policy
• Secrets management
• Build and artifact provenance
• Security requirements and design decisions
• Vulnerability intake, prioritization, and response
• Incident and postmortem process

Absence of a formal certification is not automatically fatal for a small SaaS. Absence of basic repeatable controls is still relevant.

Treat the review as technical due diligence

A technical due diligence process applies to an asset purchase, a merger, or a straightforward SaaS purchase — only the contract structure changes, not the evidence.

NIST's July 2026 Cybersecurity Supply Chain Due Diligence guide defines due diligence as researching pertinent supplier and product information for informed acquisition decisions. Its components include ownership and control, provenance, resilience, foundational cyber practices, and supply-chain tiers.

Those categories mirror due diligence best practices already used across enterprise deal teams, and they translate well to a SaaS purchase:

• Who controls source, cloud, domains, certificates, stores, and vendor accounts?
• Can every critical component's source and license be explained?
• Can the product recover from a region, provider, database, or staff failure?
• Are basic security controls implemented and evidenced?
• Which third-party vendors and nested subprocessors can interrupt service or access data?

This due diligence process should produce an evidence list, identified gaps, and remediation owners — not a vague red/yellow/green opinion. Sellers increasingly stage this evidence in a virtual data room rather than an ad hoc email thread; request organized, dated access rather than screenshots.

Evaluate delivery and reliability, not developer theater

Commit counts, story points, and lines of code are easy to misread. Google Cloud's DORA research hub centers software delivery on performance indicators such as deployment frequency, lead time for changes, time to restore service, change-failure rate, and reliability.

Its 2025 AI-assisted development findings draw on a research program covering more than 40,000 professionals. Google reports that AI amplifies existing team and system dynamics: more than 80% reported productivity gains, while 30% reported little or no trust in AI-generated code.

For a buyer, that means AI tool usage is neither proof of productivity nor evidence of low quality. Review the actual controls and outcomes:

• How often can the team deploy safely?
• How long does a routine change take?
• What percentage of changes cause incidents or rollback?
• How quickly does service recover?
• Are reliability objectives defined and met?
• Do tests catch failures that matter to customers?
• Does delivery match the product roadmap?

Compare reported metrics with deployment, incident, and monitoring records.

Inventory components, licenses, and ownership

Evaluate the target company's technology stack, dependency hygiene, and incident history before pricing risk. Generate or obtain a software bill of materials covering both licensed and open-source software where feasible. Review direct and transitive dependencies, versions, licenses, maintenance status, known vulnerabilities, and replacement options, and evaluate each against the remediation roadmap.

Then verify the target company's intellectual property ownership:

• Employee and contractor assignment agreements covering proprietary code
• Open-source license obligations
• Purchased or licensed code
• Model, data, font, image, and content rights
• Code copied from previous employers or clients
• Personally owned repositories and accounts

A codebase being accessible does not prove the target company owns every asset inside it.

Review security and incident evidence

The SEC's cybersecurity disclosure rule requires public companies to disclose material cyber incidents and describe their risk-management and governance processes. A private micro-SaaS does not inherit those filing duties merely because it is acquired.

The rule still supports a practical valuation point: cyber incidents, data security failures, and risk-management gaps can be material to investors, operations, and regulatory compliance.

Request:

• Security audit findings, vulnerability scans, and penetration-test reports
• Security incidents and customer notifications
• Insurance claims
• Access and audit logs
• Data-processing agreements and subprocessors
• Backup and restore tests
• Open customer security commitments
• Remediation status and accepted risks

Do not punish a seller for documenting incidents. A truthful record with completed remediation can be stronger evidence than a claim that nothing ever happened.

Convert findings into economic scenarios

Technical diligence becomes useful when findings connect to work, timing, and exposure. Some findings are routine maintenance; others are closing-condition red flags.

Classify each issue:

1. Closing condition: must be resolved or contractually allocated before transfer. 2. Immediate stabilization: needed in the first 30 to 90 days. 3. Growth constraint: blocks roadmap, scale, enterprise sales, or compliance. 4. Routine maintenance: normal work already reflected in operating cost. 5. Monitor: uncertain risk requiring observation rather than immediate rebuild.

For material work, estimate scope with evidence: responsible skill set, dependencies, test requirements, downtime, migration plan, and contingency. Use ranges. A complete rewrite estimate after a cursory review is not diligence.

Separate direct remediation expense from opportunity cost. If six months of engineering capacity must repair the platform, the economic impact may include delayed features and sales work even when cash payroll stays similar. Turn each finding into a checklist item with an owner and a deadline.

Test transferability

Ask a qualified engineer who did not build the target company's product to evaluate transferability directly: set up a development environment, trace a critical request, deploy a safe change, investigate a staged incident, and restore from backup under supervision.

Record where they need undocumented founder knowledge or personal credentials. This practical test often reveals more than another architecture slide.

Verify that cloud, repository, domain, CI, monitoring, app-store, email, and vendor accounts can transfer without destructive changes or secret sharing.

How RSW treats technical debt

RSW treats technical condition as risk and transferability evidence around normalized earnings.

Verified routine maintenance belongs in normal operating expense. Identified remediation can be modeled as a ranged cost and schedule. Material reliability, security, ownership, or key-person uncertainty can widen the valuation range or reduce confidence.

RSW does not assume every legacy system needs replacement. Stable older technology with good controls and documentation may be lower risk than a fashionable stack with weak operations.

Technical due diligence checklist

This checklist assumes the categories above are already scoped. Obtain:

• Architecture and data-flow diagrams
• Repository, CI/CD, infrastructure, and access inventory
• Dependency/SBOM and license review
• Test, deployment, incident, and reliability records
• Security assessments and remediation logs
• Backup, restore, and disaster recovery evidence
• IP assignments and third-party vendor contracts
• Key-person and account-transfer map
• Prioritized remediation plan with ranges
• A supervised transferability exercise

Treat this checklist as a floor for evidence, not a substitute for a qualified reviewer's judgment.

FAQs

What does technical due diligence cover in a SaaS acquisition?

It covers architecture, delivery and reliability metrics, dependency and security evidence, IP ownership, incident history, and a supervised transferability test — not a single code scan or a repository walkthrough.

Does technical debt always reduce value?

No. Some debt is an intentional tradeoff and normal maintenance. It matters when it creates material cost, delay, security exposure, unreliability, or dependency.

What is the difference between sell-side and buy-side technical due diligence?

Sell-side (or vendor) due diligence is commissioned by the seller before a sale, to surface and fix technical issues ahead of a buyer's review. Buy-side due diligence is commissioned independently by the acquirer to verify those technical claims before pricing the deal. A seller's report is useful evidence — it is not a substitute for independent buy-side verification.

What are the main types of due diligence in an acquisition?

Buyers typically run commercial (market, customers, competition), financial (books, forecasts, quality of earnings), legal (contracts, compliance, IP), and technical (architecture, security, delivery, and transferability) tracks in parallel as part of one due diligence process. This article focuses on the technical track, which applies equally to a merger or an outright purchase.

Can an automated code scan replace diligence?

No. Scans are useful evidence but cannot prove architecture, operating practice, ownership, recoverability, or business impact.

Should a buyer demand a rewrite?

Only when evidence supports it. Rewrites carry cost and execution risk. Stabilization and incremental remediation may be safer.

What is the best code-quality metric?

There is no single one. Combine delivery, failure, recovery, reliability, security, maintainability, ownership, and transferability evidence into one software quality picture.

Continue through the RSW silos

Anchor the review in the SaaS valuation pillar, then pair it with technical-risk valuation and security-risk valuation.

The WordPress plugin business guide and API business valuation show how software dependencies differ by model. Use the privacy and security guide for data-access and transfer risks.

Start with a valuation range, then price the work

Use the Real Site Worth website value calculator for an automated starting range. Then scope technical findings, remediation, and transferability with qualified engineering, security, legal, and financial reviewers.