A Guide to Technical Due Diligence for Software Acquisitions

Architecture & Framework

• Overall architecture pattern (monolith, microservices, modular monolith, hybrid) and whether it supports 3–5x growth without fundamental redesign
• Primary languages and frameworks—currency of versions, EOL status, community health. A framework four years past end-of-life is a different risk than one that is merely one major version behind
• Number of deployable units and how they relate to each other—monorepo vs. polyrepo, shared libraries, build dependencies
• Frontend/backend separation—server-rendered templates vs. SPA vs. hybrid. Ratio of template/view code to business logic (high template ratios can indicate a presentation-heavy codebase that is difficult to refactor)
• Mobile application architecture (if applicable)—native vs. cross-platform (React Native, Flutter), app store compliance, OTA update capability, and whether the mobile codebase shares logic with the web platform or is independently maintained

Codebase Quantitative Analysis

• Total lines of code by language and component—backend, frontend, mobile, infrastructure, tests. Codebase size contextualizes the scale of any modernization effort
• Test-to-production code ratio—how many lines of test code exist relative to product code. A ratio near or above 1:1 indicates strong testing discipline; a ratio below 0.1:1 signals testing gaps
• Code duplication analysis—volume and distribution of duplicated code across modules. Significant duplication (tens of thousands of lines) across independently maintained applications is a maintenance multiplier
• Commit velocity and contributor patterns over 12–24 months—is the codebase actively maintained? Declining commit frequency or contributor concentration can signal team attrition or stagnation
• Revert rate—how often commits are rolled back. High revert rates indicate quality issues in the development process

Technical Debt & Maintainability

• Third-party dependency inventory: outdated libraries, abandoned packages, known CVEs. Distinguish between dependencies that are one minor version behind (normal) and those with unpatched critical vulnerabilities (material)
• Hardcoded customer-specific logic—conditional branches that check for specific customer names or IDs. These are a common pattern in early-stage SaaS and a measurable indicator of productization maturity
• Client-specific scripts or customizations maintained outside the core product—who maintains them, what they cost to support, and whether that cost is recovered through services revenue
• Evidence of accumulated technical debt: workarounds, TODO density, commented-out code, undocumented behavior, feature flags that were never cleaned up
• Hardcoded domain references that constrain multi-vertical expansion (e.g., industry-specific terminology embedded throughout the codebase rather than abstracted into configuration)

Database & API Design

• Database technology and schema design—table count, dataset size, normalization quality, indexing strategy, read/write ratio
• Single database instance vs. read replicas—a single instance with no replication is a scaling constraint and a single point of failure
• API design and versioning strategy—RESTful vs. bespoke, internal service boundaries, external integration surface area, documentation quality
• Multi-tenancy model—how tenant isolation is enforced (row-level, schema-level, database-level). The depth and consistency of tenant scoping throughout the codebase (e.g., is a company or tenant identifier enforced at every query layer, or are there gaps?)
• Scalability constraints—identified bottlenecks, horizontal vs. vertical scaling approach, caching strategy, connection pooling, queue-based architecture for background processing

Software Quality & Debt Quantification

• Technical debt quantification—whether technical debt can be estimated in engineering hours or dollar cost to remediate. Methodologies like CAST SQALE or SonarQube’s technical debt calculation provide a structured approach. A McKinsey study found that technology issues account for approximately 30% of value destruction in M&A transactions—quantifying technical debt converts a vague concern into a line item in the financial model
• Software quality dimensions—the ISO/IEC 25010 software quality model defines eight quality characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. Each has sub-characteristics (e.g., maintainability includes modularity, reusability, analyzability, modifiability, and testability) that map to specific diligence observations. A product with high functionality but low maintainability is a product that works today but will be expensive to evolve
• Dependency health analysis—beyond known CVEs, the overall health of the dependency tree: how many dependencies are actively maintained, how many have been deprecated or archived, the depth of transitive dependencies, and whether the project uses lock files to ensure reproducible builds. A product with 400 npm dependencies, 60 of which are unmaintained, carries a different maintenance burden than one with a lean, actively supported dependency tree

Infrastructure Overview

• Cloud provider(s) and account structure—single account vs. multi-account, organizational hierarchy, IAM governance
• Hosting model—IaaS (EC2, Compute Engine), PaaS (Elastic Beanstalk, Cloud Run, App Service), containerized (ECS, EKS, GKE), or serverless (Lambda, Cloud Functions). Each has different cost curves and operational overhead
• Region and availability zone strategy—single-region, multi-AZ, multi-region. Geographic proximity to customer base
• Dedicated infrastructure for enterprise clients—whether large customers run on isolated instances, what that costs, and whether it is priced into contracts
• Non-production environments—staging, QA, development. How many exist, whether they match production configuration, and what they cost relative to production

