Skip to main content

SaaS Due Diligence Checklist

A complete 8-area due diligence framework for evaluating a SaaS business before acquisition. Use this checklist alongside the general website due diligence guide and the website acquisition checklist. SaaS acquisitions require deeper verification than content site or eCommerce deals because the core assets, recurring revenue, customer relationships, and codebase, are all invisible until you dig in.

1.Financial due diligence: MRR, ARR, and revenue verification

  • Request Stripe (or billing platform) dashboard access, verify MRR by exporting all active subscriptions and summing recurring charges
  • Cross-reference Stripe MRR against seller's stated MRR, discrepancy of more than 5% requires explanation
  • Review MRR over the trailing 24 months, identify growth trend, plateau, or decline and any one-time spikes
  • Verify that MRR figures exclude one-time charges, setup fees, and non-recurring revenue
  • Request bank statements for the past 12 months, confirm that deposits match billing platform revenue (accounting for Stripe/PayPal fees)
  • Identify any lifetime deal (LTD) users from AppSumo or similar platforms, they reduce future MRR potential and affect NRR calculation
  • Confirm SDE calculation: MRR × 12 minus all annual operating expenses (hosting, tools, support staff, software subscriptions), add back owner salary if applicable
  • Verify add-backs, non-recurring expenses, personal expenses, or one-time costs claimed to increase SDE should be documented and credible

2.Churn analysis and cohort retention

  • Request monthly churn rate data for the trailing 24 months, calculate as (customers lost in month / customers at start of month) × 100
  • Ask for cohort retention data: for customers who started in months 1, 3, 6, and 12 ago, what percentage are still active?
  • Identify whether churn is concentrated in a specific pricing tier, acquisition channel, or customer segment
  • Request Net Revenue Retention (NRR), if NRR is above 100%, expansion revenue offsets cancellations; below 85% indicates a structural retention problem
  • Check whether churn is improving, stable, or worsening over the trailing 12 months
  • Ask for cancellation survey data, what reasons do customers give when cancelling?
  • Verify Gross Revenue Retention (GRR) separately from NRR, GRR above 90% for B2B and 80% for B2C is a healthy benchmark
  • Calculate implied LTV: (ARPU ÷ monthly churn rate), verify this is at least 3× CAC

3.Customer base and concentration risk

  • Request the full customer list with MRR per customer (anonymised if needed), identify the percentage of total MRR from the top 5, top 10, and top 20 customers
  • Red flag: any single customer contributing more than 20% of MRR creates dangerous concentration risk
  • Identify whether the customer base is B2B or B2C, B2B customers have lower churn but are harder to replace when they leave
  • Check the distribution of plan tiers, a healthy SaaS has customers across multiple price points, not all in the cheapest tier
  • Ask how many customers came from lifetime deals (AppSumo, StackSocial, etc.), LTD users inflate customer count without contributing to MRR
  • Verify customer acquisition channels, organic, SEO, paid ads, content, product-led growth, or referrals, and whether those channels will continue under new ownership
  • Check whether any large customers are personal contacts of the seller who might not renew with a new owner (key-person risk at the customer level)

4.Technical due diligence: codebase and infrastructure

  • Hire an independent developer to review the codebase, budget $300-$1,000 for a technical review even if you are non-technical
  • Identify the programming language, framework, and hosting infrastructure, is the stack modern and maintainable, or obsolete?
  • Check for hardcoded API keys, credentials, or secrets in the repository, these represent a security risk and indicate poor engineering practices
  • Review dependency list for outdated packages with known CVEs (security vulnerabilities)
  • Assess test coverage, low or no automated tests mean higher risk when making post-acquisition changes
  • Check database size and schema complexity, large, denormalised databases or tightly coupled schemas are costly to modify
  • Review hosting costs and scaling trajectory, confirm that infrastructure costs won't spike unexpectedly as the user base grows
  • Evaluate the quality and completeness of technical documentation, SOPs, runbooks, and architecture diagrams significantly reduce transition risk

5.API and platform dependency risk

  • List all third-party APIs and services the product depends on, identify which ones are critical path (product breaks without them)
  • For each critical API, assess: Is the pricing model fixed or usage-based? Has pricing increased significantly in the past 12 months? Is the service financially stable?
  • Check whether the product is built on top of another platform (Zapier, Notion, Slack), platform-dependent tools are subject to policy changes that can break the product overnight
  • Verify that all API keys and service accounts can be transferred to a new owner, some services (Google APIs, Stripe Radar) have account-level restrictions on transfer
  • Check OpenAI or other AI API usage, if the product relies heavily on LLM APIs, verify cost per request and sensitivity to pricing changes
  • Identify any data suppliers or licensed datasets, confirm that data licenses are transferable
  • Review the product's Terms of Service for any API usage restrictions that could conflict with continued operation

6.Legal and contractual review

  • Confirm the business structure of the acquisition, are you buying assets (the code, domain, customer list) or the legal entity?
  • Review all customer contracts, confirm that customer contracts can be assigned to a new owner without customer consent or with a standard notification process
  • Check Terms of Service and Privacy Policy, verify they comply with GDPR and CCPA and that a new owner can continue using customer data
  • Review any outstanding disputes, refund requests, or chargebacks, ask for the past 12 months of customer support tickets
  • Confirm that all code and content is either original or properly licensed, check for any open-source licenses that may restrict commercial use or require code disclosure
  • Verify intellectual property ownership: was the product built entirely by the seller, or by contractors? Were contractor agreements 'work for hire'?
  • Review payment processor terms, confirm Stripe, PayPal, or other accounts can be transferred or that there is a clear migration path
  • Check for any non-disclosure agreements or exclusivity clauses with enterprise customers that could restrict how you operate post-close

