The SaaS Buyer’s Due Diligence Playbook: Everything to Verify Before You Buy

“In an acquisition, confidence should never come from the seller’s presentation alone; it should come from evidence that survives independent verification.”

Introduction: Why SaaS Due Diligence Is Different

Buying a software-as-a-service business is not like buying a restaurant, a retail store, or a small manufacturing company. A conventional small business is evaluated primarily on physical assets, location, inventory, and historical earnings. A SaaS business is evaluated on something far less tangible: recurring revenue that is supposed to continue long after the seller has departed. That recurring revenue is both the greatest appeal of SaaS and the greatest source of illusion.

The promise of SaaS is seductive. Customers pay every month or every year. Revenue is predictable. Margins can be high. The product scales without requiring a proportional increase in staff. A buyer looks at the MRR and ARR charts and imagines a steady stream of future cash flow. The seller reinforces this with a polished data room, impressive dashboards, and a compelling narrative about product-market fit and growth potential.

But MRR and ARR alone are not evidence of a good acquisition. They are simply numbers that a seller has chosen to display. A SaaS business can report $25,000 in monthly recurring revenue and still be a disastrous purchase. That $25,000 might be concentrated in two enterprise customers who are negotiating away from the platform. It might depend on a founder who writes all the code, answers all the support tickets, and personally renews every major contract. It might be generated by a codebase that has no documentation, no tests, and no backup. It might rely on a payment processor account that is not transferable to the buyer. It might be inflated by promotional pricing, lifetime deals, or revenue categories that are not actually recurring.

Technical debt can destroy value that headline revenue suggests. A codebase that has not been maintained for years can require more investment to fix than the acquisition itself costs. Customer concentration can create hidden fragility: if one customer represents 40% of revenue, the entire investment thesis depends on retaining that single relationship. Founder dependency matters because the seller may be the product’s architect, lead developer, chief salesperson, and customer success manager all in one. Intellectual property ownership must be verified because paying for code does not automatically mean the seller has the legal right to transfer that code to you.

Payment processor records matter because they are the closest thing to ground truth for SaaS revenue. But even processor data can be misleading if not properly analyzed. Customer retention matters more than customer count because a business with 1,000 customers and 5% monthly churn is fundamentally weaker than a business with 300 customers and 1% monthly churn. Infrastructure and third-party dependencies can materially change profitability because API costs, cloud hosting, AI inference fees, and payment processing charges are not fixed overhead — they scale with usage and can erode margins silently.

This manual exists to help you move from seller claims to verified truth. It is not a ten-point checklist. It is a complete, repeatable system for investigating a SaaS acquisition from the first screening conversation to the final wire transfer. The central principle is simple:

Do not simply ask whether the SaaS is profitable. Ask whether the revenue, customers, technology, intellectual property, operations, and future economics are transferable, sustainable, and independently verifiable.

Every section of this guide follows a consistent path:

Seller claims → Evidence → Reconciliation → Risk assessment → Valuation adjustment → Deal protection → Final decision.

You are not trying to prove the seller wrong. You are trying to determine what is true. The difference is fundamental. A hostile buyer looks for reasons to reject a deal. A professional buyer looks for evidence that either supports or contradicts the investment thesis. The goal is not to avoid all risk — no acquisition is risk-free — but to identify, quantify, price, and mitigate risk before it becomes an expensive surprise.

How to Use This Manual

Do not attempt to investigate everything at once. Due diligence is a progression, not a random audit. Work through the process in three deliberate stages, each with its own objective and level of depth.

Stage 1 — Initial Screening

The purpose of screening is to decide whether the opportunity deserves weeks of deeper investigation. You are looking for immediate disqualifiers: revenue that cannot be verified, obvious IP problems, extreme founder dependency, a seller who refuses to provide primary records, or a business model that is structurally broken. Most SaaS acquisition opportunities fail at this stage — and that is a good thing. Screening exists to save you time and capital.

Stage 2 — Full Due Diligence

Once an opportunity passes screening, you enter full due diligence. This is where you collect primary records, review contracts, audit code, interview customers, analyze cohorts, test infrastructure, and build a risk register. Every claim the seller has made should be matched against independent evidence. This stage typically takes weeks, not days.

Stage 3 — Pre-Closing Verification

Between the end of full due diligence and the actual closing date, circumstances can change. Customers churn. Employees leave. Security incidents happen. Payment processor accounts get frozen. A final pre-closing verification confirms that the business you are buying on closing day is still substantially the same business you investigated.

Some checks can be performed personally by a diligent buyer. Others require professional expertise. You should expect to involve:

• Accountants — for financial verification, normalization, and tax analysis
• SaaS finance specialists — for MRR, ARR, churn, NRR, and cohort analysis
• Technical experts — for code review, architecture assessment, and infrastructure audit
• Cybersecurity professionals — for penetration testing, vulnerability assessment, and security posture review
• Lawyers — for contract review, IP verification, corporate structure, and transaction documents
• Tax professionals — for jurisdiction-specific tax exposure, VAT/GST/sales tax, and transferability

Professional advice is not optional for legal, tax, IP, privacy, employment, and regulatory matters. This manual identifies what to investigate; it does not replace qualified counsel.

The SaaS Due Diligence Master Framework

Due diligence on a SaaS business spans at least forty-two interconnected categories. They overlap significantly. A finding in the customer category may affect the financial category. A discovery in the code review may reshape the valuation discussion. A security issue may create a legal liability. Treat these categories as lenses through which you examine the same underlying asset, not as separate boxes to check independently.

1. Financial Due Diligence

2. Revenue Verification

3. Payment Processor Verification

4. MRR and ARR Verification

5. Profitability and Cash Flow

6. Customer Due Diligence

7. Churn and Retention

8. Customer Cohorts

9. Customer Concentration

10. Contracts and Renewals

11. Product Due Diligence

12. Technical Due Diligence

13. Source-Code Review

14. Infrastructure and Cloud

15. Cybersecurity

16. Third-Party Dependencies

17. Open-Source Software

18. Intellectual Property

19. AI and Data Dependencies

20. Privacy and Data Protection

21. Legal Due Diligence

22. Corporate Structure

23. Tax Due Diligence

24. Employees and Contractors

25. Founder Dependency

26. Operations

27. Marketing

28. SEO

29. Sales

30. Customer Acquisition

31. Unit Economics

32. Vendor Relationships

33. Hidden Liabilities

34. Competitive Position

35. Growth Sustainability

36. Seller’s Reason for Selling

37. Data Room

38. Risk Register

39. Valuation Adjustment

40. Transaction Structure

41. Representations and Warranties

42. Escrow/Holdback

43. Transition Assistance

44. Final Pre-Closing Audit

These categories overlap by design. A revenue verification problem may originate in the payment processor data. A customer concentration risk may surface during cohort analysis. A technical debt finding may force a valuation adjustment. The framework works only when all findings are consolidated into a single risk register and evaluated together.

The Evidence Hierarchy: Not All Data Is Equal

Before diving into specific diligence areas, understand that evidence exists on a spectrum of reliability. A seller who shows you a spreadsheet is providing a different quality of evidence than a seller who grants read-only access to the payment processor account. A seller who shows you a Stripe dashboard screenshot is providing weaker evidence than a seller who exports a raw subscription dataset.

Level	Type	Examples
Level 1 — Primary Records	The strongest evidence. Generated by a third party or an independent system, not by the seller.	Payment processor raw exports, bank statements, accounting ledgers, source code repositories, signed contracts, official trademark registrations.
Level 2 — System Data	Data accessed directly from operational systems, but still potentially subject to seller configuration or selective extraction.	Analytics platforms, billing dashboards, CRM records, cloud billing consoles, database exports.
Level 3 — Third-Party Evidence	Information obtained from sources other than the seller, but not always fully verifiable.	Customer interview confirmations, vendor confirmations, external market reports, independent traffic estimates.
Level 4 — Seller Representations	The weakest evidence. Produced or curated by the seller without independent verification.	Spreadsheets, presentations, verbal statements, dashboard screenshots, marketing materials.

The rule is simple: the more important the claim, the stronger the evidence required. If the seller claims $30,000 in monthly recurring revenue, a spreadsheet is insufficient. You need payment processor exports, accounting records, and bank deposits that independently reconcile. If the seller claims the code is proprietary, you need the repository history, the developer contracts, and the IP assignment chain. If the seller claims 95% customer retention, you need the raw cohort data, not a summary metric.

Financial Due Diligence: The Foundation

Financial due diligence is not simply checking whether revenue exists. A seller can produce legitimate revenue numbers that are nonetheless misleading. Revenue might be real but non-recurring. It might be real but concentrated in one or two customers. It might be real but collected at unsustainable discounts. It might be real but offset by undisclosed expenses that the seller has excluded from the profit calculation.

The core question is:

Is the reported revenue real, correctly classified, collectible, recurring, profitable, and sustainable after acquisition?

What to Request

• 24–36 months of monthly profit and loss statements
• Balance sheets for the same period
• Cash-flow statements where available
• Business bank statements for all accounts
• Payment processor raw exports (not screenshots)
• Accounting records including general ledger and trial balance
• All customer invoices and subscription records
• Accounts receivable aging reports
• Accounts payable records
• Tax filings where appropriate and jurisdictionally relevant
• Refund records and credit notes
• Chargeback and dispute records
• Discount and coupon usage records
• Outstanding obligations, debts, and commitments

How to Verify

Compare the P&L against the bank statements and payment processor records. The P&L is the seller’s interpretation of what happened. The bank statement is what actually happened. The payment processor is the third-party record of customer payments. When these three sources disagree, the discrepancy itself is a finding. Legitimate timing differences exist — a payment made on the last day of the month may settle in the following month — but unexplained or persistent discrepancies indicate either accounting errors or deliberate misrepresentation.

Red Flags

