SaaS Due Diligence Guide

    What PE and VC investors actually look at when buying a SaaS business. Five areas that matter most, the questions that catch problems early, and the red flags that change the price.

    Why SaaS due diligence is different

    Buying a SaaS business is one of the more attractive deal types in the market right now. Recurring revenue, gross margins north of 70%, and predictable cash flow make the financial story easy to model. The harder part is everything underneath the financial story. SaaS due diligence is where buyers find out whether the business they think they're buying is the business that actually exists.

    A SaaS business is mostly intangible. There's no factory to inspect, no inventory to count, no warehouse to value. What you're actually buying is a code base, a customer book, a team, and the operational habits that connect all three. Standard financial due diligence catches some of the risks. The rest sit inside engineering, product, security, and how the company runs day to day.

    The cost of getting it wrong is high. Post-deal value erosion is often driven by churn that was mis-measured, technical debt that wasn't disclosed, single-engineer dependencies that turned into resignation letters, and security gaps that surfaced in the first customer renewal cycle. Each of those was visible during diligence if the right questions were asked.

    1. Revenue Quality

    ARR is the headline metric, but it's also the easiest one to massage. Good diligence pulls revenue apart and tests how much of it is genuinely recurring, contracted, and renewing.

    Key questions:

    • What percentage of ARR is on multi-year contracts vs annual rolling?
    • How is ARR reconciled to billing data and bank statements? Any gaps usually mean process weakness, sometimes worse.
    • What's the gross retention rate, and how is it calculated? Net revenue retention can hide a lot of churn if expansion is doing the heavy lifting.
    • Are there one-off services or implementation fees being counted as recurring? This is more common than people admit.
    • How concentrated is the revenue? If the top 10 customers represent more than 40% of ARR, that's a structural risk worth pricing in.

    2. Unit Economics

    LTV to CAC ratio gets quoted endlessly but rarely calculated consistently. The version that matters is the one tied to fully loaded customer acquisition cost (sales, marketing, partner commissions, onboarding) divided by lifetime value calculated with realistic churn assumptions.

    What to look for:

    • A payback period of 12 to 18 months is healthy for most SaaS. Above 24 months suggests the growth motion isn't yet efficient.
    • Gross margin trends. Margins drifting downward usually mean infrastructure costs growing faster than revenue, or pricing power eroding.
    • The cost to serve. Some SaaS businesses look great until you account for the support team needed to keep customers from churning.

    3. Product and Architecture

    This is where most generalist due diligence stops short. A SaaS business is its code base. If the architecture can't scale, if the deployment process is fragile, if there's no test coverage, you're buying a project rather than a product.

    The technical assessment should cover:

    • Code quality and structure. Is the code base maintainable, or is it being held together by the original founders?
    • Architecture decisions. Is it cloud-native, or is there legacy infrastructure that will need migrating?
    • Deployment and release processes. Can the team ship to production safely without all-night incidents?
    • Test coverage. Low coverage isn't always a deal-breaker, but it changes the integration risk profile significantly.
    • Documentation. Can a new engineer onboard in two weeks, or is all the knowledge in someone's head?
    • Key-person dependencies. If the original technical founder leaves, what breaks?

    4. Security and Compliance

    Security used to be a tick-box exercise on smaller deals. Not any more. Customers are asking harder questions, regulators are stricter, and the cost of a breach during the hold period can wipe out the equity story.

    The minimum bar:

    • SOC 2 or ISO 27001 certification, or a credible plan to achieve it within 6 to 12 months.
    • GDPR compliance for any business with UK or EU customers. This includes data processing agreements, retention policies, and the ability to action subject access requests.
    • Penetration test results from a recent independent test, ideally within the last 12 months.
    • A clear inventory of personal data, where it lives, and who has access.
    • Incident history. Any breaches should be disclosed with full context.

    5. Team and Operating Model

    The team is part of what you're buying, especially in smaller SaaS businesses. Diligence should map out who actually does the critical work, where the gaps are, and how dependent the business is on a small group of people.

    What to assess:

    • Engineering team composition and tenure. High turnover in the year before sale is a yellow flag.
    • The role of the founder. If the founder is also the CTO and the lead architect, what happens after they exit?
    • Sales team productivity. Are quotas being hit consistently, or is one or two reps carrying the number?
    • Customer success structure. SaaS businesses live or die by retention, and that's mostly an operational question.

    Common SaaS Due Diligence Red Flags

    In SaaS deals worked on for PE-backed groups and growth investors, the same red flags show up repeatedly. None are necessarily deal-breakers, but each changes the price you should pay or the structure of the deal:

    • ARR calculation that doesn't reconcile to billing data
    • Churn measured on a metric that flatters the business (e.g. logo churn instead of revenue churn)
    • A code base nobody's refactored in five years
    • Security certification that's "in progress" but always six months away
    • A handful of customers responsible for most of the growth story
    • No documented onboarding process for new engineers
    • Backups and disaster recovery that have never been tested
    • A development team smaller than the customer base would suggest

    How long should SaaS due diligence take?

    For a typical mid-market SaaS deal (£10m to £50m enterprise value), the technical and operational due diligence usually takes three to four weeks. Larger deals or messier targets take six to eight. The work should run in parallel with financial diligence, not after it.

    The biggest cause of delay is incomplete data. Sellers who prepare a clean data room with up-to-date documentation, recent test reports, and accurate metrics save themselves weeks. Sellers who don't, lose deals.

    How TechDD approaches SaaS due diligence

    Peter Rossi has spent the last 15 years working in and around SaaS businesses, including 22 acquisition integrations across five countries inside a PE-backed group. He co-founded InfoSaaS and took it through a sale to private equity in 2021. He has advised on £300m+ of PE and VC investment decisions.

    What that means in practice: knowing which problems matter and which ones don't. The diligence focuses on the questions that actually change the deal, not on filling out a checklist for the sake of it. And the reports are written for boards, not just CTOs.

    If you're working through a SaaS deal and want a second opinion, get in touch.

    FAQ

    How is SaaS due diligence different from regular tech due diligence?

    SaaS due diligence focuses more heavily on recurring revenue mechanics, churn analysis, customer concentration, and the operational maturity needed to support long-term retention. Regular tech due diligence covers similar architecture and code quality questions, but the business model differences matter. A SaaS business that loses 5% of its customers a year has a very different risk profile from a project services business with the same churn rate.

    Do small SaaS deals need full technical due diligence?

    Yes, in most cases. Even on deals under £5m, the technical risks can wipe out the equity if missed. The depth of work should match the complexity of the target, but skipping it entirely is rarely a good call.

    What's the difference between SaaS due diligence and a software audit?

    A software audit focuses on the code and technical infrastructure in isolation. SaaS due diligence sits inside a broader commercial context, connecting the technical findings to revenue quality, customer retention, and operational scalability. You usually want both, but the SaaS lens is what tells you whether the deal works.

    Who pays for SaaS due diligence?

    Buy-side due diligence is paid for by the buyer. Sell-side due diligence is paid for by the seller, usually as part of a vendor due diligence package designed to accelerate a sale process and reduce price chipping during negotiations.

    Can you do SaaS due diligence on a target you can't talk to directly?

    Yes, this is more common than people think. Pre-LOI work is often done with limited access. The findings are necessarily partial, but you can get a useful read from public information, customer reviews, hiring patterns, and the broader market context.

    Related Resources

    Running a SaaS deal? Let's talk.

    Speak with TechDD for a practical assessment focused on business risk, integration readiness, and value creation.

    Discuss Your Deal