What Technical Due Diligence Actually Examines
Technical due diligence for private equity is the process that tells a deal partner whether the technology underneath the investment thesis will hold. It is not a penetration test, a code-quality audit, or a vendor assessment—those are downstream activities once you own the asset. The TDD engagement runs in parallel with commercial and financial diligence, typically during the 30–60 day exclusivity window after the LOI is signed, though the sharpest sponsors now run a lighter pre-LOI checkpoint to surface deal-killers before they commit legal spend.
The review covers five domains: product architecture and scalability, security posture and compliance readiness, technology organization and key-person risk, infrastructure and third-party dependencies, and the product roadmap’s technical feasibility. Each domain maps to a specific deal risk. Architecture determines whether the platform can scale to the revenue number in your model without a rebuild. Security and compliance tell you whether you are buying a breach waiting to happen or a SOC 2 audit that fails in month six. The organization review flags whether the entire engineering capability walks out the door when the founding CTO vests and leaves. Infrastructure and dependencies surface the operational fragility—services running on personal accounts, APIs near rate limits, contracts that reprice at scale. The roadmap assessment confirms whether the features the seller promised in the CIM are technically possible in the timeframe the thesis assumes, or whether you are underwriting vaporware.
Most technical due diligence engagements run five business days of on-site or remote work: day one is documentation review and stakeholder interviews, days two through four are technical examination and testing, and day five is findings synthesis and report drafting. The output is a written findings memo, typically 20–40 pages, structured around the risks that would adjust your bid or change deal terms. Each finding is tagged by severity—critical findings reprice the deal or trigger escrow, high findings require a remediation plan pre-close, medium findings go into the 100-day operating plan, and low findings the portfolio company can manage on their own timeline. The report also includes a technical health score, a roadmap feasibility assessment, and a post-close remediation budget with timelines.
A quality engagement also delivers an executive summary the deal partner can forward to the IC without translation. The summary answers four questions: does the technology support the growth thesis, what are the top three technical risks to enterprise value, what is the cost and timeline to remediate critical findings, and should this deal proceed. That last line is the one most TDD providers will not write. A real technical due diligence partner states a recommendation—proceed as priced, proceed with valuation adjustment, proceed with specific reps and escrow, or do not proceed. If the report does not land on one of those four, you bought activity, not a decision input.
Who This Engagement Is For
Technical due diligence is essential for any deal where the product or platform is load-bearing in the thesis. That includes SaaS and software businesses, where the entire revenue stream runs through code; digital platforms and marketplaces, where transaction volume and uptime are the model; hardware companies with embedded software or a connected device architecture; services businesses that depend on proprietary tools, automation, or a data platform to deliver margin; and increasingly, any target where AI, machine learning, or data infrastructure is part of the value-creation plan. If your IC deck mentions ARR growth, product-led acquisition, platform scalability, automated workflows, or customer data insights, you are underwriting technology—and you need someone who can read what you are buying.
The engagement is also critical when the deal involves a technical founder departure, a post-close platform migration, or a planned integration with another portfolio company. A founder-led engineering org often has no documentation, no separation between personal and business infrastructure, and a codebase only two people understand. The TDD surfaces that dependency before the earnout negotiation, not six months post-close when the founder is unreachable and the product is on fire. Similarly, if your value-creation plan includes moving the target’s app to AWS, consolidating it into a shared platform, or integrating it with another portco’s stack, the TDD tells you whether that migration is a six-week IT project or an eighteen-month rebuild that blows up your returns model.
Most sponsors commission TDD on deals above $50 million in enterprise value, or on any software/SaaS deal regardless of size. The calculus is simple: a $15,000 read that finds a critical架构 flaw, a hidden compliance gap, or a technical founder risk you can escrow against has already paid for itself in valuation protection. The cost of skipping it is a post-close finding that reprices the deal in the seller’s favor—or worse, a breach, outage, or product failure that destroys the asset you just bought.
What a Five-Day Engagement Delivers
Day one starts with a documentation request and stakeholder interviews. The TDD team asks for architecture diagrams, infrastructure runbooks, security policies, disaster recovery plans, third-party vendor contracts, the product roadmap, recent sprint backlogs, and any prior audits—SOC 2 reports, penetration test results, code reviews. Most targets have some of these and none of the others, which is itself a finding. The interviews run with the CTO, lead engineers, the product owner, IT/DevOps, and often the seller’s deal team to confirm what was promised in the CIM versus what actually exists. These sessions surface the gaps between what the exec team believes is true and what the engineering team knows is real.
Days two through four are the technical examination. The team reviews the codebase for architecture red flags—monolithic structures that cannot scale horizontally, hard-coded configurations that break in a new environment, missing abstraction layers that make the product impossible to extend. They test the infrastructure for single points of failure, examine the disaster recovery plan by asking what happens if AWS us-east-1 goes down, review third-party dependencies for vendor lock-in or contracts that reprice at volume, and map the data flows to confirm customer data is actually segregated and encrypted the way the DPA claims. Security work includes checking for common vulnerabilities, confirming the patch management process exists, reviewing access controls, and testing the incident response plan—usually by asking what happened the last time something broke and whether anyone wrote it down.
The organizational review is where most deal-breaking findings live. The team maps who knows what, identifies key-person dependencies, reviews recent turnover, checks compensation benchmarks against local market rates, and evaluates the technical debt backlog. A common finding: the entire platform was built by one senior engineer who is underpaid by 40%, has no documentation, and is leaving the day the deal closes. That finding does not kill the deal, but it does mean you either pay that engineer to stay, plan a six-month knowledge-transfer sprint, or adjust your valuation to account for rebuilding institutional knowledge from scratch.
Day five is synthesis and reporting. The findings are classified by severity, mapped to deal risks, and translated into business language. A critical finding might read: “Customer data is stored unencrypted in an S3 bucket accessible via a URL hardcoded in the mobile app. Any user can enumerate and download the full customer database. Remediation cost: $40K and three weeks. If this is discovered post-close, you are reporting a breach to regulators in 47 states and notifying 280,000 customers. Estimated legal and remediation cost: $1.2M plus brand damage.” That is not a technology problem; that is a $1.2M adjustment to your bid or a condition precedent to closing.
The deliverable package includes the written findings report, an executive summary with a proceed/adjust/walk recommendation, a remediation roadmap with cost and timeline estimates, a technical health scorecard the operating partner can track post-close, and often a prioritized 100-day plan that sequences the critical fixes. The best TDD partners also include a post-close call where they walk the operating team through the findings and help them build the remediation plan into the value-creation roadmap. The report is not the end of the engagement; it is the start of the fix.
Pros: What This Process Gets Right
The primary advantage of a structured technical due diligence process is that it surfaces risks the quality-of-earnings and commercial diligence will never touch. A QoE reviews revenue recognition and EBITDA adjustments; it does not test whether the platform can handle 10x user growth or whether the AWS bill scales linearly with customers. A market study confirms TAM and competitive position; it does not tell you the product roadmap the seller promised is technically impossible without a ground-up rewrite. TDD fills the gap between what the financial model assumes and what the technology can actually deliver.
The five-day structure is also well-suited to the deal timeline. Most LOIs grant 30–60 days of exclusivity for diligence, and TDD can run in parallel with other workstreams without blocking progress. The engagement is scoped and priced upfront, which makes it easy to budget and approve—unlike open-ended consulting arrangements that drift. For sponsors operating in software, SaaS, or digital markets, technical due diligence has become as standard as financial and legal diligence, and its absence in a deal process is now a red flag to LPs and co-investors.
The process also benefits from being led by practitioners, not theorists. The best TDD teams are former CTOs, lead engineers, and DevOps architects who have built and scaled products themselves. They know what good looks like, they can spot架构 shortcuts in minutes, and they speak both the technical language the engineering team uses and the business language the deal partner needs. That bilingual capability is what makes the findings actionable—every critical finding maps to a dollar impact, a timeline, and a decision point.
Finally, the pre-LOI checkpoint option is one of the highest-ROI diligence tools available. For $5,000 and two days, a sponsor can surface the three or four deal-killing technical risks before signing exclusivity and spending $200K on legal and financial diligence. If the checkpoint finds that the platform is held together with duct tape, the founding engineer is leaving, and the AWS bill quintuples at the revenue target in your model, you can walk before you are locked in. The $5,000 typically credits into the full TDD if you proceed, so the incremental cost is zero—and the option value is saving six weeks and $200K on a deal that was never going to close at the proposed valuation.
Cons: What This Approach Misses
The main limitation of a five-day technical due diligence engagement is that five days is not enough time to read every line of code or test every integration. The review is risk-focused and sample-based: the team examines the most critical modules, the highest-traffic endpoints, the core data flows, and the areas the interviews flagged as risky. They do not review the entire codebase, test every feature, or replicate the production environment and run load tests. If a critical vulnerability or架构 flaw lives in a module they did not examine, it will not appear in the report. The process is a risk assessment, not a guarantee.
The engagement is also only as good as the target’s cooperation. If the seller restricts access to code, limits interview time, or withholds documentation, the TDD team has to work with what they can see—and the report will flag that lack of access as a risk itself. Some sellers view TDD as an adversarial process and treat it like a negotiation, which defeats the purpose. A quality TDD requires transparency, and if the seller is not willing to provide it, that is a signal in itself.
Another gap is that TDD typically does not include user acceptance testing, customer interviews, or product-market fit validation. The review confirms the product works as described and can scale to the model’s assumptions, but it does not confirm customers actually want it or that the roadmap is building the right features. That is the commercial diligence team’s job, and the two workstreams need to coordinate—but they rarely do. A common failure mode is a TDD that confirms the platform is technically sound while the commercial team discovers the product is losing customers because a competitor shipped the features the target has been promising for two years.
The final limitation is that the findings report is a snapshot at a point in time, typically 30–45 days before close. Technology environments change fast—new vulnerabilities are disclosed, engineers quit, infrastructure providers change pricing, compliance requirements shift. A finding that was low-severity in June can become critical in August if a new regulation takes effect or a key vendor announces end-of-life for a service the platform depends on. The best sponsors treat the TDD report as a living document and re-verify critical findings in the week before closing, but most do not—and that gap has torpedoed deals when a condition precedent was met in diligence but had regressed by the time the wire transferred.
Pricing Reality and Market Comparables
Technical due diligence pricing typically ranges from $10,000 to $25,000 for a standard five-day engagement covering a single product or platform. The $15,000 midpoint is common for mid-market deals ($30M–$200M enterprise value) with a defined scope—one application, one infrastructure environment, and a cooperative target. Pricing increases with complexity: multiple products, distributed teams, legacy systems, or restricted access can push the engagement to $20K–$25K. Larger deals above $200M in enterprise value, or targets with complex multi-tenant SaaS architectures, often run $30K–$50K and extend to ten or fifteen days.
The pre-LOI checkpoint is usually priced at $5,000 and scoped to two days. The team focuses on the top three technical risks: can the platform scale to the model, is there catastrophic security debt, and is there a key-person dependency that will blow up post-close. The checkpoint does not deliver a full findings report, but it does deliver a clear proceed/negotiate/walk recommendation and a rough remediation budget. The $5,000 fee credits into the full TDD if the deal proceeds, so the net cost is zero—and the option value is enormous.
Comparing this to alternatives: a Big Four firm will charge $50K–$150K for a comparable engagement, deliver it in PowerPoint with 80 slides of process description and 3 slides of findings, and staff it with associates who have never shipped production code. A boutique TDD firm founded by former operators will charge $15K–$30K, deliver a written memo with severity-tagged findings and a remediation roadmap, and staff it with people who have built what you are buying. The quality delta is larger than the price delta.
Some sponsors try to skip external TDD and have their internal platform team or a portfolio-company CTO conduct the review. This works when the internal team has diligence experience, available capacity, and no conflict of interest—but it rarely does. A portco CTO reviewing a competitor is not objective, and a platform VP who has never run diligence does not know what findings matter to the deal partner. The false economy is spending zero on TDD, missing a critical finding, and then spending $500K post-close remediating something that would have repriced the deal or been held in escrow.
Alternatives: What Else Deal Partners Use
The most common alternative to a structured technical due diligence engagement is conducting the review in-house using internal resources—either the sponsor’s platform team or a trusted portfolio-company CTO. This approach works well when the internal team has prior diligence experience, understands what findings map to deal risk, and can commit the time during the exclusivity window. The advantage is zero external cost and institutional knowledge of the sponsor’s operating playbook. The disadvantage is that internal teams often lack objectivity, may not have expertise in the target’s specific technology stack, and tend to focus on technical elegance rather than deal-breaking risks. Internal reviews also carry reputational risk if the team misses a critical finding, because there is no third party to point to when the LP asks what went wrong.
Another alternative is the Big Four accounting and advisory firms, which offer technology due diligence as part of their transaction services practice. These engagements typically cost $50K–$150K and are staffed by consultants who follow a standardized methodology and deliver findings in a detailed PowerPoint deck. The advantage is brand credibility and a defensible process you can show your IC and LPs. The disadvantage is that the findings are often generic, the team is rarely hands-on technical, and the output is designed to protect the firm from liability rather than to give the deal partner a clear decision input. A common complaint is paying $80K for a report that says “the target’s technology environment exhibits moderate risk consistent with a company of this scale and maturity,” which tells you nothing you could not have guessed from the CIM.
Some sponsors commission a security audit or penetration test and treat that as sufficient technical diligence. This is a category error. A pentest tells you whether the application is vulnerable to common attacks; it does not tell you whether the架构 can scale, whether the roadmap is feasible, or whether the engineering org will collapse post-close. Security is one domain within technical due diligence, not a replacement for it. The right sequence is TDD first to surface the critical risks, then a targeted pentest on high-risk areas the TDD flagged—not a pentest in isolation.
Finally, some deals proceed with no technical diligence at all, either because the sponsor does not view technology as material to the thesis or because the deal timeline is compressed and there is no time. This works when the target is a services business with minimal technology exposure, or when the sponsor has deep in-house technical capability and plans to replace the entire platform post-close anyway. It does not work when the thesis depends on product scalability, customer data, or a technical roadmap—and it has produced some of the most expensive post-close disasters in recent PE history. Skipping TDD to save $15K on a $100M deal is not risk management; it is gambling.
Final Verdict: When This Engagement Pays for Itself
Technical due diligence for private equity is essential for any deal where the product, platform, or technology infrastructure is load-bearing in the investment thesis. The five-day engagement model is well-suited to the deal timeline, delivers findings a deal partner can act on, and costs a fraction of a percent of deal value. The $15,000 typical fee is the lowest-cost insurance available when you are underwriting a SaaS multiple, a product roadmap, or a digital platform. The pre-LOI checkpoint at $5,000 is even sharper—it surfaces the three deal-killing risks before you are locked into exclusivity, and it credits into the full engagement if you proceed.
The process works best when the target cooperates, the scope is clearly defined, and the TDD partner is a practitioner who has built and scaled products themselves. It works least well when access is restricted, the engagement is staffed by junior consultants following a checklist, or the findings are delivered in a format the deal partner cannot use. The delta between a quality TDD and a checkbox exercise is larger than the delta between a $15K engagement and a $50K one, so the selection of the TDD partner matters more than the price.
For sponsors operating in software, SaaS, digital platforms, or any sector where technology is central to value creation, technical due diligence is now table stakes. The absence of TDD in a deal process is a red flag to co-investors and LPs, and the post-close cost of a missed finding is typically 10x–100x the cost of the engagement. The recommendation is straightforward: if your IC deck mentions ARR, product-led growth, platform scalability, customer data, AI capabilities, or a technical roadmap, commission a TDD. If the thesis is built on any of those, run the pre-LOI checkpoint before you sign exclusivity. The $5,000 you spend on the checkpoint will either confirm you can proceed with confidence or save you $200K in wasted diligence spend on a deal that was never going to close at the proposed valuation.
The final test: if a critical security finding, a scalability ceiling, or a key-person dependency surfaced three weeks before closing and repriced your deal by $2M, would the $15,000 TDD fee have been worth it? That is not a hypothetical. That is the base case.
How to Commission Technical Due Diligence: Practical Sequencing
The mechanics of engaging a TDD partner are straightforward, but the timing determines how useful the findings are. The ideal sequence is: (1) initial screening and thesis development, (2) pre-LOI technical checkpoint if technology is material to the thesis, (3) LOI execution with TDD findings incorporated into valuation or closing conditions, (4) full TDD during the exclusivity period, and (5) integration planning that uses the TDD findings as the technical baseline. Most sponsors compress this: they sign the LOI first, then discover in week six of an eight-week exclusivity window that the platform cannot scale and the roadmap is fiction. By then the deal momentum makes it nearly impossible to reprice or walk, and the finding becomes a post-close problem instead of a pre-close negotiating point.
The pre-LOI checkpoint solves this. Before you commit to exclusivity, before you spend $200K on full diligence, run a three-day technical assessment focused on the three questions that kill deals: Is the architecture fundamentally sound or will it require a rebuild? Are there critical dependencies on individuals, vendors, or legacy systems that create key-person or continuity risk? Is the product roadmap the management team is selling technically feasible with the existing stack and team, or is it aspirational? A $5,000 engagement answers those in 72 hours. If the answers are clean, proceed to LOI and full TDD. If any of the three surfaces a red flag, you either reprice before you sign or you walk before you are locked in.
The full TDD engagement should start within the first week of exclusivity, not in week five when every other workstream is already running. The reason is sequencing: financial, legal, and commercial diligence all depend on assumptions about what the technology can do, how much it will cost to maintain, and whether the roadmap is real. If the TDD finds that the platform needs a $1.5M rebuild, that changes the QoE analysis, the working capital model, and the first-year EBITDA bridge. Discovering that in week seven means every other workstream has to revise their conclusions, and there is no time. Discovering it in week two means the cost gets built into the model and either addressed in the purchase price or structured as a post-close escrow.
Access is the other variable the sponsor controls. The TDD partner needs direct access to the CTO or VP Engineering, read access to the code repository, architecture documentation, the product roadmap, the sprint backlog, and the infrastructure monitoring dashboards. They also need to speak to at least two engineers who were not selected by management. If the target restricts access to a prepared slide deck and a single management interview, the TDD will be surface-level and the findings will be useless. The LOI should specify TDD cooperation as a closing condition, and the scope should be defined in the data room access letter so there is no ambiguity about what the TDD partner is entitled to review.
What Disqualifies a TDD Partner
Not every firm that offers technical due diligence is competent to deliver it, and the delta between a practitioner-led TDD and a checklist-driven one is the difference between findings you can act on and a report that sits in the data room unread. The first disqualifier is a team that has never built or scaled a product themselves. If the lead consultant’s background is audit, compliance, or advisory and they have never been accountable for uptime, performance, or shipping a release, they will surface compliance gaps and missing documentation but they will miss the engineering judgment calls that determine whether the platform can scale or the roadmap is real. A pentest specialist can tell you whether the application is vulnerable to SQL injection; they cannot tell you whether the microservices architecture is over-engineered for the current scale or whether the technical debt is manageable or terminal.
The second disqualifier is a junior team executing a standardized checklist. Some firms staff TDD engagements with analysts two years out of university running a fixed question set, then package the answers into a templated report. The output looks professional, but the findings are generic and the risk ratings are often inverted—low-severity issues flagged as critical because they match a keyword, and actual deal risks missed because they require judgment to identify. The test is simple: ask who will be on-site or on the calls, review their LinkedIn profile, and confirm they have hands-on engineering experience at a company that scaled a product. If the answer is a rotation of junior staff supervised remotely, walk.
The third disqualifier is a dependency on management-prepared materials. A TDD that relies entirely on slide decks, architecture diagrams drawn for the diligence process, and interviews with the executives selling the business will produce findings that confirm the thesis, not findings that test it. The TDD partner needs to review actual code, actual infrastructure configurations, actual incident logs, and actual sprint velocity data. They need to talk to engineers who will tell them what is really broken. If the TDD firm is unwilling to request that level of access or the target refuses to provide it, the engagement will not deliver decision-quality findings.
The final disqualifier is a firm that cannot translate technical findings into financial impact. A report that says “the database is not optimized” or “there is technical debt in the codebase” is useless to a deal partner. A report that says “the database architecture will require a $400K migration to support the growth plan, and the technical debt will slow feature delivery by approximately 30% until it is addressed, which will delay the roadmap by two quarters and reduce Year 2 EBITDA by an estimated $1.2M” is a report the IC can use. If the TDD partner cannot make that translation, hire a different partner.
The Bottom Line
Technical due diligence is the lowest-cost, highest-ROI risk control available in any deal where technology is load-bearing to the thesis. The $15,000 engagement cost is a rounding error on a $100M transaction, and the $5,000 pre-LOI checkpoint is the sharpest tool available for de-risking a deal before you commit to exclusivity. The sponsors who skip TDD or delegate it to a checkbox exercise are not saving money—they are deferring a much larger cost to post-close, when the finding surfaces as a missed revenue target, a platform outage, or a key-person departure that takes the entire engineering team with them.
The right TDD partner is a practitioner who has built and scaled products, who will review actual systems rather than management presentations, and who can translate technical findings into financial impact. The engagement should start early in the exclusivity period, not at the end, and the findings should feed into the valuation model, the purchase agreement, and the 100-day plan. Done correctly, TDD either confirms the thesis and de-risks the deal, or it surfaces the findings that reprice the transaction or kill it before you waste six weeks and $500K on a deal that was never going to work at the proposed valuation.
If your thesis mentions product, platform, scalability, ARR, technical roadmap, or customer data, commission the TDD. If it mentions any of those and you are about to sign an LOI, run the pre-LOI checkpoint first. The $5,000 you spend will either give you the confidence to proceed or save you the $2M mispricing you would have discovered too late to fix. That is not a hedge. That is the trade.
Appendix: The Pre-LOI TDD Checkpoint—What It Actually Covers
The pre-LOI checkpoint is a compressed engagement, typically delivered in 48 to 72 hours for $5,000 to $8,000, designed to surface deal-breaking technical risks before you commit to exclusivity. It is not a full TDD—it will not produce a 60-page report with remediation timelines and cost estimates—but it will answer the three questions that determine whether the deal is structurally sound enough to proceed to exclusivity: Is the technology real? Is it defensible? And is the team capable of executing the roadmap the thesis depends on?
The checkpoint starts with a 90-minute call with the CTO or head of engineering, during which the TDD partner reviews the architecture, the deployment infrastructure, the dependency map, and the technical roadmap. The questions are specific: What is the current stack? What is the deployment cadence? What percentage of the codebase is proprietary versus open-source or licensed? What is the average time to resolve a P1 incident? What is the current sprint velocity, and has it been declining? The answers to those questions will either confirm that the platform is stable and the team is functional, or they will surface red flags—declining velocity, unresolved P1s, a CTO who cannot explain the architecture without referring to a slide deck—that indicate the deal needs repricing or the thesis needs adjustment.
The second component is a review of actual artifacts: the most recent sprint board, the incident log from the past 90 days, the dependency manifest, and the infrastructure diagram. The TDD partner is looking for patterns. A sprint board with a backlog of 400 tickets and a completion rate of 12 tickets per sprint indicates either understaffing or a team that cannot ship. An incident log with three P1s in 90 days that were all resolved within four hours indicates a functional ops team. An incident log with three P1s in 90 days that are still open indicates a team that cannot triage, which means the platform will not survive the growth plan. A dependency manifest that shows 80% of the codebase relies on a single third-party API with no redundancy indicates a single point of failure that the IC needs to price.
The third component is a code-quality spot check. The TDD partner does not review the entire codebase—that is the full TDD engagement—but they do pull a representative sample: the core transaction logic, the authentication layer, the database queries that handle the highest-volume operations, and the deployment scripts. They are looking for immediate disqualifiers: hardcoded credentials, unvalidated user inputs, SQL injection vulnerabilities, or deployment scripts that require manual intervention. If the spot check surfaces any of those, the deal either reprices or stops. If the spot check is clean, the checkpoint proceeds.
The output is a two-page memo delivered 48 hours after the initial call. The memo answers three questions: Can the platform support the growth plan? Are there immediate risks that would require a valuation adjustment or a post-close remediation budget? And is the technical team capable of executing the roadmap? The memo does not include remediation timelines, cost estimates, or a prioritized backlog—that is the full TDD—but it does include a clear recommendation: proceed to exclusivity, proceed with a valuation adjustment, or walk. If the recommendation is to proceed, the memo identifies the areas that require deeper review during the full TDD engagement. If the recommendation is to reprice, the memo quantifies the adjustment—typically a percentage of the purchase price or a specific dollar amount to be held in escrow for post-close remediation. If the recommendation is to walk, the memo explains why the platform cannot support the thesis at any reasonable valuation.
The checkpoint does not replace the full TDD. It eliminates the deals that should never have reached exclusivity, and it informs the valuation discussion before the LOI is signed. The $5,000 cost is a rounding error on the diligence budget, and the 48-hour turnaround means it fits into the negotiation timeline without delaying the process. The sponsors who skip it are not saving time—they are deferring the moment when they discover the platform cannot scale, the team cannot ship, or the roadmap depends on technology the target does not own. By then, they are in exclusivity, the seller knows they are committed, and the findings either get ignored or get priced as a post-close problem that becomes the portco CEO’s mandate in month one. That is not diligence. That is a liability transfer dressed up as a transaction.