• P&L revenue exceeds bank deposits consistently
• Payment processor data is unavailable or only available as screenshots
• Large adjustments or “other income” categories without explanation
• Refunds or chargebacks that spike in specific periods
• Accounts receivable that grow faster than revenue
• Revenue recorded before payment is actually received
• Expenses that appear in the P&L but not in the bank statements

What to do if something is wrong: If the sources do not reconcile, stop and demand an explanation before proceeding. Request the raw data. If the seller cannot or will not provide reconciling evidence, treat the revenue claim as unverified and adjust your valuation accordingly, potentially to the point of walking away.

Revenue Verification: Separating Recurring from Everything Else

What is it?

Revenue verification is the process of determining what a SaaS business actually earns — and from which sources. Not all revenue is equal. A SaaS business with $200,000 in annual revenue might have $180,000 in true recurring subscription revenue, or it might have $120,000 in one-time setup fees, $40,000 in consulting, $25,000 in lifetime deals, and only $15,000 in actual recurring subscriptions.

The distinction matters because a buyer is acquiring the future, not the past. Recurring subscription revenue is — if the customers stay — repeatable. One-time revenue is not. A seller may report combined revenue that masks the fact that the core subscription engine is weaker than it appears.

Revenue Categories to Identify

Category	Description	Quality for Buyer
Gross Revenue	Total revenue before any deductions, including processing fees, refunds, and discounts.	Not a reliable profit indicator; inflates apparent size.
Net Revenue	Revenue after refunds, chargebacks, discounts, and processing fees.	More meaningful than gross; still may include non-recurring items.
Recurring Revenue (MRR/ARR)	Revenue from ongoing subscription or usage-based contracts expected to repeat.	The highest-quality revenue; the core of SaaS valuation.
One-Time Revenue	Setup fees, implementation fees, one-time add-ons, custom development.	Not recurring; should not be multiplied into a valuation.
Services/Consulting Revenue	Revenue from professional services, training, migration assistance, or custom work.	Low transferability; often requires founder expertise.
Lifetime Deals (LTDs)	One-time payments for lifetime access; sometimes used to boost cash flow.	Creates future support obligations without future revenue; distorts MRR.
Affiliate/Advertising Revenue	Revenue from promoting third-party products or displaying ads.	Often volatile; may not transfer with the product.
Marketplace Revenue	Revenue from app stores, plugin directories, or marketplace commissions.	Depends on platform policies; transfer risk exists.

A practical example: A seller reports $24,000 in monthly revenue. Upon verification, you discover that $6,000 comes from implementation fees, $3,000 from a consulting retainer, $2,000 from a one-time custom build, $1,500 from affiliate commissions, and only $11,500 from actual recurring subscriptions. The seller’s MRR claim of $24,000 is technically true in a broad revenue sense but materially misleading for valuation purposes.

Remember: Revenue ≠ MRR ≠ ARR ≠ Cash Received ≠ Profit. Each term has a specific meaning, and a professional buyer never substitutes one for another.

Stripe and Payment Processor Due Diligence: The Ground Truth

The payment processor is the single most important source of truth for SaaS revenue. Stripe is the most common for subscription SaaS businesses, but the same principles apply to PayPal, Paddle, Lemon Squeezy, Chargebee, Recurly, Braintree, and any other billing or payment system. If the business uses multiple processors, you must verify each one.

What to Verify in Payment Data

• Successful payments — the actual revenue collected, not attempted charges
• Failed payments — attempted but declined; may indicate subscription cancellation risk
• Refunds — money returned to customers; reduces net revenue
• Disputes and chargebacks — contested payments; can signal customer dissatisfaction or fraud
• Processing fees — the cost of collecting revenue; reduces net proceeds
• Payouts — money actually transferred to the seller’s bank account
• Invoices — bills sent to customers, whether paid or unpaid
• Subscriptions — the underlying recurring billing relationships
• Cancellations — subscriptions that have been terminated
• Paused subscriptions — temporarily suspended; may or may not resume
• Past-due customers — subscribers who have not paid; a revenue collection risk

What to Verify in Subscription Data

• Active subscriptions — the real count of currently billed customers
• Monthly vs. annual subscriptions — affects cash flow timing and churn patterns
• Grandfathered pricing — customers on legacy plans that may be unprofitable
• Discounts and coupons — reduces effective MRR; may expire or be expected to continue
• Free trials — not yet revenue; conversion uncertainty
• Canceled subscriptions — historical churn evidence
• Failed renewals — customers who attempted to renew but their payment failed

The Reconciliation Method

The core verification process is reconciliation:

Payment Processor ↔ Accounting Records ↔ Bank Deposits

These three independent sources should align within explainable differences. Legitimate reasons for variance include:

• Payment timing — a charge on the last day of the month may settle in the next month
• Processor fees — Stripe deducts fees before payout; gross revenue exceeds bank deposits
• Refunds — recorded in processor data but may not appear in P&L if improperly excluded
• Chargebacks — disputed charges may take weeks to resolve
• Currency conversion — international payments introduce exchange-rate differences
• Accounting treatment — revenue may be recognized on an accrual basis rather than cash
• Deferred revenue — annual prepayments recognized monthly over the subscription term

Screenshots are not evidence. A screenshot shows only what the seller chose to display at one moment. It can omit unfavorable data, crop out relevant context, or be taken before adverse events occurred. Always request raw exports, API access, or read-only dashboard access where the platform supports it.

MRR and ARR Verification: Beyond the Headline Number

Monthly Recurring Revenue is the most cited metric in SaaS acquisition, and the most frequently manipulated. MRR should represent the monthly value of recurring subscription contracts. But sellers define MRR inconsistently, and buyers who accept a headline MRR without deconstruction are asking for trouble.

The MRR Bridge

MRR is not a static number. It changes every month through customer acquisitions, expansions, contractions, and churn. A proper MRR bridge shows the flow:

MRR Component	Definition	Example
Beginning MRR	MRR at the start of the period	$20,000
+ New MRR	MRR from brand-new customers	+$3,000
+ Expansion MRR	MRR from existing customers upgrading	+$1,500
− Contraction MRR	MRR lost from downgrades	−$800
− Churned MRR	MRR lost from cancellations	−$1,200
Ending MRR	The resulting MRR at period end	$22,500

A seller who reports MRR without this bridge may be hiding churn behind new customer acquisition, masking negative trends behind positive headline numbers.

Why ARR = MRR × 12 Can Be Misleading

Annual Recurring Revenue is often presented as MRR multiplied by twelve. This simplification works only when every subscription is monthly and stable. Reality is messier:

• Annual plans — a customer paying $1,200/year has $100 MRR but $1,200 ARR; the ARR is collected upfront but recognized over time
• Prepaid contracts — cash is received before service delivery; deferred revenue is a liability
• Usage-based SaaS — revenue varies month to month; MRR is an approximation
• Enterprise contracts — may include fixed fees, variable fees, implementation, and SLAs
• Discounts — a “list price” ARR may not reflect what customers actually pay
• Free accounts — users who do not pay should not appear in MRR calculations
• Unpaid invoices — booked revenue that has not been collected
• Promotional pricing — temporarily discounted subscriptions that inflate MRR

Revenue Quality: Scoring What You’re Actually Buying

Revenue quality is not a binary — good or bad. It is a spectrum. Two SaaS businesses can each report $20,000 MRR, yet one is dramatically more valuable than the other because its revenue is higher quality: more predictable, more diversified, more profitable, and more transferable.

Evaluate revenue along these dimensions:

Dimension	High Quality	Low Quality
Recurring vs. Non-Recurring	Nearly all revenue is from repeatable subscriptions	Large share from one-time fees, consulting, LTDs
Predictable vs. Volatile	MRR varies <5% month to month	MRR swings 20%+ month to month
Diversified vs. Concentrated	No single customer >5% of revenue	Top 3 customers >50% of revenue
Organic vs. Promotion-Driven	Customers acquired through content, SEO, referrals	Heavy discounts, paid ads with negative ROI, founder network
Contractual vs. Month-to-Month	Annual or multi-year contracts with renewal terms	No contracts; customers can leave anytime
Expanding vs. Shrinking	Expansion MRR > contraction MRR	Contraction and churn outpace expansion
High-Margin vs. Low-Margin	Gross margin >80%	Gross margin <50% due to API/AI/hosting costs

Conceptual Revenue Quality Score: Assign each dimension a score from 1 (low) to 5 (high) and calculate an average. A SaaS scoring below 3.0 on average should prompt a deeper investigation into whether the revenue is durable enough to justify the asking price.

Profitability and Cash Flow: Normalized, Not Reported

A SaaS can report profit and still be a poor acquisition. The seller’s profit calculation may exclude costs that you will inevitably incur. It may include add-backs that are not genuine. It may reflect a period when the founder worked for free or when infrastructure was underpriced. Your job is to calculate the profit you will earn after acquisition, not the profit the seller reported.

Key Metrics to Recalculate

• Gross profit — revenue minus direct costs of delivering the product (hosting, APIs, payment fees, support tooling)
• Gross margin — gross profit divided by revenue, expressed as a percentage
• Operating expenses — salaries, marketing, software subscriptions, office, legal, accounting
• EBITDA/SDE — earnings before interest, taxes, depreciation, amortization; or Seller’s Discretionary Earnings for smaller businesses
• Owner compensation — what the founder paid themselves; may not reflect market rate for a replacement
• Cash flow — actual money that moved through the business, not accounting profit
• Working capital — the cash required to operate between paying expenses and collecting revenue
• Infrastructure expenses — cloud hosting, database, CDN, monitoring, error tracking
• Support expenses — help desk software, customer support labor, response tools
• API costs — third-party API fees that scale with usage
• Payment fees — Stripe/PayPal processing charges, typically 2.9% + fixed fee

Post-Acquisition Normalized Profit

Start with the seller’s reported profit. Then adjust for every expense that will look different after acquisition:

• If the founder worked without salary, add a market-rate salary for the role you will need to fill or perform
• If the product runs on the founder’s personal cloud account, add the cost of dedicated infrastructure
• If customer support was handled personally by the founder, add the cost of a support hire or tooling
• If the codebase requires a developer to maintain, add the cost of ongoing technical support
• If the seller used free tiers of services, add the cost of paid plans as the business grows
• If the seller’s marketing was personal outreach, add the cost of a repeatable acquisition channel
• If the seller accepted payment through a personal account, add the cost of a business payment processor

The resulting number is your Post-Acquisition Normalized Profit. This is what you should use for valuation, not the seller’s reported figure.

Add-Backs: The Seller’s Profit Inflation Tool

Sellers often present “Seller’s Discretionary Earnings” or adjusted EBITDA that includes add-backs — expenses the seller claims are non-recurring, personal, or discretionary and should therefore be added back to profit. Some add-backs are legitimate. Many are not.

For every add-back claimed, ask these questions:

• Is it genuine? — Does the expense actually exist, or is it an estimate?
• Is it documented? — Can the seller produce receipts, invoices, or bank records?
• Is it actually non-recurring? — Or does it occur every year, just at irregular intervals?
• Will the buyer need to spend it? — Some “non-recurring” expenses are actually recurring for a new owner
• Is it personal? — Personal expenses mixed into business accounts are a red flag, not a legitimate add-back
• Is it discretionary? — Could the seller have avoided it without harming the business?
• Has it historically occurred repeatedly? — If it happens every year, it is not non-recurring

Aggressive add-backs can make a SaaS appear significantly more profitable than it actually is. A seller might add back legal fees, one-time contractor payments, server migration costs, conference expenses, and “personal development” — many of which will recur under new ownership in some form. Treat every add-back with skepticism until independently verified.

Customer Due Diligence: The Individual View

A SaaS business is not a single entity; it is a collection of individual customer relationships. Total customer count is a poor proxy for business health. A business with 500 customers may be stronger than one with 2,000 customers if the 500 are stable, engaged, and profitable while the 2,000 are churning constantly.

What to Request

Request a customer-level dataset where legally and practically appropriate. For each customer, the dataset should include:

• Customer ID (anonymized if necessary for privacy)
• Signup date
• Plan or pricing tier
• Monthly or annual billing amount
• Contract start and end dates
• Renewal date
• Geographic location
• Acquisition source (how the customer found the product)
• Payment status (current, past due, paused)
• Churn status (active, churned, reactivated)
• Expansion or contraction history (upgrades, downgrades)

How to Analyze

Do not simply look at the total count. Segment the customer base and examine each segment:

• Which customers produce the most revenue?
• Which customers have been active the longest?
• Which acquisition sources produce the best and worst customers?
• Which plans have the highest churn rates?
• Which customers have failed payments repeatedly?
• Which customers have requested refunds or filed disputes?
• Are there patterns in churn by geography, plan tier, or signup cohort?

Customer Concentration: The Hidden Fragility

Customer concentration measures how much of the business depends on a small number of customers. A SaaS where the top 3 customers represent 60% of revenue is fundamentally more fragile than a SaaS where the top 10 customers represent 15%.

Analyze concentration across multiple dimensions:

• Top 1 customer — What percentage of MRR does the single largest customer represent?
• Top 5 customers — What percentage do the top 5 represent cumulatively?
• Top 10 customers — What percentage do the top 10 represent?
• Enterprise concentration — How many customers are enterprise contracts vs. self-serve?
• Channel concentration — Do most customers come from one referral source, partner, or affiliate?
• Geographic concentration — Are most customers in one country or region subject to specific regulatory or economic risk?

There is no universal “safe” percentage. A single customer representing 3% of revenue is generally acceptable. A single customer representing 25% should trigger a deep review of that customer’s contract, relationship, renewal likelihood, and the founder’s personal involvement in that relationship. A top 5 representing 70% means the business is effectively a portfolio of five accounts, not a diversified SaaS.

Churn, Retention, GRR and NRR: The Metrics That Matter

What is it?

Churn measures how much revenue or how many customers the business loses over a period. Retention is the inverse — how much it keeps. But not all churn and retention metrics are equivalent, and sellers often report the most favorable definition.

Key Metrics Defined

• Customer/Logo Churn — percentage of customers who cancel in a period
• Revenue Churn — percentage of revenue lost from cancellations in a period
• Gross Revenue Churn — revenue lost from cancellations and downgrades, before expansion
• Gross Revenue Retention (GRR) — percentage of existing revenue retained, excluding expansion
• Net Revenue Retention (NRR) — percentage of existing revenue retained after accounting for expansion and contraction

Formulas

Metric	Formula
Customer/Logo Churn	(Customers lost in period) ÷ (Customers at start of period) × 100
Gross Revenue Churn	(MRR lost to churn and downgrades) ÷ (MRR at start of period) × 100
GRR	(Starting MRR − Churned MRR − Contraction MRR) ÷ Starting MRR × 100
NRR	(Starting MRR + Expansion MRR − Churned MRR − Contraction MRR) ÷ Starting MRR × 100

Ask the seller: “What exactly do you mean when you say churn is 2%?” Is that customer churn or revenue churn? Is it monthly or annual? Does it include downgrades? Does it exclude customers who downgraded to a free plan? Does it exclude customers who failed payment but never formally canceled? The definition matters as much as the number.

What to do if something is wrong: If the seller cannot clearly define their churn metric or the raw data does not support the reported rate, treat retention as unverified and adjust valuation downward. Poor retention is one of the most common causes of post-acquisition SaaS failures.

Cohort Analysis: Seeing Through Averages

Averages hide important information. An overall retention rate of 90% may sound healthy, but if the most recent customer cohorts retain at only 70% while legacy cohorts retain at 98%, the business is deteriorating. Cohort analysis groups customers by the month they signed up and tracks retention over time for each group.

Sample Cohort Table

Signup Month	New Customers	Month 1	Month 2	Month 3	Month 4	Month 5	Month 6
January 2025	50	96%	94%	92%	90%	88%	86%
February 2025	45	94%	91%	89%	86%	84%	—
March 2025	60	91%	87%	83%	80%	—	—
April 2025	55	88%	83%	78%	—	—	—
May 2025	70	85%	79%	—	—	—	—

In this example, the overall retention rate may still look acceptable, but the pattern is clearly deteriorating. Customers acquired in January 2025 retained at 86% after six months. Customers acquired in May 2025 retained at only 79% after two months. If this trend continues, future cohorts will retain significantly worse than legacy cohorts, and the business will slowly bleed revenue even if the headline MRR looks stable.

Cohort analysis can also reveal the opposite: improving retention. If recent cohorts retain better than legacy cohorts, the product may be improving or the acquisition channels may be attracting better-fit customers. This is a positive signal that supports the investment thesis.

Customer Interviews: Validating Reality, Not Collecting Testimonials

Customer interviews are a powerful due diligence tool when used correctly. The purpose is not to collect positive testimonials — the seller can already provide those. The purpose is to validate revenue quality, understand the customer’s reliance on the product, and identify risks that the seller may not have disclosed.

When to conduct interviews: during full due diligence, after you have reviewed customer-level data and identified key accounts, segments, and patterns. Interviews should be conducted with the seller’s permission and typically with the seller facilitating introductions.

Practical Questions

• Why did you originally purchase this product?
• What problem does the product actually solve for your business?
• What alternatives did you consider before choosing this product?
• What would make you leave this product and choose a competitor?
• Which feature is most important to your daily workflow?
• What is missing from the product that you wish existed?
• How important is the product to your business operations?
• How would a 10% or 20% price increase affect your decision to stay?
• Would you continue using the product after an ownership change?
• Have you had any support issues or reliability problems?
• How did you originally find this product?
• How frequently do you actually use the product?

Red flags in customer interviews: Customers who say the product is “nice to have” rather than “essential”. Customers who say they have considered leaving. Customers who express concerns about product direction. Customers who say they only stay because of the founder’s personal relationship. Customers who mention pricing sensitivity. These signals suggest revenue quality is weaker than the numbers suggest.

Customer Contracts: The Legal Reality Behind the Revenue

Not every SaaS customer signs a formal contract. Many self-serve SaaS products rely on click-through terms of service rather than individually negotiated agreements. But when contracts exist — especially for enterprise customers — they must be reviewed carefully.

Review these contract types where applicable:

• SaaS agreements or terms of service
• Master service agreements (MSAs)
• Enterprise agreements
• Data processing agreements (DPAs)
• Reseller agreements
• Partnership agreements
• Affiliate agreements
• Service level agreements (SLAs)

Critical clauses to review:

• Assignment restrictions — can the contract be transferred to the buyer without customer consent?
• Change-of-control clauses — does an acquisition trigger termination rights for the customer?
• Termination rights — can the customer cancel at any time, or only at specific renewal dates?
• Renewal conditions — are renewals automatic, and on what terms?
• Pricing commitments — are prices locked in for the contract duration?
• Service-level obligations — what uptime, support, or response guarantees has the seller promised?
• Indemnities — does the seller indemnify the customer against IP infringement or data breaches?
• Warranties — what promises has the seller made about product functionality?
• Exclusivity — is the customer prohibited from using competing products?
• Minimum commitments — is the customer contractually obligated to pay a minimum amount?

An apparently valuable customer may become risky if the contract cannot be transferred, if a change-of-control clause allows termination upon acquisition, or if the seller has made contractual commitments that the buyer cannot realistically meet.

Product Due Diligence: Separating Value from Vanity

A SaaS product is only as valuable as its actual utility to customers. Vanity metrics — total signups, page views, app downloads — do not tell you whether the product solves a real problem that customers will pay to solve.

What to Assess