Cost Analysis & EBITDA Impact

• Monthly cloud spend as a percentage of revenue—trend over 12 to 24 months. Cloud costs that grow faster than revenue indicate an efficiency problem; costs that shrink as a percentage indicate operating leverage
• Cost breakdown by category: compute, storage, data transfer, CDN, database, monitoring, managed services, and third-party SaaS. Identify the top five line items by spend
• EBITDA impact modeling—what does a 20%, 40%, or 60% reduction in the largest cost categories translate to in margin improvement? At deal multiples, what is the enterprise value impact?
• Cost per customer or per seat—unit economics of infrastructure. Is the platform more or less expensive to operate per incremental customer?
• Services revenue infrastructure cost—if the company runs managed services or dedicated hosting for customers, what is the margin on that hosting?

Optimization Opportunities

• Instance sizing and utilization—right-sizing opportunities, average CPU and memory utilization, reserved vs. on-demand vs. spot usage
• CDN configuration and cost efficiency—caching hit rates, origin request volume, anomalous request patterns (e.g., recursive requests or misconfigured cache rules that amplify traffic)
• Data transfer patterns—cross-region, cross-AZ, and internet egress costs. Unexpected data transfer between services in different availability zones is a common source of invisible cost
• Storage lifecycle management—tiering policies, orphaned volumes and snapshots, backup retention costs, S3 bucket size and access frequency
• Database hosting costs—instance class, read replica strategy, managed vs. self-hosted economics, automated scaling configuration
• Reserved capacity or savings plan coverage—utilization of existing commitments, expiration timeline, gap between committed and actual usage
• Observability and logging costs—log volume, retention policies, third-party monitoring and APM spend (Datadog, New Relic, Splunk). These can be surprisingly large line items
• Redundant or unused services—resources running in non-production environments without schedules, zombie infrastructure, orphaned load balancers, unattached elastic IPs
• Cost allocation and tagging discipline—ability to attribute spend to products, features, environments, or customers. Lack of tagging makes optimization harder post-close

FinOps Maturity & Cloud Governance

• FinOps practices—whether the company has a defined process for cloud cost management: regular cost reviews, cost anomaly alerting, budget forecasting, and cost-aware engineering practices. Companies without FinOps discipline typically discover 20–40% optimization opportunity during diligence. The FinOps Foundation defines a crawl-walk-run maturity model that provides a useful benchmark
• Multi-cloud posture—whether the company runs workloads across multiple cloud providers (AWS, Azure, GCP) and whether that is intentional (avoiding vendor lock-in, meeting customer requirements) or accidental (acquired through M&A or organic drift). Unintentional multi-cloud creates operational complexity without corresponding benefit
• Kubernetes and container cost governance—if the platform runs on Kubernetes (EKS, GKE, AKS), whether resource requests and limits are configured appropriately, whether cluster autoscaling is enabled, and whether workload bin-packing is optimized. Over-provisioned Kubernetes clusters are one of the most common sources of unnecessary cloud spend
• AI and ML infrastructure costs—if the product uses AI features, the cost of GPU instances, model hosting, inference endpoints, and training jobs as a distinct line item. AI infrastructure costs can scale nonlinearly with usage and should be tracked separately from general compute

Application Security

• Authentication architecture—custom-built vs. managed service (Firebase Auth, Auth0, Cognito), password hashing algorithm, session management, token expiration. Hardcoded credentials or shared passwords across accounts are critical findings
• Authorization model—role-based access control implementation, permission granularity, enforcement consistency across API endpoints and UI
• Web application firewall (WAF)—whether one exists, what it covers, rule configuration, whether it is actively monitored or deployed in log-only mode
• Input validation and injection protection—SQL injection, XSS, CSRF, and RCE attack vectors. Active vulnerability scan results if available
• Webhook and callback security—whether incoming webhooks from payment processors, scheduling providers, and other integrations validate signatures. Unsigned webhooks are an exploitable attack surface
• Billing and access control boundaries—whether API routes that control feature access, pricing tiers, or subscription state are properly protected (e.g., cron jobs or internal routes that bypass authentication)

Infrastructure Security

• Encryption at rest and in transit—TLS configuration, certificate management, database-level encryption. Whether database connections require SSL (a production database with requireSsl: false is a material finding)
• Secrets management—how API keys, database credentials, private keys, and tokens are stored. Plaintext secrets in environment variables, source code, or CI/CD configuration vs. a secrets manager (Vault, AWS Secrets Manager, GCP Secret Manager)
• Cloud security services—GuardDuty, CloudTrail, Security Hub, or equivalent enabled and actively monitored. Cloud audit trail coverage for forensic capability
• Network security—VPC configuration, security group rules, public vs. private subnet placement, bastion host or VPN access patterns
• Access controls—principle of least privilege for cloud IAM, review cadence for permissions, number of users with root or admin access, MFA enforcement for cloud console

