You just closed. The ink is dry, the wire transferred, and someone from your deal team is now technically responsible for a software company whose codebase nobody on your team has ever seen. The existing management team is either nervous, protective, or both. Engineering is watching to see what happens next.
You have about 90 days before the window closes on first impressions and easy access to honest information. Here’s how to use them.
Week One: Stop, Look, Listen
Before you touch anything, orient yourself. Your job in week one is not to make decisions — it’s to understand what decisions you’re actually facing.
Get answers to four questions immediately:
Who actually runs the technology? This is almost never the org chart answer. In most software companies under $50M ARR, one or two engineers carry disproportionate institutional knowledge. Find them. The CTO title may sit on someone who is primarily a manager, a salesperson, or a founder who has drifted away from the codebase. You need to know who would hurt most to lose.
What does the system do when it breaks? Ask for the last three major incidents. Ask who responded, how long it took, and what the root cause was. This tells you more about operational maturity than any architecture diagram.
What are customers actually paying for? Not what the product deck says. Ask support to pull the top 20 tickets from the last 90 days. The gap between what the company thinks it sells and what customers actually need is where technical debt hides.
Is there a roadmap, and does engineering believe in it? Ask two engineers separately what the company is building next and why. If the answers diverge, the planning process is broken.
Weeks Two Through Four: The Independent Assessment
This is where most PE firms make their first mistake. They ask the existing CTO to self-assess, or they send in a consulting firm that does a checkbox audit. Neither tells you what you actually need to know.
You need someone technically credible who has no stake in the outcome to spend two to three weeks doing a real assessment. This means reading the code, not just interviewing the team. It means looking at deployment history, test coverage, dependency age, and cloud spend. It means talking to engineers privately — not in rooms where their manager is present.
What you’re looking for in this assessment:
Architecture risk. Is the system built in a way that scales with the business, or did it get bolted together to hit milestones? Monoliths aren’t automatically bad. Tangled microservices with no documentation aren’t automatically good. What matters is whether the architecture creates or limits your options.
Key person risk. If two specific engineers quit tomorrow, what breaks? This is a business risk, not just an HR issue. It affects valuation and integration planning.
Security and compliance posture. If you’re in healthcare, finance, or any regulated vertical, you need to know what certifications exist and whether they were real or performed. SOC 2 reports vary wildly in what they actually cover.
Runway on the current stack. How much longer can the company grow on what it has before a major replatforming becomes unavoidable? That’s a capital planning question, not just a technology question.
Days 30 Through 60: The CTO Question
If the existing CTO is staying, you need to know by day 30 whether they are the right person to take this company where you want it to go. This is not about whether they’re a good person or whether they built something impressive to get the company here. The question is whether they can operate in a PE-backed environment with tighter timelines, more stakeholder accountability, and explicit growth targets.
Many technical founders can build something from zero to $10M ARR and then struggle badly with what comes next. That’s not a failure — it’s a common and predictable transition. Recognizing it early saves everyone time and protects the relationship.
If there is CTO uncertainty, do not leave it open. Ambiguity about technical leadership at this stage will cost you the engineers you most need to keep.
Days 60 Through 90: Build the Technical Roadmap
By day 60, you should have enough information to make real decisions. Now you can structure the technical roadmap against your investment thesis.
If you’re driving toward an exit in three to five years, the roadmap needs to support that. Which technical improvements will directly affect EBITDA or valuation multiples? Which are housekeeping that can wait? Which are risks that must be addressed regardless?
Prioritize ruthlessly. You cannot fix everything in year one, and trying to fix everything in year one will destroy the team’s ability to ship product. The goal is a realistic, sequenced plan that the engineering team can execute and that you can explain to your investment committee.
The 90-day window is also when you establish the reporting cadence. PE-backed companies need technical visibility at the board level. That means clear metrics — deployment frequency, system uptime, cost per transaction, open security vulnerabilities — not status updates written by the people you’re overseeing.
The Move Most PE Firms Delay Too Long
Every PE firm that has made a software acquisition without technical expertise on the deal team eventually brings in outside technical help. The question is whether they do it in week two or month eight.
Month eight costs significantly more — in advisor fees, in avoidable mistakes, in key people who left because the transition was mishandled, and in the opportunity cost of decisions made on incomplete information.
If you’re in the first 90 days of a software company acquisition and you’re not sure what you actually own, a 15-minute call with Christopher can help you figure out what questions to ask first and how to structure the next 60 days. He has done this assessment for PE-backed companies in financial services, logistics, and retail technology, and can tell you quickly whether what you’re facing is unusual or standard.