• Product-market fit — do customers use the product regularly and would they be upset if it disappeared?
• Active users — what percentage of paying customers actually use the product weekly?
• Engagement — how frequently do users log in, take key actions, or generate output?
• Activation — what percentage of signups become active, paying customers?
• Onboarding — can new customers get value from the product without extensive support?
• Trial conversion — what percentage of trial users convert to paid?
• Paid conversion — what percentage of free users eventually pay?
• Feature adoption — which features are actually used vs. merely present?
• Support volume — how many support tickets per customer per month? Is the product self-serve?
• Error rates — how often does the product fail or behave unexpectedly?
• Uptime — what is the historical availability? Are there repeated outages?
• Product complaints — what do customer reviews, support tickets, and feedback reveal?

Red flags: High signup volumes with low activation. Large numbers of free users who never convert. Customers who pay but rarely use the product. Frequent support tickets for basic functionality. A product roadmap that has been stagnant for months. These suggest the product is not delivering genuine value, and revenue may be fragile.

Technical Due Diligence: What’s Under the Hood

Technical due diligence is the process of determining whether the technology that powers the SaaS is sound, maintainable, scalable, and actually owned by the seller. This is not a casual review — it requires a qualified technical expert who can read code, assess architecture, and evaluate infrastructure.

What to Review

• Architecture — how is the application structured? Monolith vs. microservices? Clean separation or spaghetti code?
• Frontend — what framework, build system, and UI libraries are used? Is the code maintainable?
• Backend — what language, framework, and API design? Is the logic clean and documented?
• Database — what database system, schema design, indexing, and data model? Are there obvious inefficiencies?
• APIs — internal and external API design. Are there undocumented dependencies?
• Queues and workers — background processing, cron jobs, scheduled tasks. Are they reliable?
• Authentication — how are users authenticated? Are credentials stored securely?
• Authorization — how is access control implemented? Can users access data they should not?
• Deployment — how is code deployed? Is the process automated or manual?
• CI/CD — is there continuous integration and deployment? Or does the founder deploy manually?
• Monitoring — what monitoring is in place? Will you know when something breaks?
• Logging — are errors logged and searchable? Can you debug production issues?
• Backups — is data backed up? Are backups tested?
• Disaster recovery — what happens if the primary server or database fails?
• Scalability — can the product handle 2x, 5x, or 10x current load?
• Technical debt — what legacy code, outdated dependencies, or architectural compromises exist?

Source Code Due Diligence: The Repository Tells the Truth

The source code repository is one of the most revealing sources of evidence in a SaaS acquisition. It shows what was actually built, who built it, when it was built, how it was built, and — critically — whether the seller actually owns the code.

What to Request Access To

• GitHub, GitLab, or Bitbucket repository access (read-only)
• Complete commit history
• Pull request and merge request history
• Branch structure
• Issue tracker
• Deployment configuration
• CI/CD configuration
• Dependency manifest files

What to Inspect

• Code quality — is the code readable, modular, and well-structured, or is it a tangle of copy-paste and dead ends?
• Documentation — is there any documentation beyond the code itself?
• Tests — are there unit tests, integration tests, or end-to-end tests? What is the coverage?
• Dependency management — are dependencies pinned, audited, and updated?
• Security issues — any hard-coded credentials, API keys, or secrets in the repository?
• Technical debt — abandoned modules, commented-out code, TODO markers that have persisted for months
• Single-developer dependency — has one person written essentially all of the code?
• Contribution patterns — when was the last commit? Is the code actively maintained or in maintenance mode?

Why Git History Matters

Current code alone is insufficient. The Git history can reveal:

• Who actually wrote the code — employees, contractors, or the founder personally
• When development activity slowed or stopped
• Whether the codebase was recently rewritten (a sign of technical crisis)
• Whether critical features were built by contractors whose IP assignments may be missing
• Whether security fixes were applied promptly or ignored
• Whether the repository contains third-party code copied without proper licensing

Infrastructure Due Diligence: Mapping the Stack

The infrastructure is the physical and cloud foundation on which the SaaS runs. Map the complete stack from domain to database:

Domain → DNS → CDN → Load Balancer → Application → Database → Storage → Queues → APIs → Monitoring → Backups

What to Verify

• Account ownership — who controls the cloud accounts, DNS, domain registrar, and CDN accounts?
• Credentials — can the seller provide access credentials and transfer them securely?
• Monthly costs — what is the actual spend on AWS, Google Cloud, Azure, Cloudflare, or other providers?
• Production environments — is there a clear separation between production and development?
• Backups — are backups automated, tested, and retrievable?
• Restoration procedures — has the seller ever tested restoring from backup?
• Undocumented services — are there any external services, cron jobs, or scripts running outside the documented stack?
• Single points of failure — is there any component whose failure would bring down the entire product?

Red flags: The seller cannot identify where the application is hosted. The seller uses a personal cloud account. There is no backup. Backups exist but have never been tested. There is no monitoring or alerting. The infrastructure cost is not documented.

Cloud Cost Analysis: The Margin Eroder

Cloud costs are a critical but frequently overlooked part of SaaS profitability. A product that generates $50,000 in monthly revenue but spends $25,000 on cloud infrastructure has a gross margin problem that may be hidden in the seller’s P&L.

Analyze costs across:

• AWS, Google Cloud, Azure compute and storage
• Database hosting
• CDN and bandwidth
• External API costs
• AI inference costs (for AI-powered SaaS)
• Monitoring and logging services
• Error tracking tools
• Email delivery services
• Search services

The Key Ratio

Infrastructure Cost ÷ Revenue = Infrastructure Cost Ratio

A healthy SaaS typically keeps infrastructure costs below 10–15% of revenue. A SaaS with infrastructure costs above 25% has a structural profitability problem. Above 40%, the business may be fundamentally uneconomical.

Watch for: Sudden cost spikes that are not reflected in revenue growth. Costs that scale faster than revenue. AI inference costs that grow with usage but are not priced into subscription fees. Reserved instances or committed infrastructure that will outlive the acquisition.

Cybersecurity Due Diligence: The Risk You Cannot See

A SaaS business is a target for attack. Customer data, payment information, intellectual property, and the application itself are all valuable. A security vulnerability discovered after acquisition can destroy customer trust, trigger legal liability, and reduce the business’s value to zero.

What to Review

• Authentication — how are user accounts protected? Is MFA available and enforced where appropriate?
• Authorization — can users access data they should not? Are there privilege escalation vulnerabilities?
• Secrets management — are API keys, database credentials, and service accounts stored securely or hard-coded?
• Encryption — is data encrypted in transit and at rest where appropriate?
• Production access — who has access to production systems? Is access audited?
• Employee access — do former employees or contractors still have access credentials?
• Logging — are security-relevant events logged?
• Monitoring — is there security monitoring or intrusion detection?
• Vulnerability management — are dependencies scanned and updated for security patches?
• Backups — are backups encrypted and protected from ransomware?
• Incident response — has the seller experienced security incidents? How were they handled?
• Breach history — has the product ever been breached? If so, what was the impact?
• Penetration testing — has the product ever been professionally tested?
• Dependency vulnerabilities — are third-party dependencies up to date and free of known vulnerabilities?

What to do if a serious security problem is discovered: Do not close the deal until the issue is remediated, a remediation plan is agreed upon, or the valuation is adjusted to reflect the cost and risk of fixing the problem. Security issues discovered during due diligence may also trigger disclosure obligations under data protection laws, so consult legal counsel.

Open-Source Software and Dependency Audit: The Legal Code Inside Your Code

Nearly every SaaS codebase includes open-source software. Open-source is not a problem — it is a standard practice. But the licenses attached to open-source components can create legal and operational obligations that a buyer must understand.

What to audit:

• Open-source licenses — MIT, Apache, GPL, LGPL, AGPL, BSD, and others. Some require that derivative works be open-sourced.
• Dependency inventory — a complete list of all third-party libraries and packages used in the codebase
• Vulnerable packages — dependencies with known security vulnerabilities
• Abandoned libraries — dependencies that are no longer maintained and may break or create security risks
• Commercial licenses — third-party commercial components that require paid licenses that may not transfer
• License compatibility — whether the combination of licenses used in the codebase is legally compatible
• SBOM — a software bill of materials, which is increasingly required by enterprise customers and regulators
• Package provenance — where packages were sourced from, and whether any have been modified

Why it matters: A GPL-licensed component embedded in the codebase could require the entire SaaS to be open-sourced under certain interpretations. A commercial license that does not transfer could expose the buyer to additional fees or legal action. Vulnerable packages could be exploited post-acquisition. An SBOM may be required by enterprise customers who demand security compliance.

Intellectual Property Due Diligence: Do You Actually Own What You’re Buying?

Intellectual property is the core asset of a SaaS business. If the seller does not actually own the IP, the buyer is purchasing an illusion. This is one of the most common — and most expensive — due diligence failures in SaaS acquisitions.

IP categories to verify:

• Source code — who wrote it, under what terms, and with what IP assignment?
• Trademarks — is the product name registered? Who owns the registration?
• Domain name — who is the registrant? Is the domain transferable?
• Logo and brand assets — who created them? Are the rights assigned?
• Content — documentation, blog posts, tutorials, marketing materials — who wrote them?
• Designs — UI/UX designs, graphics, icons — who created them?
• Databases — proprietary data, customer datasets, curated content
• Algorithms — proprietary logic, ranking systems, scoring models
• Documentation — internal documentation that enables operation of the product
• Datasets — training data, customer behavior data, aggregated analytics
• APIs — public and internal API designs and specifications
• Proprietary workflows — unique processes or configurations that make the product work

“I paid for the code” does not automatically mean “I legally own the code.”

A seller may have paid a freelancer to build the product, but if the freelancer’s contract did not include an IP assignment clause, the freelancer may still own the copyright. A seller may have used a template, framework, or component under license that does not permit transfer. A seller may have incorporated open-source code with a viral license that contaminates the proprietary codebase.

Contractor IP Ownership: The Silent Deal Breaker

Most SaaS products are built with significant contractor or freelancer involvement. The legal principle in most jurisdictions is that the creator of a work owns the copyright unless there is a written agreement assigning those rights to the company. Without a proper IP assignment, the contractor — not the seller — owns the code, design, or content they created.