Compliance & Governance

• Compliance certifications—SOC 2 Type I vs. Type II (and whether Type I was followed through), ISO 27001, HIPAA, PCI-DSS, FedRAMP, or industry-specific standards. Status of ongoing compliance programs vs. one-time certifications
• Industry-specific regulatory requirements—FMCSA for transportation, COPPA/FERPA for products serving children or students, PCI-DSS for payment processing, state-level privacy laws
• Data privacy practices—data classification, retention policies, handling of PII and sensitive data, GDPR and CCPA readiness, data deletion capability
• Penetration testing history—frequency, scope (external only vs. external and internal), remediation of findings, time from finding to fix
• Incident response plan—documented runbooks, escalation procedures, past incident postmortems, notification obligations
• Third-party vendor risk—security assessment of critical SaaS dependencies, data processing agreements, supply chain exposure

SOC 2 Operational Readiness

• SOC 2 readiness beyond the certificate—having a SOC 2 report is not the same as having the operational practices that sustain it. Evaluate whether the underlying controls are actively maintained: formal change management processes, documented access review cadence (quarterly is standard), vendor risk management program, employee security awareness training, and defined onboarding/offboarding procedures that include access provisioning and revocation
• Application-level audit trails—whether the product maintains comprehensive logs of who did what, when, and from where—not just infrastructure-level logs (CloudTrail, Azure Activity Log) but application-level audit trails that record user actions, administrative changes, data access, and configuration modifications. These are a prerequisite for SOC 2, HIPAA, and any compliance framework, and their absence is one of the most common gaps in early-stage software companies
• Trust Services Criteria coverage—SOC 2 addresses five categories: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. Most companies pursue Security only. Evaluate whether the business requires the additional criteria based on customer contracts, industry expectations, and the data the product handles
• Continuous compliance vs. point-in-time—whether compliance monitoring is automated and continuous or requires manual evidence collection before each audit cycle. Automated compliance tooling (Vanta, Drata, Secureframe) reduces the operational burden but introduces its own vendor dependency

Security Architecture & Supply Chain

• Zero trust posture—whether the architecture assumes trust based on network location (traditional perimeter model) or verifies every request regardless of origin. Products that rely on VPN access as their primary security boundary are more fragile than those that enforce authentication and authorization at every service boundary
• Software supply chain security—whether the build and deployment pipeline is hardened against supply chain attacks: signed commits, verified base images, pinned dependencies, and integrity checks on third-party packages. Supply chain compromises (SolarWinds, Codecov, Log4j) demonstrate that vulnerabilities in the development toolchain can be more damaging than vulnerabilities in the product itself
• OWASP ASVS alignment—the OWASP Application Security Verification Standard provides a structured framework for assessing application security across 14 domains including authentication, session management, access control, cryptography, and error handling. ASVS Level 2 is the recommended baseline for most applications; Level 3 applies to high-value targets in finance, healthcare, and defense. Mapping current security practices against ASVS identifies specific gaps rather than relying on general impressions of security posture
• Security program maturity—whether security is reactive (responding to incidents and audit findings) or proactive (threat modeling, security-by-design, regular internal assessments). The NIST Cybersecurity Framework 2.0 provides a useful reference with six functions—Govern, Identify, Protect, Detect, Respond, Recover—for evaluating program completeness. The Govern function, added in CSF 2.0, explicitly addresses organizational security governance and risk strategy

Composition & Structure

• Team size, structure, and reporting lines—engineering, QA, DevOps, product, data, support engineering. Distinguish between employees, contractors, and offshore staff
• Onshore vs. offshore vs. contractor composition—cost structure, IP ownership considerations, knowledge distribution across geographies and time zones
• Functional gaps—missing roles that the current team compensates for (e.g., no dedicated QA, no dedicated DevOps, no product manager). These gaps define post-close hiring priorities
• Support vs. engineering boundaries—whether support staff maintain scripts, integrations, or customer-specific configurations that are outside the core engineering workflow but essential to operations
• Compensation structure—market competitiveness, equity vs. cash mix, retention risk during ownership transition, whether key employees have change-of-control provisions

Key-Person Risk

