The 100-day technology plan: from DD findings to value creation

The deal closed. The technology value creation plan is where private equity earns the multiple, and the raw material for it already exists: the due diligence report the deal team argued over three months ago and nobody has opened since. That report is the map; the first hundred days are the route.

The distinction matters because the DD report is organized by severity, which is the right order for negotiating and the wrong order for executing. After closing, the question changes from "what is this worth" to "what do we do on Monday". Here is how we translate one into the other.

From risk register to value-creation route

A risk register ranks findings by what threatens the thesis. A plan sequences them by dependencies and return on effort, and the two orders rarely match. Some critical findings do come first regardless: an exposed credential or an unencrypted backup gets fixed in week one because the downside is unbounded. But many high-severity items, say a database that will not survive three years of growth, can wait a quarter behind an enabler like test coverage, because attempting the migration without a safety net turns one risk into two.

Three sequencing rules serve well. Anything with unbounded downside goes first. Enablers go before the work they de-risk. And nothing enters the first hundred days unless it removes a named risk or measurably speeds up delivery. If the deal team never walked you through the register, start with how to read the DD report and pull the priced findings out of it.

Days one to thirty: stop the bleeding, start the meter

The first month has two jobs. The visible one is quick wins: rotate every credential that appeared in the report, restore one backup for real to prove recovery works, put monitoring on the revenue paths, and cap the cloud spend anomalies that almost every audit surfaces. Each takes days, each removes real risk, and together they buy the new owner credibility with the engineering team, who usually knew about all of them.

The invisible job matters more: baseline the metrics. Deployment frequency, incident count and recovery time, infrastructure cost per customer, delivery against plan. In month six the board will ask whether the technology investment changed anything, and without a day-thirty baseline that argument cannot be won. It is the same discipline we push when pricing technical debt: numbers first, narrative second.

Days thirty to one hundred: the structural work

With the floor secured, the structural work starts, and the selection principle is relevance to the roadmap rather than engineering preference. Left alone, engineers refactor what annoys them. The plan should fund the debt that blocks the value-creation thesis: the tangled module standing between the company and the enterprise tier, the manual deployment that caps release cadence, the single-tenant architecture that turns every new customer into a project.

The same discipline applies to the AI line that most 2026 plans carry. The first AI move should be boring, measurable, and shipped inside the quarter: document processing in operations, an internal assistant on support knowledge, extraction in the back office. We have watched portfolio companies chase a flagship AI feature for two quarters while a plain workflow automation would have paid for the whole program. Choosing a first AI use case has its own note, and the short version is that boring beats impressive.

What to staff, what to bring in

Three sourcing decisions cover most cases. When DD flagged the technical leadership itself, an interim or fractional CTO comes first, because every other decision runs through that seat. Bounded, definable work (a migration, the first AI build, a security remediation sprint) suits an outside team that arrives with pattern knowledge from other deals and leaves behind a system the internal team runs. Permanent hires are for permanent capabilities, and they take a quarter to land, so the job openings go out in week one even though the people arrive after day one hundred.

The mistake to avoid is the reverse mapping: hiring permanent staff for one-off remediation, or handing the core product to an agency forever.

Day one hundred: what done looks like

Nobody empties a risk register in a hundred days, and nobody should try. Done means: every item with unbounded downside closed, the baseline published and moving in the right direction, the structural work staffed and visibly underway, and one AI use case in production with a measured result. That makes a defensible board slide. It also gives the engineering team proof that the change of ownership changed something concrete.

This translation from findings to route is why our audits do not stop at the risk register. The deliverables of a technical and AI due diligence include a value-creation plan, so the document the investment committee used to price the deal is the one the operating team opens on day one.