For every developer, designer, writer, consultant, and contractor who contributed to the product, ask:

• Who created the work?
• When was the work created?
• Under what contract or agreement?
• Does the contract contain an IP assignment clause?
• Are moral rights addressed where relevant?
• Were subcontractors involved, and if so, do their agreements also include IP assignment?
• Was third-party code, templates, or assets used that may carry separate licensing obligations?

What to do if IP assignments are missing: Missing IP assignments are a potential deal blocker. You cannot safely acquire a business where a former contractor could later assert ownership of critical code or design. At minimum, the seller must obtain retroactive IP assignments from every contractor before closing. If they cannot, the value of the IP is impaired, and the deal should be renegotiated or abandoned.

Domain, Trademark and Brand Ownership

The domain name is the digital address of the business. The trademark is the legal identity. The social accounts are the public presence. All must be owned by the entity you are acquiring and must be transferable to you.

What to Verify

• Domain registrar — which registrar holds the domain registration?
• Domain account owner — who is the legal registrant? The seller personally or the company?
• Trademark ownership — are there registered trademarks? Who owns them? Are they in the correct jurisdiction?
• Pending applications — are there trademark applications in progress that may not be approved?
• Social accounts — who controls the Twitter/X, LinkedIn, Facebook, YouTube, and other social accounts?
• Brand assets — are the logo, brand guidelines, and design files documented and transferable?
• Email accounts — who controls the email infrastructure and mailing lists?

Transferability: A domain registered in the seller’s personal name may be difficult to transfer. A trademark registered in the founder’s name rather than the company’s name requires a separate assignment. Social accounts controlled by a founder’s personal email may be lost if the founder is uncooperative after acquisition.

AI-Specific Due Diligence: The 2026 Imperative

As of 2026, a significant share of SaaS products incorporate AI capabilities. AI introduces a new dimension of due diligence that traditional SaaS checklists do not cover. An AI-powered SaaS carries dependencies, costs, and legal obligations that a conventional SaaS does not.

What to Investigate

• AI API providers — which providers does the product depend on? OpenAI, Anthropic, Google, Meta, custom models?
• Model dependencies — which specific models are used? Are they available long-term?
• API pricing — what do the AI API calls cost? How does pricing scale with usage?
• Rate limits — are there limits on API calls that could restrict the product’s operation?
• Model availability — is the model version guaranteed to remain available, or could it be deprecated?
• Model switching — can the product switch between AI providers, or is it locked into one?
• Prompts — are the prompts proprietary? Are they documented? Can they be transferred?
• Fine-tuned models — are there fine-tuned models? Who owns them? Can they be exported?
• Embeddings — are embeddings stored? Are they portable?
• Vector databases — which vector database is used? Is the data portable?
• Training datasets — what data was used for fine-tuning or RAG? Is the data legally acquired?
• User data — is user data used to train AI models? Is that disclosed to users?
• Generated output — who owns the AI-generated output? Are there copyright implications?
• Third-party AI terms — do the AI providers’ terms permit commercial use and resale?
• AI infrastructure cost — what is the actual cost of AI inference, storage, and vector search?

“If the primary AI provider doubles its price or changes its terms, does the SaaS remain economically viable?”

AI costs are variable and can scale non-linearly. A SaaS that charges $30/month per user but consumes $15/month in AI inference costs has a gross margin problem that may not be visible in a traditional P&L. Model deprecation, API pricing changes, and provider terms updates are all risks that must be priced into the valuation.

Data and Privacy: The Invisible Liability

A SaaS business collects, stores, and processes data about its customers and their users. That data carries legal obligations under privacy regulations such as GDPR, CCPA, and other applicable frameworks. The obligations do not disappear when the business is sold — they transfer to the buyer.

What to Review

• Personal data — what personal data does the product collect and process?
• Sensitive data — any health, financial, biometric, or special-category data?
• Storage — where is data stored? Which jurisdictions? Which cloud providers?
• Retention — how long is data kept? Is there a documented retention policy?
• Deletion — can users request data deletion? Is that honored?
• Access — who has access to customer data? Employees? Contractors? Third-party subprocessors?
• Subprocessors — which third parties process customer data on behalf of the SaaS?
• International transfers — is data transferred across jurisdictions? Are appropriate safeguards in place?
• Privacy policies — is the privacy policy accurate, complete, and consistent with actual practice?
• DPAs — are there data processing agreements with customers where legally required?
• Customer data obligations — what have customers been promised regarding their data?

Privacy and data protection laws vary significantly by jurisdiction. GDPR applies to EU data subjects regardless of where the business is located. CCPA/CPRA applies to California residents. Other jurisdictions have their own regimes. Do not assume that one set of rules applies universally. Professional legal review is essential.

Legal Due Diligence: What Survives the Acquisition

Legal due diligence focuses on liabilities that may survive the acquisition. When you buy a business — depending on the transaction structure — you may inherit its debts, lawsuits, contractual obligations, employment disputes, IP problems, and regulatory violations.

What to Review

• Incorporation documents — is the company properly formed and in good standing?
• Ownership records — who actually owns the company shares or equity?
• Cap table — are there other shareholders, option holders, or convertible securities?
• Shareholder agreements — are there voting restrictions, right of first refusal, or transfer restrictions?
• Debts — outstanding loans, credit lines, or financial obligations
• Liens — any security interests or encumbrances on company assets
• Lawsuits — current or threatened litigation, arbitration, or regulatory action
• Disputes — unresolved disputes with customers, vendors, employees, or partners
• Employment contracts — obligations to employees, including severance and benefits
• Contractor contracts — outstanding obligations to contractors
• Customer contracts — obligations and liabilities to customers
• Vendor contracts — commitments to vendors and service providers
• IP records — registrations, assignments, and licensing agreements
• Privacy obligations — privacy policies, data processing agreements, and regulatory registrations
• Regulatory obligations — any industry-specific regulatory requirements
• Insurance — what insurance coverage exists, and can it be transferred?

Corporate Structure: Asset Purchase vs. Share Purchase

The transaction structure determines what you are actually buying and what liabilities you inherit. The two fundamental structures are:

Asset Purchase

You buy specific assets — the source code, domain, customer contracts, trademarks, equipment, and goodwill — but not the company entity itself. The seller’s entity retains its debts, lawsuits, and most liabilities. Asset purchases are generally cleaner for the buyer but may trigger tax consequences and may require customer consent for contract transfers.

Share/Equity Purchase

You buy the company entity itself, including all its assets and all its liabilities. This structure may be required for certain contracts, licenses, or tax attributes, but it means you inherit everything — known and unknown.

The choice of structure is jurisdiction-specific and tax-dependent. Do not make this decision without qualified legal and tax advice.

Tax Due Diligence: The Obligations That Follow You

Tax liabilities can survive an acquisition and attach to the buyer. A SaaS business may have obligations across multiple jurisdictions depending on where it is incorporated, where its customers are located, and where its employees or contractors work.

What to Review

• Corporate taxes — income tax, corporation tax, or equivalent in the relevant jurisdiction
• Sales tax — US sales tax, including nexus in multiple states
• VAT — value-added tax obligations in EU and other jurisdictions
• GST — goods and services tax in applicable jurisdictions
• Payroll taxes — employer obligations for any employees
• Tax registrations — where is the business registered for tax purposes?
• Outstanding liabilities — unpaid taxes, penalties, or interest
• Tax audits — has the business ever been audited? What was the outcome?
• Nexus obligations — does the business have tax nexus in jurisdictions where it has not registered?

Tax obligations are highly jurisdiction-specific. What applies to a US-based SaaS selling to US customers is different from a UK-based SaaS selling to EU customers. Professional tax advice is essential.

Employees and Contractors: The People Risk

A SaaS business is only as strong as the people who operate it. If the critical employee or contractor leaves after acquisition, the buyer may be left with a codebase no one understands and customers no one can support.

What to Analyze

• Employees — how many, what roles, what salaries, what benefits?
• Contractors — who are they, what do they do, what are they paid?
• Tenure — how long have key people been with the business?
• Key-person risk — who is indispensable, and what happens if they leave?
• IP assignments — do all employees and contractors have signed IP assignment agreements?
• Employment agreements — what terms, severance, and restrictions apply?
• Contractor agreements — are they current, enforceable, and transferable?
• Retention risk — will key people stay after acquisition? What incentives exist?

What to do if key people are at risk of leaving: Build retention into the transaction structure. Consider retention bonuses, transition agreements, earn-outs, or consulting arrangements. If the business depends on one person who will not stay, the acquisition value is significantly impaired.

Founder Dependency: The Risk You Cannot Fully Eliminate

Founder dependency is one of the most common — and most underappreciated — risks in SaaS acquisition. The founder may personally control every critical function of the business:

• Coding — the founder may be the only person who understands the codebase
• Sales — the founder may be the only person who can close deals
• Customer support — the founder may answer every support ticket personally
• Marketing — the founder may write all the content and manage all campaigns
• Product management — the founder may be the only person who knows the roadmap
• Infrastructure — the founder may control all cloud accounts, domains, and credentials
• Billing — the founder may handle invoices, renewals, and collections
• Partnerships — the founder may have personal relationships with key partners
• Hiring — the founder may be the only one who knows what roles are needed
• Customer relationships — enterprise customers may be loyal to the founder personally

“If the founder disappeared tomorrow, could the buyer operate the SaaS?”

Founder dependency affects valuation, transition requirements, seller financing terms, earn-out structures, and hiring needs. A business with high founder dependency should be priced lower, should include a longer transition period, and should require the founder to document processes and train the buyer before closing.

Operations Due Diligence: Can You Actually Run This?

A SaaS may have excellent revenue, solid code, and loyal customers — but if the operations are entirely in the founder’s head, the buyer cannot run it. Operations due diligence asks: can you actually operate this business after acquisition?

What to Review