• Key-person dependencies by system—identify individuals whose departure would materially affect operations. Map each critical system (infrastructure, auth, payments, core business logic) to who owns it. A single person with sole access to production infrastructure is a different risk than a single person who is the best at a particular feature area
• Code ownership concentration—git blame and commit history analysis to quantify who has contributed what percentage of code to critical modules. If one developer authored 90%+ of a critical subsystem, that is a measurable bus factor
• CTO as operational bottleneck—whether the technical leader is also the sole deployer, the sole infrastructure operator, or the sole person who can resolve production incidents. This is common in small teams and constrains post-close velocity
• Cross-training and knowledge transfer practices—pair programming, rotation policies, documentation of tribal knowledge. The gap between what is documented and what lives in specific people's heads
• Tenure and retention patterns—average tenure, recent turnover, reasons for departures. Founders or early engineers who have been signaling departure are a different risk profile than a stable, long-tenured team

Capability & Culture

• CTO/VP Engineering assessment—technical depth, leadership capacity, strategic vision, alignment with post-close plans. Whether the technical leader can scale with the business or is best suited for the current stage
• Hiring pipeline and ability to recruit—open roles, time-to-fill history, sourcing channels, employer brand in local market. Whether the tech stack is attractive or a limiting factor for recruiting
• Engineering culture indicators—code review rigor, post-incident reviews, technical decision-making process, how technical disagreements are resolved
• Documentation quality—architecture docs, runbooks, onboarding materials, API documentation, architectural decision records. Evaluate what exists, not what is promised
• Engineering management ratios—the ratio of individual contributors to engineering managers. Ratios above 10:1 may indicate under-investment in management; ratios below 4:1 may indicate organizational bloat. The right ratio depends on team seniority and product complexity, but extreme outliers in either direction are a signal
• AI and emerging technology readiness—whether the engineering team has the skills to build, deploy, and maintain AI features, or whether that requires new hires. If the deal thesis includes AI-driven value creation, the gap between current team capabilities and required capabilities defines a post-close hiring plan and timeline

Build & Deployment

• CI/CD pipeline maturity—fully automated build, test, and deployment vs. manual steps. Identify every manual step in the deployment process and who performs it. A team where only the CTO can deploy is constrained differently than one with automated pipelines any engineer can trigger
• Deployment frequency—how often code ships to production. Daily, weekly, monthly, or ad-hoc. Monthly frequency with 40–50 manual deployments indicates a bottleneck; multiple automated deploys per day indicates maturity
• Rollback capability—how quickly the team can revert a bad deploy. Automated rollback vs. manual intervention, database migration rollback strategy
• Infrastructure as code—Terraform, CloudFormation, Pulumi, or equivalent. Percentage of infrastructure managed through code vs. manually configured through the console. Drift detection and state management practices
• Container and orchestration strategy (if applicable)—Docker, Kubernetes, ECS, Cloud Run. Image build pipeline, registry management, container security scanning

Quality & Testing

• Test coverage by type—unit, integration, end-to-end. Overall coverage percentage and what it actually measures. High coverage of utility functions with no integration tests is a different profile than moderate coverage with strong end-to-end tests
• Test coverage distribution—where coverage is concentrated and where gaps exist. Backend API coverage vs. frontend coverage vs. mobile coverage. A product with strong backend tests but near-zero mobile test coverage (e.g., below 1%) has a measurable quality risk in the mobile application
• QA function—dedicated QA team or role, vs. developer self-testing only. Manual testing processes, regression testing discipline
• Source control practices—branching strategy (trunk-based vs. feature branches vs. GitFlow), code review requirements, merge process, protected branches
• Environment parity—staging, QA, and production consistency. Whether non-production environments use production-like data, infrastructure, and configuration

Reliability & Operations

• Monitoring and observability—application performance monitoring (APM), error tracking, structured logging, alerting thresholds and escalation. Whether alerts are actionable or create noise
• Uptime and reliability—SLA commitments, historical uptime percentage, mean time to recovery (MTTR), major incident history over the past 12 months
• Incident management—on-call rotation, escalation procedures, postmortem culture, whether the same person is always the one paged
• Feature flagging—whether the platform supports feature flags, how they are managed, whether they are used for gradual rollouts or only for long-lived configuration. Feature flag maturity directly affects the feasibility of tiered packaging and controlled releases post-close
• Disaster recovery and business continuity—backup strategy and frequency, cross-region or cross-account backup replication, recovery time objectives (RTO) and recovery point objectives (RPO), and whether restore procedures have been tested. A backup strategy that has never been tested is not a backup strategy

DORA Metrics & Engineering Maturity

