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

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

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

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

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

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

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

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

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