• SOPs — standard operating procedures. Are they documented or in the founder’s memory?
• Onboarding — how are new customers onboarded? Can someone else do it?
• Support — what is the support process? Ticketing system? Response time? Escalation path?
• Refunds — how are refunds processed? Who approves them?
• Deployment — how is code deployed to production? Is it automated or manual?
• Incident response — what happens when something breaks? Is there a documented process?
• Sales — how are leads generated, qualified, and closed?
• Marketing — what marketing activities are ongoing, and who manages them?
• Billing — how are invoices generated, sent, and collected?
• Customer success — how are existing customers supported and retained?

The Customer Journey Map

Lead → Signup → Activation → Payment → Onboarding → Usage → Support → Renewal → Expansion

Map each step. Identify who performs it, what tools they use, what documentation exists, and what happens if that person leaves. Undocumented processes are a risk factor.

Marketing Due Diligence: How Customers Actually Arrive

A SaaS with high revenue but no repeatable marketing engine is dependent on the founder’s personal network or a single channel that could disappear. Marketing due diligence examines how customers actually arrive — and whether that process will continue after acquisition.

Channels to Analyze (12–24 months where possible)

• Organic search — what keywords drive traffic? Are rankings stable?
• Paid advertising — what channels? What is the ROI? What is the CAC?
• Social media — which platforms? What engagement? What conversion?
• Referrals — do existing customers refer new ones? Is there a program?
• Affiliates — are there affiliate partners? What do they cost?
• Partnerships — do other companies refer customers? What are the terms?
• Email marketing — is there a list? What are open and click rates?
• Direct traffic — how many visitors arrive by typing the domain directly?

Watch for: Sudden traffic spikes that are not explained by a clear cause. Traffic that does not convert into customers. Paid advertising with negative ROI that the seller continues to run. Dependence on a single social media account or platform that could change its algorithm.

SEO Due Diligence: The Traffic Engine

For many SaaS businesses, organic search traffic is the primary customer acquisition channel. SEO due diligence examines whether that traffic is sustainable, owned, and resistant to algorithm changes.

What to Review

• Google Analytics — traffic volumes, sources, user behavior, conversion rates
• Search Console — search queries, impressions, clicks, average position
• Organic traffic — how much traffic comes from organic search vs. paid vs. other sources?
• Top pages — which pages attract the most search traffic? Which convert?
• Keywords — which keywords drive traffic? Are they branded or non-branded?
• Backlinks — what links point to the domain? Are they from quality sources?
• Ranking trends — are rankings stable, improving, or declining?
• Algorithm changes — has the site been affected by Google algorithm updates?
• Branded vs. non-branded traffic — branded searches indicate awareness; non-branded indicates discoverability
• Content ownership — who wrote the content? Are the rights assigned?
• Manual actions — has the site been penalized by Google?
• SEO dependency — if organic traffic dropped 50%, what would happen to revenue?

Stress test: Model the business if organic traffic declines by 30%, 50%, or more. If the business cannot survive a significant SEO decline, it is over-dependent on a single channel that is outside your control.

Sales and Customer Acquisition: The Engine of Growth

Customer acquisition is the engine that drives SaaS growth. A business that acquires customers efficiently and repeatably is more valuable than one that acquires customers through the founder’s personal relationships or unsustainable promotions.

Key Metrics to Calculate

• CAC (Customer Acquisition Cost) — total sales and marketing spend divided by new customers acquired
• LTV (Customer Lifetime Value) — average revenue per customer multiplied by average customer lifetime
• LTV:CAC ratio — the relationship between lifetime value and acquisition cost
• CAC payback period — how long it takes for a customer to generate enough revenue to cover the acquisition cost
• Conversion rates — from visit to signup, signup to trial, trial to paid
• Sales cycle length — how long does it take from first contact to closed deal?
• Lead sources — where do qualified leads come from?
• Trial conversion — what percentage of trial users convert to paid?
• Founder-generated sales — what percentage of revenue comes from the founder’s personal network?
• Organic sales — what percentage comes from self-serve or inbound channels?
• Paid acquisition — what percentage comes from paid advertising, and at what ROI?

Why founder-network sales are less transferable: A founder who sells to their personal network is leveraging relationships that the buyer does not have. After acquisition, those relationships may not transfer. A repeatable acquisition system — SEO, paid advertising with proven ROI, a referral program, or a sales team — is more valuable because it can continue without the founder.

Unit Economics: The Math That Determines Survival

Unit economics examines the profitability of a single customer. A SaaS can have high aggregate revenue but lose money on every customer if the cost of serving each customer exceeds what they pay. Understanding unit economics is essential for determining whether the business model is fundamentally sound.

Key components:

• CAC — the cost of acquiring a new customer
• LTV — the total revenue a customer generates over their lifetime
• Gross margin — the profit margin after direct costs of service delivery
• Contribution margin — revenue minus variable costs of serving that customer
• CAC payback — how long it takes to recover the acquisition cost
• Retention — how long customers typically stay
• Expansion — how much existing customers increase their spend over time
• Acquisition efficiency — the relationship between what you spend to acquire and what you earn over time

For AI SaaS specifically: Include variable model/API costs in the gross margin calculation. A SaaS that charges $50/month but spends $20/month on AI inference per customer has a different gross margin profile than a traditional SaaS with minimal variable costs.

Vendor and Third-Party Dependency: The Ecosystem Risk

Every SaaS depends on third-party vendors: cloud providers, email services, payment processors, AI APIs, analytics tools, support platforms, and dozens more. A critical vendor failure or change in terms can disrupt the entire business.

Dependency Table Template

Vendor	Purpose	Monthly Cost	Account Owner	Transferable?	Failure Impact
Example: AWS	Cloud hosting	$2,500	Founder’s personal account	Requires migration	Complete outage
Example: OpenAI API	AI inference	$3,800	Company account	Transferable with credentials	Core feature failure

Every critical vendor should be mapped this way. Pay particular attention to vendors whose accounts are held in the founder’s personal name rather than the company’s name — these will require account transfer or migration.

Hidden Liabilities: What the P&L Does Not Show

Many liabilities do not appear clearly in headline profit figures. A business can show healthy profit while carrying significant obligations that will consume future cash flow or create legal exposure.

Common Hidden Liabilities

• Refunds owed — customers who have requested refunds that have not been processed
• Customer credits — credits issued to customers that reduce future revenue
• Prepaid contracts — annual plans paid upfront; the obligation to serve remains
• Deferred obligations — promises made to customers about future features or services
• Unpaid vendors — outstanding invoices to suppliers and service providers
• Taxes due — unpaid sales tax, VAT, GST, or corporate tax
• Debt — loans, credit lines, or convertible notes
• Chargebacks — disputed charges that may be reversed after acquisition
• Litigation — current or threatened lawsuits
• Security incidents — breaches that have not been disclosed or remediated
• Licensing disputes — disagreements over software licenses or IP rights
• Employee claims — wage disputes, wrongful termination, discrimination claims
• Infrastructure commitments — reserved instances, committed spend, or long-term contracts

Competitive and Market Due Diligence: The External Threat

A SaaS business exists within a competitive and market context. A product that looks strong today may be disrupted tomorrow. Competitive due diligence examines what could make the business significantly less valuable in the future.

What to Analyze

• Direct competitors — products that solve the same problem for the same customers
• Indirect alternatives — different approaches that customers could use to solve the same problem
• Switching costs — how difficult is it for customers to leave and use an alternative?
• Pricing — how does the product’s pricing compare to alternatives?
• Differentiation — what makes this product uniquely valuable?
• Market maturity — is the market growing, stable, or shrinking?
• Market growth — what is the expected growth rate for the product category?
• Platform dependency — does the product depend on a platform that could change its policies (Apple, Google, Shopify, etc.)?
• Commoditization risk — is the product at risk of being commoditized by larger competitors or open-source alternatives?
• Technological disruption — could AI or another technology make the product obsolete?

“What could make this SaaS significantly less valuable three years after acquisition?”

Growth Quality: Not All Growth Is Healthy

Growth is a positive signal, but the quality of growth matters as much as the rate. A business can grow rapidly while becoming weaker — acquiring customers at unsustainably high costs, sacrificing retention for acquisition, or inflating revenue through promotions that will not persist.

Questions to Ask

• Why is revenue growing? Is the driver sustainable or temporary?
• Is growth profitable, or is each new customer acquired at a loss?
• Does growth depend on promotions, discounts, or limited-time offers?
• Is growth driven by acquisition channels that will continue after acquisition?
• Does retention support growth, or is churn offsetting new customer acquisition?
• Are recent customer cohorts retaining better or worse than legacy cohorts?
• Is CAC rising, stable, or declining? Rising CAC with stable pricing is a warning sign.
• Does expansion revenue contribute meaningfully to growth, or is it all new customer acquisition?

There is a difference between growth (the top-line number is increasing) and healthy, repeatable growth (the business is becoming more efficient at acquiring and retaining profitable customers). A professional buyer evaluates the latter.

Seller’s Reason for Selling: A Clue, Not Evidence

Why is the seller selling? The answer matters, but it should never be treated as evidence by itself. A seller can have a perfectly legitimate reason for selling a healthy business, and a seller can have a concerning reason that is well-disguised.

Possible explanations include:

• Founder wants to move on to another project
• Founder wants to retire or reduce workload
• Lack of time or energy to continue
• Burnout
• Personal circumstances (health, family, relocation)
• Capital requirements for another venture
• Plateauing growth
• Declining economics
• Anticipated market or competitive changes

How to test the explanation: Compare the stated reason against the actual data. A seller who claims burnout but is actively developing another product is a different signal than a seller who claims burnout and has not touched the codebase in six months. A seller who claims the business is growing but the cohort data shows declining retention should not be believed simply because the explanation sounds reasonable.

The Data Room: Your Request List

A data room is the collection of documents and records the seller provides for due diligence. The quality and completeness of the data room is itself a signal — a well-organized data room suggests a professional seller; a sparse or disorganized data room suggests hidden problems.

Use this as your actual request list:

Financial