• Deployment frequency—how often code reaches production, benchmarked against the DORA framework. Elite teams deploy on-demand (multiple times per day); low performers deploy monthly to semi-annually. A team deploying monthly with 40+ manual steps is operating at a fundamentally different velocity than one with automated pipelines deploying daily
• Lead time for changes—elapsed time from code commit to production deployment. Elite performers measure this in hours; low performers in months. Long lead times constrain the speed of post-close execution on the product roadmap
• Change failure rate—percentage of deployments that cause a failure in production. Elite teams maintain rates below 5%; low performers exceed 30%. High failure rates compound with deployment frequency—deploying often with a 30% failure rate creates chaos, not velocity
• Mean time to recovery (MTTR)—how quickly the team restores service after a production incident. Elite teams recover in under an hour; low performers take over a week. MTTR is the clearest indicator of operational maturity and directly affects customer-facing SLA compliance

Environment & Supply Chain Security

• Environment separation and data controls—whether development, staging, and production environments are fully isolated with independent access controls. Whether customer data (including PII) exists in non-production environments, whether PII is scrubbed or masked in staging and development databases, and who has access to each environment. Customer data in dev environments with broad developer access is both a security risk and a compliance violation under most data protection frameworks
• SBOM generation in CI/CD—whether the build pipeline automatically generates a Software Bill of Materials for each release, enabling automated vulnerability scanning and license compliance checking as part of the standard deployment process
• Dependency update cadence—how frequently third-party libraries and frameworks are updated, whether automated tools (Dependabot, Renovate, Snyk) manage dependency updates, and the average age of dependencies in the stack. The Synopsys OSSRA report finds that 91% of codebases contain components more than ten versions out-of-date

Data Stores & Schema

• Primary data stores—relational (PostgreSQL, MySQL, SQL Server), NoSQL (MongoDB, DynamoDB), data warehouse, data lake. Technology choices and their fit for the workload
• Database scale—table count, total dataset size, growth rate. A 160GB database with 658 tables is a different migration and optimization challenge than a 5GB database with 30 tables
• Schema quality—normalization, naming conventions, referential integrity, foreign key enforcement, migration history (managed migrations vs. ad-hoc DDL changes)
• Read/write ratio and query patterns—a 95% read workload has different optimization opportunities (caching, read replicas) than a write-heavy workload. Identify the most expensive queries and whether they are indexed appropriately
• Multi-tenant data isolation—consistency of tenant scoping across all tables and queries. Gaps in tenant isolation are both a security and a data integrity risk

Data Quality & Portability

• Data quality assessment—completeness, consistency, duplication, orphaned records, known integrity issues. Data quality problems compound over time and constrain every downstream use case (analytics, AI, integrations)
• Entity resolution complexity—if the business needs to export, migrate, or segment customer data (e.g., for a divestiture, data portability request, or platform migration), how many engineering hours does that require? Complex entity relationships can turn a straightforward data export into a multi-hundred-hour project
• Migration readiness—portability of data formats, vendor lock-in risks, export capabilities, ORM abstraction layer vs. raw SQL coupling
• Customer data segmentation—ability to produce per-customer data exports, isolate customer data for regulatory requests, and support multi-entity reporting
• Data retention and archival—policies, compliance with regulations (GDPR right-to-deletion, industry-specific retention requirements), storage cost implications of unbounded growth

Pipelines & Analytics

• ETL/ELT pipelines—data flow between systems, transformation logic, failure handling, latency, scheduling (cron vs. event-driven)
• Analytics and reporting infrastructure—BI tools, dashboards, self-serve analytics capabilities. Whether the business relies on direct database queries for reporting or has a dedicated analytics layer
• Data governance—ownership, access controls, audit logging, data lineage. Who can access production data and through what mechanisms
• Third-party data dependencies—enrichment providers, external data feeds, contractual terms, cost structure
• Data lineage and provenance—ability to trace data from source through transformations to its final form in reporting or customer-facing features. Lack of data lineage makes debugging data quality issues exponentially harder and creates audit risk for regulated industries
• Data contracts between services—whether there are formal or informal agreements about the shape, schema, and quality of data exchanged between systems. In microservice or multi-application architectures, the absence of data contracts means that upstream changes can silently break downstream consumers
• Real-time data capabilities—event streaming infrastructure (Kafka, Kinesis, Pub/Sub), real-time analytics, and whether the architecture supports event-driven patterns. Batch-only data pipelines constrain the product’s ability to deliver real-time features post-close
• ML feature infrastructure—if AI features are on the roadmap, whether the data architecture supports feature extraction, storage, and serving at the speed and scale those features require. Clean, versioned, labeled datasets are the foundation for any durable AI capability

Integration Inventory

