Pre-deal · buy-side and sell-side
Technical due diligence on the IC timeline.
A written assessment of the platform, the team, and what it will cost to support the thesis, delivered in two to three weeks by a sitting CTO who has run diligence and integration on more than ten acquisitions.
Timeline
How the two to three weeks are spent
- 1
Scope to the thesis
A one-hour call with the deal team to understand what the model assumes the technology can do, what you already suspect, and the IC date. The scope is set around what would change the decision.
- 2
Read the system
Week one: code, architecture, cloud accounts, security posture, delivery process, and cost history, plus management interviews. If anything would stop the deal, you hear about it by Friday.
- 3
Score and cost the risks
Week two: each material finding is rated by severity, cost to fix, and time to fix, with a suggested remediation sequence and the part of the model it affects.
- 4
Readout
A written report the IC can read in fifteen minutes, an appendix your operating team can work from, and a live walkthrough with Q&A. The risk register is formatted to become the draft 100-day plan.
Scope
What gets examined
Architecture and scalability: Whether the platform can carry the next three years of the plan (pricing changes, add-ons, new markets, AI features) without a rebuild, and where the structural constraints are.
Code and delivery: Code quality where it matters, test coverage where it counts, and the real release cadence: how often the team ships, how often it breaks, and how long recovery takes.
Team and key-person risk: Who holds the critical knowledge, how decisions get made, how much depends on contractors, and what the exposure is if two people leave shortly after close.
Security and compliance: The actual posture versus the questionnaire answers: identity, secrets management, data handling, patching, and the gap an enterprise customer's security review would find.
Cloud and vendor cost: Twelve months of spend, unit cost trend against revenue, contract lock-in, and a realistic estimate of the margin improvement available without changing the roadmap.
Data and AI: Data model fitness, data rights and provenance, and for any AI claim: whether it's a model or a wrapper, vendor concentration, inference economics, and evaluation maturity.
Product and roadmap: Whether the roadmap is driven by customers or by the engineering team's preferences, and whether the team's plan and the deal thesis are the same plan.
Deliverables
What you get
IC summary
Risk register
Technical appendix
Readout and Q&A
How I work
A few things I won't do
Rubber-stamp a deal: If the platform can't support the thesis, the report says so in the first paragraph.
Write a 200-page PDF: The report is written for the people making the decision. The supporting evidence is there for the people who will do the work.
List risks without prices: Every finding comes with a cost and a time to fix. Without those, it isn't useful to an investment committee.
Disappear after the readout: I stay available to the team running the plan on an advisory basis. The register is built to hand over, and I'd rather be asked about it than have it guessed at.
FAQ
Questions deal teams ask
How long does technical diligence take?
Two to three weeks from data room access to the final readout, with a preliminary red-flag call at the end of the first week. If the IC date requires a shorter timeline, I narrow the scope to the items that would change the decision.
What do you need from the target?
Read access to the code repositories and cloud accounts, whatever architecture and security documentation exists, the last twelve months of cloud invoices, and two to three hours with the engineering leadership. I work under NDA and can operate through a clean-team arrangement where needed.
Do you review the code yourself?
Yes. Automated scans are a starting point. The findings that matter most, such as a data model that can't support a planned pricing change or a deployment process only one person can run, come from reading the system with operating experience.
How does this connect to post-close work?
The risk register is written so it can serve as the first draft of the 100-day plan. Your operating team or the incoming CTO runs it; I stay available to them on an advisory basis, with check-ins at day 30, 60, and 100 if you want them.
You're a sitting CTO. How does that work with a diligence timeline?
Summit Foundry Group is a small practice I run alongside my role as CTO at LINQ. I take one diligence at a time, or one or two advisory relationships, and I'll tell you on the first call if I'm full. Diligence is project-shaped and mostly evenings, early mornings, and a block of focused days I plan around the IC date, which is why I take one at a time and confirm the date before I say yes.
Do you do sell-side diligence?
Yes. A buyer's-eye review six to twelve months before a process, so remediation happens on your timeline and the data room is in order before buyers see it.
Have a deal in diligence?
Send the timeline and a sentence on the thesis. I'll reply within a business day with a proposed scope and whether the date is workable.
Or email signals@summitfoundrygroup.com. I reply within one business day.