• 24–36 months of P&L statements
• Balance sheets
• Cash-flow statements
• Bank statements for all accounts
• Payment processor raw exports
• Accounting ledger and trial balance
• Tax filings and registrations
• Accounts receivable aging
• Accounts payable
• Refund and chargeback records

Customers

• Customer-level dataset with MRR, signup date, plan, and status
• Cohort retention data
• Customer contracts (all)
• List of top 20 customers by revenue
• Customer churn records
• Support ticket data

Product & Technology

• Source code repository access
• Architecture documentation
• Technical specification
• Deployment configuration
• CI/CD configuration
• Infrastructure documentation
• Cloud account details and costs
• Backup documentation
• Disaster recovery plan
• Dependency inventory

Security

• Security policy documentation
• Penetration test reports (if any)
• Vulnerability scan results
• Incident reports
• Access control documentation
• Encryption practices

IP & Legal

• IP assignment agreements for all contributors
• Contractor and freelancer contracts
• Trademark registrations
• Domain registration records
• Privacy policy and terms of service
• All customer and vendor contracts
• Incorporation documents
• Cap table and shareholder agreements

Operations & People

• SOPs and process documentation
• Employee and contractor list with roles and compensation
• Employment agreements
• Onboarding and support documentation
• Vendor list with contracts and account ownership

Marketing & Analytics

• Google Analytics access
• Search Console access
• Advertising platform reports
• Email marketing platform access
• CRM access
• Historical traffic and conversion data

The Claim → Evidence Table

For every claim the seller makes, you should be able to identify the evidence that would prove it, the independent cross-check that would verify it, and the red flag that would signal a problem.

Seller Claim	Evidence to Request	Independent Cross-Check	Red Flag
$20K MRR	Billing records, subscription exports	Payment processor + accounting + bank	Numbers don’t reconcile
95% retention	Cohort data, churn records	Customer-level billing history	Retention definition unclear
Proprietary code	Repository access, commit history	IP assignment agreements	Missing contractor assignments
100K monthly visitors	Analytics access	Search Console + ad platforms	Traffic spike unexplained
$10K monthly profit	P&L, expense records	Bank statements + normalized costs	Missing or hidden costs
No customer concentration	Customer revenue distribution	Billing data by customer	Top 3 >50% of revenue
No technical debt	Code review, architecture docs	Independent technical audit	Outdated dependencies, no tests
No outstanding liabilities	Legal records, tax filings	Independent legal and tax review	Unpaid taxes, pending disputes

The Three-Way Reconciliation Method

One of the most powerful due diligence strategies is three-way reconciliation. For important claims, compare three independent sources of evidence. When all three agree, confidence is high. When they disagree, something is wrong.

Revenue

Payment Processor ↔ Accounting Records ↔ Bank Deposits

Customers

Billing System ↔ Database ↔ Payment Records

Traffic

Analytics ↔ Search Console ↔ Advertising Platforms

Code

Seller Claims ↔ Git Repository ↔ Production Environment

IP

Seller Claims ↔ Contracts ↔ Official Records

What to do when sources disagree: Disagreement is a finding. It means at least one source is wrong, and possibly more than one. Investigate until you understand the discrepancy. If the seller cannot explain it, treat the claim as unverified. In severe cases, a pattern of unexplained discrepancies across multiple claims is a strong signal to walk away.

The Risk Register: Tracking What You Find

A risk register is a living document that consolidates every finding from due diligence. Each risk is classified, quantified, and assigned a mitigation strategy. The register should be updated continuously throughout the process and used as the basis for valuation adjustments and negotiation.

Column	Description
Finding	What was discovered during due diligence
Evidence	The source that produced the finding
Severity	Low, Moderate, Material, High, or Critical
Probability	How likely is the risk to materialize post-acquisition?
Financial Impact	The monetary consequence if the risk materializes
Operational Impact	The effect on daily operations if the risk materializes
Mitigation	What can be done to reduce the risk or its impact
Negotiation Impact	How the risk should affect the purchase price or deal terms
Deal-Breaker?	Is the risk severe enough to warrant walking away?
Final Decision	The conclusion after considering all factors

Some risks are automatically deal-critical: unclear ownership of critical IP, evidence of fraud, major undisclosed legal exposure, or severe security issues that cannot be remediated. These are not negotiating points — they are reasons to walk away.

Red Flags: The Warning Signs

A red flag is not necessarily a deal killer — it is a signal that something requires deeper investigation. The presence of multiple red flags, or a single critical red flag that cannot be resolved, should cause you to reconsider the acquisition.

Critical Red Flags

• Seller refuses primary records — If the seller will not provide payment processor exports, bank statements, or source code access, assume the claims cannot be verified.
• Only screenshots provided — Screenshots are the weakest form of evidence and are easily manipulated.
• Revenue cannot be reconciled — If three independent sources disagree and the seller cannot explain why, trust nothing.
• Missing IP assignments — If contractors or employees created code without written assignment, the IP chain is broken.
• Founder is sole developer — No one else understands the code; buyer cannot operate the product.
• No backups — Data loss risk that could destroy the business instantly.
• No documentation — Process, architecture, and operations exist only in the founder’s head.
• Security incidents hidden — If the seller concealed a breach, they have concealed other things.
• Legal disputes — Lawsuits, disputes, or regulatory actions that may survive acquisition.
• Unclear ownership — If the seller cannot clearly demonstrate who owns the company, the domain, the code, or the IP.
• Seller rushing closing — Pressure to close quickly is a classic sign of hidden problems.
• Refusal to provide transition assistance — A seller who will not commit to a transition period is signaling that the business will fail without them — or that they know something the buyer does not.

Warning Signs Requiring Investigation

• Unexplained MRR spikes — promotional campaigns, one-time deals, or revenue manipulation
• High customer concentration — top 3 customers >40% of revenue
• Poor recent cohorts — retention declining across successive cohorts
• Unusual refunds — spikes in refund requests before listing the business for sale
• High chargebacks — payment disputes suggesting customer dissatisfaction or fraud
• Undocumented infrastructure — cloud accounts in personal names, unknown services
• Unusual traffic spikes — bought traffic, bot traffic, or unrepeatable promotions
• Aggressive add-backs — inflating profit with non-genuine adjustments
• Unexplained expenses — costs that do not appear in the P&L but show up in bank statements
• Dependence on one vendor or AI provider — single point of failure outside buyer control

Stress Testing: What If Things Go Wrong?

Before committing to a purchase, stress-test the business against adverse scenarios. The purpose is not to predict doom — it is to understand how fragile the economics are and whether you can survive if circumstances deteriorate.

Scenario A: Revenue falls 20%

What happens to cash flow? Can you still cover fixed costs? How long can the business sustain a 20% revenue reduction before requiring additional capital?

Scenario B: Revenue falls 40%

Is the business still viable? What costs can be cut? What is the break-even point?

Scenario C: Top customer leaves

If the largest customer churns immediately after acquisition, what is the impact on revenue, profitability, and valuation? Can the business survive?

Scenario D: Organic traffic falls 50%

If the primary acquisition channel is cut in half, how many new customers are acquired per month? Is the business still growing or merely sustaining?

Scenario E: Cloud/API costs rise 30%

How does a cost increase affect gross margin and profitability? Are prices adjustable without customer churn?

Scenario F: Founder is unavailable after closing

Can you operate the business without the founder’s assistance? What breaks first? What documentation is missing?

Scenario G: A key developer leaves

Who understands the codebase? Can you hire a replacement? How long would it take for a new developer to become productive?

Scenario H: Payment processor account experiences disruption

What happens if Stripe freezes the account or the seller’s account is not transferable? Can you process payments through an alternative?

Scenario I: AI provider changes pricing

If your AI API costs double or triple, is the business still profitable? Can you switch providers or adjust pricing?

For each scenario, model the impact on revenue, gross margin, cash flow, profitability, and valuation. If the business cannot survive a realistic adverse scenario, it may be overpriced or too fragile to acquire at any price.

Valuation Adjustment: Pricing What You Found

Due diligence is not simply a binary exercise of “good business / bad business.” It should directly influence the price you are willing to pay and the terms you demand. Every material finding should have a valuation consequence.

Examples of how findings should affect the deal:

• High founder dependency → lower valuation, longer transition period, larger holdback
• High customer concentration → lower valuation, specific retention protections
• Weak retention → lower multiple, earn-out tied to retention targets
• Technical debt → lower valuation to account for remediation costs
• Missing IP assignment → potential deal blocker; if remediable, lower valuation
• High infrastructure costs → lower normalized earnings, lower valuation
• Unstable revenue → lower multiple
• Strong diversified recurring revenue → potentially supports a stronger valuation case

This article does not prescribe a universal SaaS multiple. The appropriate multiple depends on growth rate, retention quality, gross margin, customer diversification, technical health, and dozens of other factors that emerge during due diligence. The key principle is that due diligence findings should be reflected in the price.

Deal Protection: Building Safety Into the Transaction

The transaction structure can protect you against risks discovered during due diligence or risks that emerge after closing. These mechanisms should be negotiated based on your findings.

Common Protection Mechanisms

• Representations and warranties — the seller formally represents that certain facts are true; if they are not, the buyer has recourse
• Indemnification — the seller agrees to compensate the buyer for specific losses if certain events occur
• Escrow — a portion of the purchase price is held by a third party and released only when conditions are met
• Holdback — part of the price is withheld for a period after closing to cover contingencies
• Seller financing — the seller finances part of the purchase price, aligning incentives post-closing
• Earn-outs — additional payments tied to post-acquisition performance
• Transition services — the seller agrees to provide support, training, or consulting for a specified period
• Closing conditions — specific conditions that must be met before the transaction closes
• Non-compete/non-solicit — restrictions on the seller competing or soliciting customers, where legally enforceable
• IP assignment — formal transfer of IP rights at closing
• Account transfer — domain, cloud accounts, payment processor, and other accounts transferred to the buyer
• Credential transfer — all passwords, API keys, and access credentials delivered securely

