2. How tech due diligence really drives investment outcomes • EL BANTLI

The investment committee memo assumed a clean first-year ramp: $18M of EBITDA expansion from pricing discipline and sales coverage, starting in quarter two. The tech diligence summary said the target was “on Salesforce” and had “good data maturity.”

Six months after close, the pricing team still couldn’t answer a basic question: “Which customers are we underpricing, and by how much?” The CRM was Salesforce in name only—a heavily customized instance with three competing definitions of “active customer,” no reliable product master, and pipeline stages that meant different things by region. The team spent the first two quarters rebuilding data foundations and designing workarounds. Pricing moved, but a year late. The EBITDA wasn’t wrong. The timetable was.

This is what tech due diligence actually does when it’s done well: it changes the economics and the clock. Not by producing a thicker report, but by forcing a small number of decisions early enough that you still have choices.

The primary decision is simple: is tech due diligence a risk check, or an investment tool? If it’s a risk check, you get a list of issues. If it’s an investment tool, you get changes to price, timing, and the first 100-day plan.

Technology diligence should move three numbers

Most deal teams treat tech DD as a set of “findings.” Investment outcomes show up as numbers. Good diligence connects the two and moves three things explicitly:

Timing of value. When do the tech gates open for the value levers the model assumes?
One-time cash. What do you have to fund to make the plan safe (separation, integration, data fixes, security uplift)?
Run-rate EBITDA. What is the true steady-state cost to run the tech you’re buying (and what can realistically be taken out)?

If diligence doesn’t change at least one of those, it may still be accurate—but it did not do its job.

Why most tech DD fails: it answers the wrong question

The common failure mode is not “missed a risk.” It’s that the work answers “How good is their IT?” when the IC needs “What does this do to our return?”

Three patterns show up repeatedly.

Pattern 1: A long list of issues, no decision

The diligence team produces a risk register: technical debt, outdated systems, key-person risk, cyber gaps. All real. None tied to the model.

The IC doesn’t need 40 risks. It needs 4 decisions:

Do we change the bid or the structure (holdbacks, indemnities, TSAs)?
Do we change the year-one value timing?
Do we fund a specific set of fixes, with a credible ROI?
Do we change the leadership plan (hire, retain, replace)?

If the output isn’t decision-shaped, it won’t change outcomes. It becomes “good to know.”

Pattern 2: Starting from the systems, not the thesis

Many diligence efforts start with inventory: applications, infrastructure, contracts. The result is comprehensive and still misses what matters.

Example: You can map 200 applications and still fail to identify that customer master data is the gating item for revenue synergy, or that identity is the gating item for TSA exit, or that the ERP close process is the gating item for working-capital control.

Systems matter. What matters more is which systems gate the value path.

Pattern 3: Findings arrive after the deal model hardens

In fast deals, the model, the synergy timing, and the integration narrative get locked early. If diligence produces “here’s the complexity” on day 20, it’s too late. The team will rationalize the findings to protect the thesis.

Good tech DD produces an early, imperfect point of view in week one—then sharpens it. Delay the point of view and you lose the only moment it can change the deal.

What “good” looks like: a tech DD value brief, not a report

The best diligence teams aim for a single-page outcome that an IC can act on. Call it a tech DD value brief. It has five sections:

Value gates: the 3–5 technology conditions that must be true to deliver the deal thesis on the assumed timeline.
Model changes: what you are changing in the deal model (timing, one-time, run-rate) and why.
Deal constraints: contractual, regulatory, or architectural constraints that limit optionality (licenses, data residency, long-term vendor commitments).
Day-1 risk posture: what must not break, and the minimum viable Day-1 design.
First 100 days: the few moves that de-risk the thesis fastest, with an owner.

You can still append detailed inventories. But if you can’t fit the outcome on one page, you don’t yet know what matters.

Build diligence around value gates

A practical way to drive outcomes is to run diligence as a “gate hunt.” Start with the investment thesis and force an explicit mapping to technology.

Step 1: Translate the thesis into 3–5 business levers with dates

Not “synergies.” The actual programs and timing the model assumes:

price harmonization by quarter two
consolidated procurement compliance by month six
cross-sell motions live by month four
close books on a single chart of accounts by month nine

If the deal team can’t name the levers with dates, diligence will drift into generic assessments.

Step 2: For each lever, name the technology gate

Examples of real gates that change timing:

Pricing discipline requires a unified customer and product master and a quoting workflow you can enforce.
Procurement savings require vendor master cleanup and approval flows aligned to new policies.
Working-capital control requires a stable close process and consistent definitions of AR aging and “on-time delivery.”

This is where diligence becomes investment work. The question is not “Is the CRM modern?” It’s “Can we enforce the pricing process by the date the model assumes?”

Step 3: Pressure-test each gate with evidence, not interviews

Interviews produce confidence. Evidence produces truth.

Ask for artifacts that are hard to fake:

last two month-end close calendars and issue logs
incident history for critical customer-facing systems
top 20 integrations and who owns them (with diagrams or tickets)
data dictionaries for the metrics the model assumes (customer, margin, churn)
security audit results and open findings (not just a policy deck)