• Complete inventory of third-party integrations—payments (Stripe, Braintree), communication (Twilio, SendGrid), scheduling, analytics, monitoring, authentication, and any domain-specific services
• Integration architecture—whether each integration is abstracted behind a service layer or directly coupled throughout the codebase. Count the number of files that directly reference each vendor’s SDK or API. High counts indicate tight coupling
• Contract terms and pricing—negotiated rates vs. standard pricing, volume commitments, contract expiration dates, auto-renewal terms
• Integration maintenance burden—commit history to integration-related code over the past 12 months. A high ratio of bug-fix commits to feature commits in integration code indicates instability

Vendor Risk & Replaceability

• Vendor lock-in assessment for each critical integration—estimated engineering hours to replace, availability of alternatives, data portability from the vendor
• Single-vendor dependencies—systems where a single vendor's outage would take the product offline. Distinguish between vendors with strong SLAs (major cloud providers, Stripe) and niche vendors with limited redundancy
• Proprietary logic on top of vendor services—whether the product adds meaningful value beyond what the vendor provides (e.g., custom business rules, domain-specific workflows, data transformations). This is the platform’s intellectual property layer, separate from the vendor’s commodity service
• Webhook and callback reliability—error handling for integration callbacks, retry logic, dead-letter queues, signature validation. How the system behaves when a third-party service is degraded or returns unexpected responses
• Payment processing integration depth—if the platform processes payments, the Stripe (or equivalent) integration model: Stripe Connect, direct charges, platform fees. PCI compliance scope, chargeback handling, reconciliation between the platform's records and the payment processor

API Maturity & Platform Ecosystem

• API-as-product maturity—if the platform exposes APIs to customers or partners, the quality of documentation, versioning strategy, rate limiting, authentication, and developer experience. A well-designed API is a growth lever; a poorly documented one is a support burden
• Platform dependency risk—if the product is built on top of a platform (Salesforce, Shopify, HubSpot, ServiceNow), the terms of that relationship, the platform’s history of changing partner economics, and the engineering effort required to migrate if the relationship deteriorates. A product whose entire distribution depends on another company’s marketplace is a different risk than one that uses a platform as one channel among several
• Open source dependency audit—a software composition analysis (SCA) scan of all third-party libraries and open source components. Percentage of dependencies with known CVEs, percentage that are more than two major versions behind, and whether automated vulnerability scanning is integrated into CI/CD. The Synopsys OSSRA report consistently finds that 84% of commercial codebases contain at least one known vulnerability, with 74% containing high-risk vulnerabilities
• Marketplace and ecosystem health—if the product has an integration marketplace or plugin ecosystem, the number of active integrations, developer adoption trends, and whether the ecosystem creates meaningful switching costs or is primarily cosmetic

Current AI Capabilities

• AI claims vs. reality—what the marketing materials and pitch deck describe as “AI-powered” vs. what is actually deployed in production. A managed OCR service processing documents is different from a custom-trained model. Both may appear as “AI” in a CIM
• Existing AI/ML features inventory—what is in production, what is in development, what is on the roadmap. For each feature: what model or service powers it, when it was deployed, and what business outcome it drives
• Model provenance—proprietary models fine-tuned on first-party data vs. off-the-shelf API calls to third-party services (OpenAI, Anthropic, AWS Textract). The former creates durable differentiation; the latter is commodity access that competitors also have
• AI cost structure—current monthly spend on AI/ML services, per-inference or per-call costs, and how that scales with usage. A product spending $270/month on OCR has a different AI cost profile than one spending $15,000/month on LLM API calls
• Prototyping and experimentation infrastructure—whether the team has tools for rapid AI prototyping (n8n, LangChain, internal tooling) and has used them to validate AI use cases before committing engineering resources

Data & Foundation Readiness

• Data readiness for AI—volume, quality, labeling, and accessibility of historical data that could be used for training or fine-tuning. Clean, structured, domain-specific data is the most durable competitive advantage in AI
• Domain-specific data moat—whether the company's historical data, customer interactions, or industry knowledge creates training data that competitors cannot easily replicate
• Foundation readiness—clean data pipelines, well-documented API surfaces, modular architecture, and engineering practices that would support AI feature deployment without requiring a platform rewrite first
• Evaluation and monitoring—how model accuracy is measured in production, drift detection, human-in-the-loop feedback mechanisms, error handling when models produce incorrect output

Strategic AI Position

• Team capability—ML engineering talent, data science capacity, and whether the current team can build, deploy, and maintain AI features or whether that requires new hires
• Competitive AI exposure—risk that AI-native entrants could replicate or displace the product's core value. Vertical SaaS products that primarily provide workflow access (rather than proprietary data or embedded domain logic) are most exposed to AI-native disruption
• AI value creation opportunity—specific, measurable use cases where AI could create product or operational advantage post-close: document processing, intelligent automation, predictive analytics, customer-facing AI features, internal tooling. Prioritize use cases by data readiness and business impact
• Marketing language calibration—whether the company’s AI positioning is accurate, aspirational, or overstated. Material gaps between AI claims and reality should be flagged as a diligence finding, not just an observation

