When a $400M software buyout missed its Year 2 EBITDA target by 38% last year, the post-mortem traced the gap to a single line in the tech DD report: "monolithic architecture; refactor recommended." That sentence translated into $22M of unplanned engineering spend, a 14-month delay to the cross-sell module the LBO model depended on, and the loss of two anchor customers who moved to a cloud-native competitor. Tech due diligence is no longer a confirmatory exercise run in the final two weeks before signing. For sponsors writing checks into software, fintech, healthcare IT, or any business where the product is code, it is a quantitative discipline that adjusts purchase price, shapes the value creation plan, and underwrites the exit thesis.
This article is the fourth in our PE Portfolio Operating Model guide. Earlier articles covered AI-driven sourcing and commercial and financial diligence. Here we focus on what happens inside the codebase, the cloud account, and the engineering org — and how to convert that visibility into specific dollars on the model.
Why Tech DD Has Become a Pricing Lever, Not a Checkbox
Across the 180+ software and tech-enabled deals our practice has supported since 2021, tech DD findings drove a measurable purchase price adjustment in 31% of transactions, with the median adjustment at 4.2% of enterprise value. The categories that triggered repricing were predictable: undisclosed cloud cost run-rate (often 2-3x what management presented because reserved instances were expiring), single points of failure in critical infrastructure, and capitalized software development costs that masked the true cash cost of maintaining the existing codebase.
The leverage works in both directions. We have also seen tech DD support price increases — or more commonly, defend a sponsor's bid against competing offers — when the diligence team can document that the target's architecture genuinely supports the growth case. A SaaS company we diligenced in Q3 2025 had migrated to event-driven microservices on AWS with a documented 18-month track record of 99.97% availability through three Black Friday-equivalent traffic peaks. That evidence let our client maintain a 14.2x ARR bid against two strategics who had assumed re-platforming was required.
The Five-Layer Tech DD Framework
Effective tech DD examines five distinct layers, each with its own evidence base and its own failure modes. Treating them as a single "tech review" is the most common reason diligence reports miss the issues that later destroy value.
| Layer | What You're Measuring | Primary Evidence | Typical Red Flag |
|---|---|---|---|
| Architecture | Modularity, coupling, scalability ceiling | C4 diagrams, dependency graphs, ADRs | Single database serving all tenants |
| Code Quality | Maintainability, test coverage, complexity | SonarQube, CAST, GitHub repo analysis | Cyclomatic complexity >25 in core modules |
| Infrastructure & Cloud | Cost, reliability, IaC maturity | AWS/Azure billing, Terraform repos, SLO history | Manual deploys, no rollback capability |
| Security & Compliance | Vulnerabilities, SOC 2, data handling | Snyk, Wiz, audit reports, pen tests | PII in logs, expired certs, no MFA |
| Engineering Org | Velocity, key person risk, hiring funnel | DORA metrics, retention, org charts | Top 3 engineers own 70% of commits |
We typically spend 60% of a four-week tech DD on the first two layers, because they drive the longest-tailed remediation costs. Cloud and security findings, while often more alarming in a steering committee deck, can usually be remediated in two to three quarters with bounded spend. Architectural debt and code rot, by contrast, can require multi-year programs that fundamentally change the post-close operating model.
Quantifying Technical Debt in Dollars, Not Adjectives
The deliverable that gets read in the IC memo is a number. "Significant tech debt" does not survive the partner's red pen. We use a four-method triangulation to put a defensible dollar figure on the debt — and more importantly, to allocate it between debt that must be repaid (blocking the growth thesis) and debt that can be carried (functional but suboptimal).
Method one is static analysis. Tools like SonarQube, CAST Highlight, and CodeScene scan the repository and output remediation estimates in person-days. For a typical mid-market SaaS codebase of 1.5-3M lines of code, this usually surfaces 8,000-25,000 hours of estimated remediation. Multiply by a blended developer fully-loaded cost (we use $145/hour for US-heavy teams, $55/hour for nearshore-heavy teams in 2026) to get the first dollar estimate.
Method two is the capitalized R&D cross-check. We pull the last three years of capitalized software development costs from the financial DD workstream (covered in Article 3) and compare to feature shipped per the product roadmap. When a target capitalized $18M but shipped only two material features that customers cite in their renewal conversations, the delta is debt servicing — paid in cash, hidden on the balance sheet.
Method three is developer time allocation. Stripe's developer survey put time spent on technical debt at 33% across the industry; in our diligences, we benchmark the target by analyzing Jira/Linear ticket categorization and asking engineers directly in management interviews. Targets above 45% on tech debt and bug fixes (versus new feature work) are operating at a velocity ceiling that will not support the growth plan without intervention.
Method four is architecture-specific cost modeling. If diligence identifies that the target must migrate from a single-tenant database to multi-tenant before it can support its top-of-funnel growth, we size that program directly with a bottoms-up estimate: team composition, duration, third-party tooling, customer migration effort, and the revenue cost of feature freeze during the migration. These targeted estimates frequently land between $4M and $40M for mid-market software companies.
Stress-Testing Scalability Against the LBO Model
The investment committee approved a model with 4x revenue growth over five years. The diligence question is whether the technology stack can carry that load — or what it will cost to make it possible. We translate the model's growth assumptions into concrete technical loads: peak concurrent users, transactions per second, data volume, integration counts, geographic footprint, and tenant count.
For a B2B SaaS target growing from $80M to $320M ARR with an average ACV moving from $35K to $50K, the implied tenant count roughly triples. If diligence reveals a Postgres instance hitting 78% CPU at current load with no read replicas and no sharding strategy, the scalability conclusion is not a yellow flag in a slide — it is a $6-9M re-platforming line item that the value creation plan must accommodate.
The reporting and analytics tier is the most commonly underestimated bottleneck. Targets routinely show CEO dashboards that load in two seconds for a demo account with 10,000 rows, but break entirely when customers cross 5 million rows. Diligence should request the largest customer's actual dashboard load times — we have seen 90-second load times disclosed only after specific probing, which materially changes the renewal risk profile for top-decile accounts.
On the infrastructure side, we run a parallel analysis using cloud cost intelligence platforms — Vantage, CloudZero, or directly through AWS Cost Explorer with the target's permission. The exercise frequently reveals that 25-40% of cloud spend goes to unused or oversized resources. That finding cuts two ways: it identifies a clear quick-win for the 100-day plan, and it usually means current gross margin is artificially low. We have seen Year 1 cloud optimization deliver 180-320 bps of gross margin improvement on software portcos without touching the product roadmap.
The Modern Tech DD Tool Stack
A 2026-vintage tech DD looks nothing like the manager interviews and architecture deck reviews that defined the discipline a decade ago. Sponsors now expect diligence providers — whether internal operating teams, specialists like Crosslake, West Monroe, or Stepwise, or the tech arms of Bain, EY-Parthenon, and Alvarez & Marsal — to run an instrumented examination of the actual asset, not a paper review of its documentation.
Read access to the production repository — even time-boxed and supervised — is now the single biggest predictor of diligence quality. In transactions where sellers grant read-only Git access via a clean room, we identify 3-5x more material findings than when we are limited to architecture diagrams and management interviews. Sophisticated buyers now make repository access a deal-breaker requirement in exclusivity, not a nice-to-have.
Red Flags That Should Move Price or Kill Deals
Not every finding warrants action. Sponsors should expect tech debt in every target; the question is whether the debt is recoverable, the team is capable of recovering it, and the value creation plan accounts for it. The findings below, in our experience, warrant either a material price adjustment, a structured indemnity, or in some cases a pass.
| Tier | Example Findings | Typical Action |
|---|---|---|
| Tier 1 — Deal-Threatening | Embedded GPL code in proprietary product; PII breach not disclosed; key person owns critical IP personally; no source control history | Pass, or fundamental restructuring of deal |
| Tier 2 — Material Repricing | Re-platforming required for growth case; >40% cloud cost increase needed; founder-CTO leaving; no DR or backup tested in 12 months | 3-8% EV adjustment, escrow, or earn-out structuring |
| Tier 3 — Value Creation Plan | Test coverage <30%; manual deployments; tech debt at 12-18% TDR; documentation gaps | 100-day plan items, no price impact |
| Tier 4 — Operational Hygiene | Outdated dependencies; missing monitoring; informal incident process | Standard post-close cleanup |
Open-source license contamination remains an under-recognized Tier 1 risk. We diligenced a developer tools company in 2024 where 8% of the proprietary codebase had been copied from AGPL-licensed projects without compliance. The remediation required a six-month rewrite and significantly altered the bid. Modern SBOM tooling — Snyk, FOSSA, Black Duck — surfaces these issues in hours, but only if buyers insist on running the scans during diligence rather than after close.
The cheapest tech DD finding is the one you discover before signing. The most expensive is the one a customer discovers after.
From Diligence Findings to the Value Creation Plan
Tech DD that ends at signing is a missed opportunity. The same evidence base used to size risk during diligence should populate the 100-day plan and the longer-arc value creation roadmap. We hand off three artifacts to the post-close team: a remediation backlog with sized initiatives, a target architecture state with sequencing, and a set of operational KPIs the portfolio company will report monthly.
Five-layer assessment with instrumented tooling. Output: IC memo with sized findings, repricing recommendations, and risk register.
Translate findings into Day 1, Day 30, Day 100 initiatives. Identify interim CTO or fractional engineering leadership if key person risk identified.
Quick wins on cloud cost (typically 15-25% reduction), security hygiene, and monitoring. Initiate any required re-platforming workstreams. See Article 5 for the full integration playbook.
Execute against the architecture roadmap. Track DORA metrics monthly. Stand up engineering KPI dashboard for sponsor reporting.
Strategic upgrades — typically platform migrations, AI/ML feature investment, M&A integration capability. Position for exit.
Reverse the diligence — produce the data room artifacts a sophisticated buyer will demand. Covered in detail in Article 9.
Sponsors who run this loop well treat each portco diligence as input to a fund-level intelligence asset. The third software deal benefits from the data of the first two. Standardized tooling, repeated KPIs, and a shared engineering benchmark library mean later deals close faster and at higher confidence. Our larger PE clients now maintain proprietary benchmark databases covering 50+ portcos on metrics like cost per ARR dollar, deploy frequency, and cloud spend as a percentage of revenue — data the strategics cannot match.
What This Means for the Operating Model
The funds we see winning competitive software processes in 2026 share three habits. First, they front-load tech DD — beginning the technical review in parallel with the IOI, not after exclusivity. Second, they invest in proprietary instrumentation: tooling agreements, benchmark databases, and reference relationships with sellers' former engineers that let them triangulate management claims quickly. Third, they integrate tech DD findings directly into the LBO model rather than carrying them as qualitative risks.
The connection to the rest of the operating model is direct. Tech DD findings shape the 100-day plan (Article 5), inform which capabilities belong in shared service centers, define the cybersecurity baseline that Article 11 tracks across the portfolio, and determine whether a target needs a fractional CTO in the first 90 days. The diligence is not separate from value creation. It is the first chapter of it.