If the target can’t produce evidence quickly, that is a finding. It means the organization can’t run change at speed—and speed is what the model is buying.

Quantify what changes the return

“High/medium/low” risks don’t change returns. Numbers do. You don’t need perfect precision. You need a range that forces a decision.

1) Timing: make synergy gates explicit

Convert gates into dates and dependency logic.

Example: If revenue synergy depends on a single view of customers, diligence should answer:

How many customer identifiers exist today?
Is there a current customer master, or will you have to build one?
Can you enforce quoting and pricing rules in the current stack?

Then turn that into a gate date:

If customer and product master can be stabilized in 10–12 weeks, quarter-two pricing is plausible.
If master data is fragmented across regions and owned by no one, assume 6–9 months for a workable foundation and move the synergy ramp.

The point is not to be “right.” The point is to stop the team from committing to a timetable the systems can’t support.

2) One-time cash: separate “must spend” from “nice to have”

Deals often underestimate one-time tech spend because teams mix three buckets:

Mandatory spend: Day-1 continuity, separation work, TSA exit, security remediation required to operate.
Value unlock spend: data foundation, process automation, integration tooling that accelerates the thesis.
Preference spend: architecture modernization that feels good but does not change the thesis in year one.

Good diligence labels the bucket and ties it to either risk avoidance or value timing.

Decision trigger: If mandatory one-time spend exceeds 30–40% of year-one synergies, the deal is still viable—but the sequencing must change. You either accept slower value capture, or you fund the program and protect Day-1 with a narrower scope.

3) Run-rate EBITDA: model offsets, not just savings

The biggest diligence miss is counting gross IT savings and ignoring offsets.

When you remove duplicate tools, costs don’t fall cleanly. They shift:

license true-ups when you exit a seller’s enterprise agreement
parallel run costs during transition (two systems, two teams, two support contracts)
contractors and integration tooling to make the change safe
new security controls the buyer requires (and the target didn’t fund)

What good looks like: for any “IT synergy” line, diligence should produce two numbers:

Gross savings (what you could retire)
Net savings (after the costs you will add to avoid disruption)

If diligence can’t identify the offsets, you don’t have savings. You have hope.

Five deal decisions tech DD should force

The fastest way to make diligence matter is to anchor it to explicit decisions the IC will recognize.

Decision 1: Reprice, restructure, or accept the risk

When a tech risk is real, you have three levers: change price, change structure, or accept.

If/then triggers:

If there is no credible path to Day-1 stability without major new build, push risk into structure (holdbacks, transition support) or reprice.
If cyber remediation is required to operate in your environment, treat it as mandatory one-time cash (not an “IT improvement”) and fund it in the deal case.

Decision 2: Separation vs integration posture on day one

Even in full acquisitions, you still choose how tightly you connect early. In carve-outs, you choose how dependent you remain.

If/then triggers:

If TSA is under 9–12 months and shared identity/network is in scope, assume early stand-up work and price it as mandatory.
If the thesis requires fast cross-sell, prioritize interoperability (data + workflow) over platform replacement in year one.

Decision 3: What not to do in the first 100 days

Most deals overcommit. Diligence should identify the landmines and force explicit deferrals.

If/then trigger: If the target has fragile operations (high incident volume, tight SLAs, thin support), do not combine core systems in the first 100 days. Stabilize, build observability, and separate Day-1 continuity from value capture.

Decision 4: The management and capability plan

A weak tech function doesn’t just raise risk. It slows value.

Diligence should name:

the key-person dependencies (and what happens if they leave)
the missing roles required for the deal plan (integration lead, enterprise architect, data owner, security lead)
the minimum team you need by close vs by Day 100

Decision trigger: If 2–3 people hold the integration knowledge for critical systems, retention is not optional. Price retention and backfill as mandatory.

Decision 5: Where to invest for return (and where not to)

Not every tech weakness is worth fixing inside the hold period. The question is ROI and timing.

Good diligence makes a short list of investments that directly accelerate the thesis (and a short list of improvements to defer).

If/then trigger: If a modernization effort does not open a value gate in the first 12 months, don’t make it a deal dependency. Keep it as a year-two option with a separate business case.

What to do in the next two weeks

If you want tech DD to change investment outcomes, run these actions on a tight clock:

Run a 60-minute “value gate” working session (deal lead + finance + tech lead). Output: top 5 value levers, their tech gates, and the assumed gate dates.
Ask for evidence early, not narratives late. Close calendars, incident logs, integration maps, data dictionaries, security findings.
Force three numbers into the model. Move synergy timing, quantify mandatory one-time cash, and adjust run-rate IT cost for offsets.
Write the first 100 days as a list of decisions, not tasks. What you will not attempt matters as much as what you will.
Turn findings into owners. One owner for Day-1 continuity, one for value capture, one for tech cost and architecture choices.

Tech due diligence doesn’t create value by finding problems. It creates value by changing what the team commits to—price, timing, and the sequence of work—while there is still time to choose.