LLM-Specific Risks & Governance

• Hallucination risk and mitigation—if the product uses large language models, whether outputs are grounded through retrieval-augmented generation (RAG), constrained output schemas, or human-in-the-loop review. Unmitigated hallucination in a product that generates compliance documents, financial analysis, or medical information is a liability exposure, not just a quality issue
• Prompt injection and adversarial input—whether the product is vulnerable to prompt injection attacks where user input manipulates the model’s behavior. Products that expose LLM capabilities to end users without input sanitization and output filtering are running an open attack surface
• Data leakage through AI providers—whether customer data is sent to third-party LLM APIs, what those providers’ data retention and training policies are, and whether the company has negotiated zero-retention agreements. Sending customer data to a model provider that may use it for training creates both a privacy risk and a competitive risk
• Model versioning and rollback—whether the product pins to specific model versions and can roll back when a provider updates a model with behavior changes. An upstream model change that degrades output quality for a critical workflow is an operational risk that most early AI implementations do not manage
• AI cost trajectory—how LLM API costs scale with usage growth. Token economics, caching strategies, model selection by task complexity (using smaller models for simpler tasks), and whether the cost curve is sustainable at 3–5x the current user base
• Regulatory classification—whether any AI features would be classified as high-risk under the EU AI Act, requiring conformity assessments, technical documentation, and human oversight mechanisms. Products that use AI for hiring decisions, creditworthiness assessment, or safety-critical applications face the most stringent requirements, with compliance obligations phasing in through August 2026

Revenue Composition

• SaaS vs. services revenue decomposition—what percentage of revenue is recurring subscription vs. one-time implementation, custom development, or managed services. For services revenue: what does it pay for, and is the work performed by engineering or by a separate services team?
• Custom development revenue—if the company does custom programming for clients, what is the annual revenue, what is the margin, and does the custom work create maintenance obligations that divert engineering from the core product?
• Managed services or dedicated hosting revenue—if the company provides hosting or managed infrastructure for enterprise clients, what is the cost to deliver it and what is the margin? Infrastructure margins of 70%+ on dedicated hosting are healthy; margins below 30% suggest the service is underpriced
• Payment processing or marketplace revenue—if the platform processes transactions and takes a percentage, the GMV concentration across customers, take rate, and whether the take rate is competitive or vulnerable to renegotiation

Packaging & Pricing Readiness