7.Traffic, SEO, and growth channel verification

  • Request read-only access to Google Analytics 4, verify monthly active users, traffic sources, and growth trend over 24 months
  • Request read-only access to Google Search Console, verify organic keyword rankings, click-through rates, and any manual action warnings
  • Cross-reference GA4 traffic against Ahrefs or Semrush estimated organic traffic, significant divergence can indicate bot traffic or unreported traffic sources
  • Verify paid acquisition: request Google Ads, Meta Ads, or other ad platform data, confirm ad spend, CPA, and whether CAC is sustainable
  • For SaaS products with product-led growth (PLG), verify trial-to-paid conversion rate, activation rate, and time to first value
  • Check for any recent traffic drops or ranking declines, a sudden organic traffic loss 1-3 months before listing is a major red flag
  • Verify that growth attribution is accurate, confirm that an MRR spike is from genuine new customers, not a lifetime deal campaign or one-off enterprise contract

8.Transfer planning and handover checklist

  • Confirm that the source code repository (GitHub or GitLab) can be fully transferred, get written confirmation of repository ownership and absence of co-owners
  • Verify all hosting accounts (AWS, GCP, Heroku, Render, DigitalOcean) can be transferred or have a migration path, confirm no shared tenancy with other products
  • Confirm domain name and DNS control, obtain the EPP/auth code for the domain transfer before releasing escrow funds
  • Verify Stripe account transfer feasibility, Stripe allows account ownership transfers; confirm email, 2FA, and business details are updatable
  • List all third-party tool accounts that must transfer: Intercom, Mailchimp, Postmark, Sentry, Datadog, etc.
  • Negotiate a transition support period of 30-90 days, request defined weekly availability (e.g., 2 hours/week) and a specific scope of support
  • Request a knowledge transfer document covering: common support issues and how to resolve them, critical deployment procedures, and key vendor contacts
  • Use escrow (Escrow.com) and release funds only after verifying access to every critical system, do not release escrow on the promise of post-close access

Key SaaS due diligence benchmarks

Monthly churn rate

Good: Under 2%

Caution: 2-5%

Red flag: Over 5%

Net Revenue Retention

Good: Over 110%

Caution: 90-110%

Red flag: Under 85%

Customer concentration

Good: Top customer under 10% MRR

Caution: Top customer 10-20% MRR

Red flag: Top customer over 20% MRR

LTV:CAC ratio

Good: 3:1 or higher

Caution: 2:1 to 3:1

Red flag: Under 2:1

MRR growth trend

Good: Growing or stable 24 months

Caution: Flat last 6 months

Red flag: Declining any period

GRR (Gross Revenue Retention)

Good: B2B 90%+, B2C 80%+

Caution: B2B 80-90%

Red flag: Under 75% any type

Frequently asked questions

What is the most important thing to verify when doing SaaS due diligence?
Churn rate is the single most important metric to verify and the hardest to fake accurately. A seller claiming 1% monthly churn but with declining MRR over the past 6 months is inconsistent, verify churn independently by calculating it from the raw customer-level subscription export, not from a summary the seller provides. After churn, verify the independence of the customer base from the founder: if the top 3 customers are personal contacts of the seller who will leave when the founder does, the business is worth far less than its headline metrics suggest.
Do I need to be technical to do SaaS due diligence?
No, but you need access to someone technical. The financial, customer, legal, and traffic due diligence areas can all be completed without coding knowledge. The technical due diligence area, codebase review, security assessment, dependency audit, requires a developer. Hiring an independent developer for a one-time technical review ($300-$1,000) is standard practice for any SaaS acquisition over $10,000. Frame it as a structural inspection before buying a house. Even if you plan to hire a developer post-acquisition to maintain the product, an independent pre-acquisition review gives you leverage to negotiate price and protects you from discovering critical technical debt after closing.
How long does SaaS due diligence take?
For a small SaaS ($5,000-$50,000 acquisition price), plan for 1-2 weeks of active due diligence after the seller grants access. Financial and revenue verification (2-3 days), churn and cohort analysis (1-2 days), technical review by a developer (3-7 days), customer base and concentration analysis (1 day), and legal review (1-3 days if you use a lawyer). For deals above $100,000, budget 3-5 weeks and consider commissioning a formal Quality of Earnings (QoE) report ($2,000-$8,000) from an independent accountant, this is standard for mid-market transactions and gives you the most defensible basis for price negotiation.
What SaaS due diligence red flags should cause me to walk away?
Walk away if you find: (1) MRR that cannot be reconciled with bank statements, unexplained discrepancies of more than 10% indicate revenue fabrication. (2) Monthly churn above 8%, the business will shrink faster than you can replace customers. (3) More than 40% of MRR from one customer, single-customer concentration makes the acquisition a bet on one relationship. (4) Hardcoded credentials in the codebase combined with a seller who won't allow a developer review, this combination suggests hidden technical liabilities. (5) A recent MRR spike (last 1-3 months) that the seller cannot explain with verifiable customer data, this pattern often indicates a lifetime deal campaign designed to inflate trailing MRR before listing. Any one of these, if confirmed, is sufficient justification to walk away or demand a significant price reduction.

Related guides

Ready to browse SaaS businesses for sale?

Apply this checklist to live listings, browse SaaS businesses with verified revenue, direct from founders, no broker fees.