What SaaS technical due diligence should answer
SaaS technical due diligence gives investors a deal-useful view of whether the subscription revenue story is supported by a product, platform, Data/IP position, security posture, engineering team and operating model that can survive ownership transfer. SaaS due diligence for investors starts with that technical evidence because the aim is not a generic software audit; it is to decide whether the SaaS deal can scale, retain customers and absorb post-close change without unexpected risk.
SaaS businesses can be attractive targets because recurring revenue and high gross margins make the financial story easier to model than many project-led businesses. The harder part is everything underneath the financial story. SaaS M&A due diligence is where buyers test whether the business they think they are 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.
Treat the SaaS lens as a business-model overlay on investor technology due diligence, where the core question is still whether technical evidence supports the investment thesis and post-close plan.
If you need a fast outside view, use the provider-selection guide to compare a technical DD provider for SaaS deals by software depth, security coverage, cloud cost evidence, technical debt handling and PE/VC references.
Poor technical diligence can leave buyers exposed after close. Churn can be mis-measured, technical debt can be under-disclosed, single-engineer dependencies can weaken handover, and security gaps can surface during customer renewals. Good diligence should test those assumptions before they become operating problems.
SaaS technical due diligence framework
A useful SaaS DD scope connects each evidence stream to a buyer decision. The Deal-stage SaaS risk framework below keeps the SaaS lens separate from the broader technology due diligence checklist by focusing on subscription economics, platform inheritance and post-close operating metrics. For scope and fee trade-offs, compare the work against the technology due diligence cost guide.
Architecture and scalability
Stage: Pre-LOI screen
Evidence/output: Product architecture, hosting pattern, uptime signals, cloud spend trend and known scale limits.
Buyer decision: Whether the growth case needs confirmatory technical access before valuation is fixed.
Product and roadmap
Stage: Confirmatory DD
Evidence/output: Roadmap commitments, customer-request backlog, product analytics, release history and evidence of roadmap-to-revenue linkage.
Buyer decision: Whether the buyer is acquiring a repeatable product engine or a backlog of bespoke customer promises.
Security and compliance
Stage: Confirmatory DD
Evidence/output: SOC 2 or ISO evidence, penetration-test history, incident logs, data flows and GDPR controls.
Buyer decision: Whether customer, regulatory or remediation exposure changes price or completion conditions.
Data, AI and IP
Stage: Confirmatory DD
Evidence/output: Data ownership, IP assignment, open-source licensing, customer data rights, AI model dependencies and training-data constraints.
Buyer decision: Whether the buyer can inherit the product and data estate without legal or operational rework.
Engineering delivery
Stage: Operating plan
Evidence/output: Deployment frequency, release controls, incident response, QA process, environment separation and owner accountability.
Buyer decision: Whether the team can ship the post-close plan without slowing customer commitments or increasing outage risk.
Technical debt
Stage: Operating plan
Evidence/output: Repository structure, test coverage, release pipeline, backlog, defect history and maintenance cadence.
Buyer decision: Whether remediation competes with roadmap delivery in the first 100 days.
Team and key-person risk
Stage: Operating plan
Evidence/output: Code ownership, privileged access, founder dependency, contractor reliance, documentation and retention risk.
Buyer decision: Whether completion needs handover, retention, access transfer or succession protections.
Operating metrics and SaaS evidence
Stage: Operating plan
Evidence/output: Gross margin, cloud cost per customer, deployment frequency, support load, uptime and churn signals.
Buyer decision: Whether the SaaS operating model can scale without hiding cost or retention pressure.
SaaS technical diligence evidence checklist
For deal-team scanning, use this SaaS diligence summary checklist to summarise the findings in one page: revenue quality, unit economics, architecture and scalability, product and roadmap, security and compliance, data, AI and IP, engineering delivery, technical debt, team/key-person risk and operating metrics. Each row should state evidence reviewed, risk severity, likely remediation cost and whether the issue affects price, terms, a completion condition, walk-away risk or the 100-day plan.
1. Revenue Quality
ARR is the headline metric, but definitions vary and weak revenue hygiene can make it misleading. 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 12 to 18 month payback period is often treated as healthy for many SaaS models. Above 24 months suggests the growth motion may not yet be 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, Roadmap and Architecture
This is where generalist due diligence can stop short. In a SaaS business, the code base is part of the asset being bought. If the architecture cannot scale, if the deployment process is fragile, or if test coverage is weak, the buyer may be inheriting a remediation project rather than a stable product engine.
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. Data, AI and IP Risk
SaaS buyers increasingly inherit data products, analytics features, embedded AI workflows and third-party model dependencies as part of the transaction. Technical due diligence should test whether the target has the rights, controls and practical operating evidence needed to keep those features live after close.
- Data rights. Confirm customer contracts, privacy notices and processing records allow the intended product use.
- AI dependencies. Identify model providers, training-data constraints, output controls, human review and fallback plans.
- IP ownership. Check founder, employee and contractor assignment evidence, especially around early product builds.
- Open-source and vendor risk. Review licences, critical dependencies and whether vendor lock-in threatens margin or continuity.
5. Security and Compliance
Security used to be treated as a tick-box exercise on some smaller deals. That is no longer a safe assumption. Customers ask harder questions, regulators expect stronger controls, and a serious breach during the hold period can materially damage 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.
6. Engineering Delivery, 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.
Solo-founder and key-person risk in SaaS acquisitions
In smaller SaaS acquisitions, founder dependency is often the highest-value diligence question. A solo founder can be a strength, but if they hold architecture knowledge, production credentials, roadmap decisions and customer trust in their head, the buyer is acquiring a fragile handover rather than a transferable operating model.
Evidence checklist:
- Code ownership
- Privileged access
- Deployment knowledge
- Customer relationships
- IP assignment
- Bus factor
- Succession and retention
- Documentation and runbooks
Founder is the only release approver
Deal-protection response: Require access transfer, documented release runbook and interim founder availability through completion.
Core customer escalations depend on one engineer or founder
Deal-protection response: Link retention, customer handover and named backup ownership to the 100-day plan.
IP or contractor ownership is unclear
Deal-protection response: Make assignment evidence a condition precedent or specific warranty before close.
For an M&A tech DD scope that turns founder dependency into valuation, retention and 100-day actions, see buy-side technology due diligence.
SaaS technical DD red flags and buyer actions
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 should be mapped to a buyer action: price, terms, 100-day plan, completion condition or walk-away risk.
ARR, billing and product usage do not reconcile
Buyer action: Re-test revenue quality and consider price protection if retention or expansion assumptions depend on the gap.
Scaling depends on manual support or a fragile single-tenant architecture
Buyer action: Move remediation into the 100-day plan and cost it before accepting the growth model.
Security certification is promised but evidence is thin
Buyer action: Make certification progress, independent testing or customer-facing remediation a completion condition where customer renewal risk is material.
AI or data features rely on unclear rights, vendor lock-in or unmanaged model risk
Buyer action: Require data-rights evidence, vendor exit options and legal review before the product thesis is relied on.
One founder or engineer controls production access, roadmap trade-offs and customer escalations
Buyer action: Use retention, handover, access transfer and documentation requirements to decide whether this is a terms issue or walk-away risk.
For the evidence and escalation framework behind those decisions, use the deal-killing technology due diligence red flags guide before final diligence closes.
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.
Incomplete data is one of the biggest causes of delay. Sellers who prepare a clean data room with up-to-date documentation, recent test reports, and accurate metrics can remove weeks of avoidable back-and-forth. Sellers who cannot provide evidence quickly create doubt at the worst point in the process.
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 do not. The diligence focuses on questions that change the deal, not on filling out a checklist for the sake of it. The reports are written for boards, not just CTOs.
If you're working through a SaaS deal and want a second opinion, use the contact form below to scope the smallest diligence workstream that gives the investment committee enough evidence for the next decision.
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.
What does SaaS technical due diligence include?
SaaS technical due diligence includes architecture and scalability, product and roadmap evidence, security and compliance, data, AI and IP risk, engineering delivery, technical debt, team dependency, and the SaaS metrics that prove whether the platform can support the investment case.
How does SaaS technical due diligence affect valuation or deal terms?
Findings affect valuation or deal terms when they change the cost, timing or certainty of the growth plan. Common responses include price adjustments, specific warranties, completion conditions, retention support, remediation budgets, and 100-day actions rather than treating every technical issue as a binary deal-breaker.
What's the difference between SaaS due diligence and a software audit?
A software audit focuses on code and infrastructure in isolation. SaaS technical due diligence sits inside a broader commercial context, connecting technical findings to revenue quality, customer retention, operational scalability and the decisions a buyer needs before signing.
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.
How do you assess founder dependency in a SaaS acquisition?
Assess founder dependency by mapping who owns architecture, production access, deployments, customer relationships, IP decisions and roadmap trade-offs. Then test whether documentation, delegated access, retention terms and succession plans make the business transferable.
How can buyers mitigate key-person risk before close?
Buyers can mitigate key-person risk by requiring handover evidence, retention or consultancy support, access transfer, IP assignment confirmation, documentation sprints and a post-close succession plan tied to deal protections.
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 buyers can get a useful read from public information, customer reviews, hiring patterns, product evidence and the broader market context.