You’re in an M&A process. The LOI is signed, the buyer seems excited, and then they tell you their technical team is coming in. You’ve spent months crafting the narrative around your product and your team. Now someone is about to look at everything you’ve been building — and find the parts you haven’t talked about in any deck.
Here’s what actually happens in a technical due diligence process, what kills deals, and how to come out of it with your valuation intact.
What Technical Due Diligence Actually Is
It is not a code review. No serious technical due diligence team is going to read every line of your codebase and grade its elegance. What they are doing is a structured risk assessment designed to answer one question for the buyer: are there technical facts about this company that change what we’re willing to pay, how we integrate it, or whether we close at all?
The categories they look at fall into four buckets: architecture risk, people risk, security and compliance risk, and cost structure.
Understanding this framing matters because it changes how you prepare. You’re not trying to show them how sophisticated your engineering is. You’re trying to demonstrate that the risks are known, manageable, and priced in.
What Actually Kills Deals
In order of how often they blow up a transaction:
Hidden compliance gaps. If your product handles health data, financial data, or personal information at scale and you’ve been loose with compliance, this is the one that ends deals fastest. Buyers in regulated industries have their own regulatory exposure. They cannot absorb your gaps. SOC 2 Type II, HIPAA BAAs, PCI compliance — if you have any of these requirements and your coverage is thin, this surfaces quickly and it surfaces badly.
Key person concentration. If two engineers wrote 80% of the production codebase and one of them is already looking at other jobs, the buyer’s technical team will find this. They look at commit history. They look at who touches critical systems. They will ask, in the integration planning conversation, what happens if those people leave. If you don’t have a good answer, they will price it into the deal.
Undisclosed technical debt that is operationally critical. Technical debt is not a disqualifier. Every real software company has it. What kills deals is when the technical debt is in a place that will force expensive remediation as part of the integration, and you haven’t disclosed it. If the buyer finds it on their own, they assume there’s more you’re hiding. If you disclose it upfront, they can model it.
Cloud cost structure that doesn’t scale. If your gross margins look good at current scale but your cloud architecture has a structural problem that will erode margins as you grow, a good technical team will model this. This shows up as a valuation adjustment, not a deal killer — but if you don’t know your own unit economics on infrastructure, you’ll be caught flat-footed when they present their findings.
Security vulnerabilities in customer-facing systems. This is increasingly a standard check. Buyers are doing penetration testing or reviewing recent pentest results. Unpatched critical vulnerabilities in production systems are a liability, particularly if customer data is involved.
What They Are Fine With
Old technology that works. Rails apps from 2014, Java backends that haven’t been touched in three years, PostgreSQL running on legacy versions — none of this is automatically disqualifying. Boring infrastructure that is stable and well-understood is not a liability.
Monolithic architecture. The microservices narrative has overcorrected dramatically. A well-structured monolith that the team understands and can modify is often worth more than a distributed system that requires six engineers to operate.
Test coverage gaps in non-critical systems. If your customer-facing APIs have good coverage and your internal tooling doesn’t, that’s a normal tradeoff. They’re not going to hold you to academic standards.
Honest technical debt with a remediation roadmap. Show them you know what’s broken and you have a sequenced plan. That’s a mature engineering organization. That’s what they want to see.
How to Prepare Without Overpromising
Four weeks before a technical team comes in, do your own internal audit. Not to hide things, but to know what they’re going to find before they find it. Walk through your own architecture with fresh eyes. Pull your dependency list and check for anything that’s end-of-life or known-vulnerable. Look at your cloud bills and understand your margin structure at 2x and 5x current scale. Review your compliance documentation and identify gaps.
Then brief your CTO on the framing. The goal is not to spin anything. The goal is to present known issues as known issues, with owners and timelines, rather than letting the buyer discover them and assume the worst.
Prepare your engineers for the interviews. Technical teams talk to your engineers, often without your CTO in the room. Engineers who haven’t been briefed on what questions are coming will say things that sound alarming but are actually fine — or will volunteer information about problems that have already been solved. A 30-minute conversation with your team about what due diligence looks like goes a long way.
The Negotiation That Happens After
When the technical team presents their findings, the buyer will use them to negotiate. Some of what they present will be legitimate — real risks that you should acknowledge and that may warrant a price adjustment or an escrow. Some will be inflated — standard technical realities dressed up as risks to create negotiating leverage.
You need someone in the room who can push back on the second category credibly. This is not your CEO’s job. It is not your lawyer’s job. You need technical representation that can look at a finding and say, “That’s a standard tradeoff in a company at this stage, not a material risk, and here’s why.”
Without that, you will either concede on findings that didn’t warrant concession, or you’ll push back without credibility and damage the relationship.
If you’re in an active M&A process and a buyer’s technical team is coming in within the next few weeks, a 15-minute call with Christopher can help you understand what they’re actually looking for, how to position your technology honestly, and where you need representation in the room. He has been on both sides of technical due diligence — as the assessor and as the advisor to the company being assessed.