These are not legal drafting instructions. The specific terms, enforceability, and drafting of these mechanisms vary by jurisdiction and transaction structure. Acquisition counsel should structure them appropriately.

Final Pre-Closing Verification: Before You Wire the Money

Between the end of full due diligence and the closing date, circumstances can change. The final pre-closing verification is your last line of defense before committing capital.

Verify That:

• Revenue still matches the figures from due diligence
• Customers still exist and are actively paying
• No major customer has churned since due diligence
• No major employee or contractor has departed
• No security incident has occurred
• No legal dispute has emerged
• The payment processor account remains operational
• Domain transfer has been initiated or completed
• Source code has been transferred to a repository you control
• IP assignments have been executed
• Infrastructure accounts have been transferred
• Credentials have been delivered securely
• Contracts have been assigned or novated where required
• Databases have been migrated or access transferred
• Analytics accounts have been transferred
• Vendor accounts have been transferred
• Documentation is complete and accessible

There is a difference between due diligence complete (you have finished investigating) and transaction ready (everything has been verified, transferred, and confirmed). Do not wire funds until the latter state is achieved.

The Master Decision Framework: Buy / Renegotiate / Delay / Walk Away

Every due diligence investigation should conclude with one of four decisions. The framework forces discipline — you are not deciding between “buy” and “not buy” but among four distinct options, each with its own conditions.

BUY

The evidence supports the business and the valuation. Revenue reconciles. Customers are diversified and retained. The code is documented and owned. IP is assigned. Operations are documented. Risks are understood and manageable. The price reflects the verified quality of the business.

RENEGOTIATE

The business is attractive but the risks justify a lower price or stronger protections. Examples: revenue verified but retention is weaker than represented. Code is solid but technical debt requires investment. IP is assigned but key contractors have not signed. The business is worth acquiring, but not at the current price or terms.

DELAY

Important information remains unresolved. Critical documents are missing. The seller has not provided access to the code repository or payment processor. An independent technical audit has not been completed. Delaying does not mean rejecting — it means the evidence is insufficient to make an informed decision, and more time or information is needed.

WALK AWAY

Critical evidence is contradictory, ownership is unclear, major liabilities exist, or the economics do not work. Examples: revenue cannot be reconciled across three independent sources. IP assignments are missing and cannot be obtained. A security breach has been concealed. The seller refuses to provide primary records. Walking away is not a failure — it is the correct decision when the evidence does not support the investment thesis.

The Master Due Diligence Checklist: 100+ Checks

Use this checklist as your complete verification list. Copy it into a spreadsheet or project-management system and track each item’s status: Pending, In Progress, Verified, Problem Found, or N/A.

Financial (14 checks)

1. 24+ months of P&L statements received
2. Balance sheets received
3. Cash-flow statements received
4. Bank statements received for all accounts
5. Payment processor raw exports received
6. Accounting ledger and trial balance received
7. Tax filings reviewed
8. Accounts receivable aging reviewed
9. Accounts payable reviewed
10. Refund records reviewed
11. Chargeback records reviewed
12. Outstanding debts identified
13. Revenue classifications verified
14. Post-acquisition normalized profit calculated

Revenue & Payments (10 checks)

1. Gross vs. net revenue verified
2. Recurring vs. non-recurring revenue classified
3. One-time revenue identified and separated
4. Lifetime deals identified
5. Affiliate/advertising revenue identified
6. Stripe/PayPal/Paddle exports reviewed
7. Failed payments analyzed
8. Paused subscriptions identified
9. Processor ↔ accounting ↔ bank reconciliation completed
10. Revenue categories documented and verified

MRR, ARR & Retention (10 checks)

1. MRR bridge constructed for 12+ months
2. New, expansion, contraction, churned MRR tracked
3. ARR verified (not simply MRR × 12 where inappropriate)
4. Annual vs. monthly plan mix analyzed
5. Grandfathered pricing identified
6. Discounts and coupons quantified
7. Customer/logo churn calculated
8. Revenue churn calculated
9. GRR calculated for 12+ months
10. NRR calculated for 12+ months

Customers (10 checks)

1. Customer-level dataset received
2. Top 20 customers by revenue identified
3. Top 5 and top 10 revenue concentration calculated
4. Geographic concentration analyzed
5. Acquisition source distribution analyzed
6. Plan tier distribution analyzed
7. Customer tenure distribution analyzed
8. Customer interviews conducted (where possible)
9. Churn patterns by segment identified
10. Expansion/contraction patterns identified

Contracts (8 checks)

1. All customer contracts reviewed
2. Assignment restrictions identified
3. Change-of-control clauses identified
4. Termination and renewal conditions reviewed
5. Pricing commitments identified
6. SLA obligations reviewed
7. Indemnity and warranty clauses reviewed
8. Minimum commitments and exclusivity identified

Product & Technical (12 checks)

1. Product actively used and tested
2. Activation and onboarding assessed
3. Trial conversion rate calculated
4. Feature adoption analyzed
5. Support volume and patterns reviewed
6. Source code repository accessed
7. Commit history reviewed
8. Code quality assessed by technical expert
9. Test coverage evaluated
10. Architecture documented and assessed
11. Technical debt identified and quantified
12. Scalability assessed

Infrastructure & Security (10 checks)

1. Infrastructure map completed
2. Cloud account ownership verified
3. Monthly infrastructure costs documented
4. Backups confirmed and tested
5. Disaster recovery plan reviewed
6. Monitoring and logging in place
7. Security assessment completed
8. Dependencies audited for vulnerabilities
9. Secrets and credentials securely stored
10. Incident response plan documented

IP, Data & Privacy (8 checks)

1. IP assignment agreements verified for all contributors
2. Open-source licenses audited
3. Trademark ownership verified
4. Domain ownership verified
5. Brand assets ownership verified
6. Privacy policy reviewed
7. Data processing agreements reviewed
8. AI dependency and terms reviewed

Legal, Tax & People (10 checks)

1. Incorporation documents reviewed
2. Cap table verified
3. Debts and liens identified
4. Lawsuits and disputes identified
5. Tax registrations verified
6. Outstanding tax liabilities identified
7. Employee and contractor list received
8. Employment and contractor agreements reviewed
9. Key-person risk assessed
10. Founder dependency evaluated

Marketing, SEO & Sales (10 checks)

1. Marketing channel performance analyzed
2. SEO traffic reviewed in Search Console
3. Keyword rankings assessed
4. Backlink profile reviewed
5. Content ownership verified
6. CAC calculated
7. LTV calculated
8. LTV:CAC ratio calculated
9. Sales cycle and conversion rates analyzed
10. Acquisition channel transferability assessed

Operations & Market (8 checks)

1. SOPs and process documentation reviewed
2. Customer journey mapped
3. Vendor dependency table completed
4. Hidden liabilities searched for
5. Competitive landscape assessed
6. Market growth and maturity analyzed
7. Switching costs assessed
8. Commoditization and disruption risk evaluated

The One-Page Due Diligence Summary

At the end of your due diligence, complete this summary to consolidate all findings into a single executive overview.

Purchase Price: _________________________
Verified MRR: _________________________
Verified ARR: _________________________
Normalized Profit (Post-Acquisition): _________________________
Gross Margin: _________________________
Customer Concentration (Top 5): _________________________
NRR: _________________________
Monthly Churn: _________________________
Founder Dependency: Low / Moderate / High / Critical
Technical Risk: Low / Moderate / Material / High / Critical
Security Risk: Low / Moderate / Material / High / Critical
IP Risk: Low / Moderate / Material / High / Critical
Legal Risk: Low / Moderate / Material / High / Critical
Tax Risk: Low / Moderate / Material / High / Critical
Growth Risk: Low / Moderate / Material / High / Critical
Overall Risk: Low / Moderate / Material / High / Critical
Recommended Action: BUY / RENEGOTIATE / DELAY / WALK AWAY

Conclusion: The Philosophy of SaaS Acquisition Due Diligence

Due diligence is not a defensive exercise designed to prove that the seller is wrong. It is a systematic investigation designed to determine what is true. The distinction matters because the mindset you bring to the process shapes the outcome.

A hostile buyer looks for reasons to reject a deal and may miss genuine strengths. A naive buyer looks for reasons to believe and may miss fatal weaknesses. A professional buyer looks for evidence — and lets the evidence drive the conclusion. Some businesses deserve to be bought. Some deserve to be renegotiated. Some deserve to be abandoned. The evidence tells you which is which.

A good buyer verifies revenue. A good buyer understands customers. A good buyer audits technology. A good buyer confirms ownership. A good buyer tests scalability. A good buyer identifies hidden liabilities. A good buyer normalizes profitability. A good buyer stress-tests the economics. A good buyer adjusts valuation. A good buyer protects the transaction. And a good buyer walks away when the evidence does not support the investment.

The best acquisition is not necessarily the SaaS with the highest MRR. It is the SaaS whose economics, customers, technology, ownership, operations, and risks can be understood, verified, transferred, and managed at a price that still makes sense.

“Trust the seller enough to investigate the opportunity, but verify the business thoroughly enough that you do not have to trust the seller’s numbers.”

Also Read

Continue your SaaS acquisition preparation with these essential guides:

• Factors Affecting Website & SaaS Valuation
• How to Prepare Your Website or SaaS for Sale
• How to Buy the Right Website or SaaS Business

DISCLAIMER

This article is provided for educational and informational purposes only. It does not constitute legal, tax, accounting, investment, cybersecurity, or financial advice. SaaS acquisitions involve significant financial and legal risk, and every transaction has unique characteristics that require professional evaluation. Buyers should consult qualified legal counsel, tax professionals, accountants, and technical experts before completing any acquisition. Requirements vary significantly by jurisdiction, transaction structure, and the specific facts of each business. No checklist, framework, or article can eliminate acquisition risk entirely. The author and publisher assume no liability for any actions taken or not taken based on the information contained herein.