The SaaS Tech Due Diligence Checklist

Technical diligence on a SaaS target answers two questions at once: what did we buy and what will it cost us to keep it running. The checklist below is the working version we run on every engagement at Beyond M&A, condensed for a buyer audience.

How to use this checklist

Run it in three passes. First pass is desk research — what the data room reveals without asking the seller a single follow-up. Second pass is the architecture session, ideally 90 minutes with the CTO and lead engineer. Third pass is the targeted vendor and customer reference calls. Score each line 1–5; anything scoring 2 or below becomes a deal term.

1. Architecture & scalability

The first thing to look at is the deployment topology. A SaaS platform that runs as a single multi-tenant database with row-level isolation behaves very differently at acquisition than one with per-tenant schemas or per-tenant clusters. Multi-tenant is cheaper to operate but harder to onboard regulated enterprise customers later.

Look for monolithic drift — where the cost of shipping a feature has grown faster than the team. Pull deployment frequency from the CI logs; a healthy SaaS business deploys to production every working day. Anything below weekly in a sub-200-engineer company is a signal of architectural debt.

2. Security posture

The baseline is now AES-256 at rest, TLS 1.3 in transit, SSO via SAML or OIDC, and audit logs that survive customer-initiated tenant deletion. SOC 2 Type II is no longer a differentiator — it's the table-stakes ask. ISO 27001 and HIPAA matter for regulated verticals.

Read the latest pen test report, not the certificate. Look at the severity distribution of findings — a clean report with one Critical is worse than a busy report with everything Medium and below.

3. AI exposure (the new diligence frontier)

For any AI-enabled feature, the seller must be able to produce:

• The training data lineage, including consent and licence basis for every dataset.
• The model dependency graph — which third-party APIs would break the product overnight if discontinued.
• The data-residency posture for each model call (US-only, EU-only, or unconstrained).
• A statement of which customer data, if any, has been used to train the seller's own models.

A target that cannot answer the third or fourth question in writing is a Repricing Event 80% of the time.

4. Engineering team & key-person risk

Map every production system to the single engineer who could rebuild it tonight from scratch. Where that number is one, you have key-person risk; flag it for retention packages. Where that number is zero (the original engineer has already left), you have architectural inheritance risk — far more expensive to fix.

5. Unit economics of the stack

Cloud cost per active user is the cleanest single metric. Pull the last twelve months of AWS, GCP, or Azure invoices and divide by the average monthly active customer count. Compare to the target's gross margin disclosure. Discrepancies of more than 15% almost always indicate either over-engineered infrastructure or undisclosed customer concentration.