• Tiered pricing or packaging feasibility—whether the platform's architecture and feature flagging support differentiated product tiers. If the platform currently offers a single tier, what technical work is required to gate features for a tiered model?
• Billing system architecture—how subscriptions, usage metering, and invoicing are implemented. Custom-built billing vs. Stripe Billing, Chargebee, or equivalent. The complexity of migrating pricing models post-close
• Customer concentration—revenue distribution across the customer base. Percentage of revenue from the top 1, 5, and 10 customers. High concentration creates both pricing risk (loss of a key account) and platform risk (feature development driven by a single customer's needs)
• Expansion revenue mechanics—upsell and cross-sell paths, seat-based vs. usage-based growth, net revenue retention drivers. Whether the technology supports the expansion model the deal thesis assumes

Customer Contract Complexity

• Contract uniformity—whether customer agreements use a standard template or are individually negotiated. A company with 200 customers on 15 different contract variations creates a different operational and compliance landscape than one with a uniform MSA. Bespoke contracts with custom SLAs, data handling requirements, or feature commitments can constrain product decisions and create hidden obligations
• Data handling obligations by contract—whether specific customer contracts impose data residency, encryption, retention, or deletion requirements beyond the company’s standard practices. Contractual commitments to store data in specific regions, maintain dedicated infrastructure, or provide customer-specific audit trails directly affect cloud architecture and cost structure
• SLA commitments and enforcement—uptime guarantees, response time commitments, and penalty clauses across the customer base. Whether current infrastructure and operational practices can meet the most demanding SLAs, and whether SLA breaches have triggered credits or penalties historically
• Custom deployment requirements—customers requiring dedicated environments, on-premise instances, VPN connectivity, or private cloud hosting. The cost of maintaining these custom deployments, whether it is recovered in pricing, and how many engineering hours per month they consume
• Usage-based pricing mechanics—if the product uses consumption-based or hybrid pricing, the metering infrastructure, billing accuracy, revenue recognition complexity, and whether usage data is auditable. Usage-based models require more sophisticated billing systems than flat-rate subscriptions and create revenue forecasting complexity

Open Source License Compliance

• Software Bill of Materials (SBOM)—whether the company maintains a current, machine-readable inventory of all open source components, their versions, and their licenses. SBOM generation should be automated as part of the build pipeline, not a manual exercise performed only during diligence
• Copyleft exposure—identification of GPL, AGPL, LGPL, and other copyleft-licensed components in the codebase. AGPL is the highest-risk license for SaaS companies because it triggers reciprocal licensing obligations when software is provided over a network, not just when distributed. A single AGPL dependency embedded in a proprietary SaaS product can, in theory, require disclosure of the entire linked codebase
• License compatibility analysis—whether the combination of open source licenses used in the product creates conflicts. Mixing GPL and Apache 2.0 code in certain configurations creates incompatibilities that require re-engineering to resolve
• Dual-licensed components—dependencies that offer both open source and commercial licenses (e.g., MongoDB SSPL, MySQL GPL). Whether the company is using the open source version within its terms or needs to procure a commercial license
• Remediation cost estimation—for any problematic license findings, the engineering effort to replace the component with a permissively licensed alternative or negotiate a commercial license. Ripping out a deeply integrated AGPL dependency can require hundreds of engineering hours

Intellectual Property Ownership

• IP assignment chain—whether all code contributors (employees, contractors, agencies, freelancers) have executed IP assignment agreements that transfer ownership to the company. Gaps in contractor IP assignment are one of the most common findings in technical diligence and can cloud title to the software asset being acquired
• Founder IP assignment—whether the founders formally assigned their pre-incorporation work to the company. This is surprisingly often missing, particularly in bootstrapped companies where the founder wrote the initial codebase before the entity existed
• Prior invention disclosures—whether employees disclosed prior inventions that may overlap with the company’s product. Undisclosed prior art owned by a key engineer creates a latent IP dispute
• Contributor license agreements—if the company maintains open source projects, whether contributors have signed CLAs granting the company rights to use contributions commercially
• Patent portfolio and exposure—whether the company holds patents (an asset), and whether a freedom-to-operate analysis has been conducted to identify potential infringement of third-party patents. NPE (non-practicing entity) exposure is an ongoing cost of doing business in certain software verticals

Export Controls & Data Sovereignty

• Export control applicability—whether the software is subject to ITAR (International Traffic in Arms Regulations) or EAR (Export Administration Regulations). Software that incorporates non-standard encryption, serves defense or intelligence customers, or processes classified data may require export licenses. The EAR classifies encryption software under ECCN 5D002, though mass-market encryption has an exemption
• Data localization requirements—jurisdictional rules that mandate where customer data must be stored. GDPR data residency expectations, sector-specific requirements (healthcare, financial services, government), and country-specific laws (China PIPL, Russia, Brazil LGPD) that affect cloud architecture decisions and multi-region deployment strategy
• Cross-border data transfer mechanisms—whether the company relies on Standard Contractual Clauses, the EU-US Data Privacy Framework, or other mechanisms for international data transfer. The legal basis for these transfers has been challenged repeatedly (Schrems I, Schrems II) and remains a moving target
• Deemed export rules—whether foreign national employees or contractors have access to export-controlled technology, which may constitute a “deemed export” requiring a license

Regulatory Exposure & Enforcement

• FTC enforcement history and exposure—whether the company has been subject to FTC investigations, consent decrees, or complaints related to data security or privacy practices. The FTC has taken action against software companies including Blackbaud and Avast for inadequate security practices, with consent orders lasting up to 20 years and requiring ongoing compliance monitoring
• SEC cyber disclosure obligations—if the target is or will become a public company, whether it complies with the SEC’s cybersecurity disclosure rules requiring material incident reporting within four business days and annual risk management disclosures. These obligations transfer to the acquirer
• State privacy law compliance—exposure under CCPA, CPRA, and the expanding patchwork of state privacy laws. Whether the company has the technical capability to honor data access, deletion, and opt-out requests at scale
• EU AI Act classification—if the product incorporates AI features and serves EU customers, whether any AI systems fall into the high-risk category requiring conformity assessments, technical documentation, human oversight mechanisms, and registration in the EU database. High-risk AI system requirements take full effect in August 2026, but classification and gap analysis should happen during diligence
• Government contract compliance—if the company sells to or plans to sell to government agencies, the compliance posture for FedRAMP (federal), StateRAMP (state), or CMMC (defense). FedRAMP Moderate authorization typically costs $250,000–$750,000 and takes 12–18 months—a material cost and timeline consideration for any deal thesis that includes government market expansion