The acquisition was valued at $50M. The founders had been heads down for four years building the product, shipping features, and growing revenue. The buyer's initial assessment was positive: strong market position, solid customer base, impressive growth metrics.
Then came the technical due diligence.
Three weeks of code review, architecture discussions, security assessments, and team interviews later, the buyer revised their offer downward by $15M. The term sheet came back with an explanation: "Significant technical debt impacting development velocity, security vulnerabilities requiring immediate remediation, and critical knowledge concentrated in two individuals who haven't agreed to stay."
The founders were blindsided. They'd been so focused on building product and closing deals that they hadn't realized their codebase had become a liability. The shortcuts they'd taken to ship faster had accumulated into structural problems. The documentation they'd never prioritized meant the system was opaque to outsiders. The security issues they'd been meaning to address were still sitting in the backlog.
"We thought we were selling a $50M company," one founder told me afterward. "We were actually selling a $35M company with $15M of technical risk that the buyer wasn't willing to absorb."
At SmithSpektrum, I've been involved in over 50 technical due diligence processes—some as the advisor to the selling company, some as the technical evaluator for investors or acquirers[^1]. The patterns of what matters and what doesn't are remarkably consistent. Understanding them can mean the difference between a smooth transaction at full value and a haircut that costs you millions.
What Technical Due Diligence Actually Evaluates
Technical DD isn't a code review, though code review is part of it. It's a comprehensive assessment of whether a company's technology can support its business objectives and whether the risks involved are understood and manageable.
The codebase assessment looks at architecture, quality, maintainability, and technical debt. Is the system designed sensibly? Can it scale? Is the code readable by people who didn't write it? How much effort would it take to add new features or fix problems? What compromises have accumulated, and what would it cost to address them?
The security assessment evaluates vulnerabilities, practices, and compliance. Are there known security issues? Does the team follow security best practices? Is the company compliant with relevant regulations—GDPR, SOC 2, HIPAA, whatever applies to their business?
The team assessment considers capabilities, depth, and concentration risk. Can this team execute the roadmap? What happens if key people leave? Is knowledge distributed across the team or concentrated in a few heads?
The infrastructure assessment examines scalability, reliability, and cost efficiency. Can the systems handle growth? What's the incident history? Is the cloud spend reasonable, or are they burning money on inefficient architecture?
The IP assessment covers ownership, licensing, and dependencies. Does the company own what it thinks it owns? Are there problematic open-source licenses? Are there dependencies on third-party services that create risk?
The weighting varies by context. Venture investors focus most on team capability and scalability—can this group build what they claim they'll build? Strategic acquirers focus more on IP and integration—what are we actually buying and how hard will it be to absorb? Private equity buyers focus on operational efficiency and risk—is this a well-run technology operation or a mess that will need immediate investment?
The Codebase Deep Dive
When evaluators look at code, they're forming impressions across several dimensions simultaneously.
Architecture coherence is about whether the system design makes sense. Is there a clear structure? Do the components fit together logically? Can someone new to the codebase understand how things work without getting lost in spaghetti? The cleaner the architecture, the easier future development will be—and the lower the risk that adding features will break unexpected things.
| Assessment Area | Key Questions | Green Flags | Red Flags |
|---|---|---|---|
| Architecture | How does it scale? What are the bottlenecks? | Clear boundaries, documented decisions | Monolith with no plan, "rewrite coming" |
| Code Quality | Test coverage? Deployment frequency? | CI/CD, regular deploys, good coverage | Manual deploys, low/no tests |
| Security | Last pentest? Vulnerability scanning? | Regular audits, patched dependencies | Unknown exposure, old dependencies |
| Team | Who built this? Who maintains it? | Original builders still present | All original engineers gone |
| Technical Debt | What's the worst part? | Honest answer + plan | "Nothing major" |
Code quality matters for maintainability. Is the code readable? Are there consistent patterns? Is there meaningful test coverage? Code that can only be understood by its original author is a liability; code that's clear enough for any competent engineer to work on is an asset.
Technical debt is the accumulated cost of shortcuts. Some technical debt is inevitable and even strategic—taking on debt to ship faster can be the right call. But uncontrolled debt slows development, increases bug rates, and makes the system fragile. Evaluators look at whether debt is acknowledged and managed or whether it's been ignored until it's become structural.
Documentation rounds out the picture. Is there architecture documentation that explains how the system works? Are there runbooks for operations? Is there enough written down that new team members or acquirers can understand the system without relying on tribal knowledge?
Red flags in codebase assessment include: no test coverage (quality is unknown and changes are risky), massive monoliths with no clear boundaries (hard to scale or split), critical code that only one person understands (bus factor risk), severely outdated dependencies (security risk and maintenance burden), and inconsistent patterns that suggest ad hoc development without engineering discipline.
Green flags include: consistent coding standards across the codebase (professional engineering), meaningful test coverage that's actually run in CI (quality discipline), clear module boundaries (scalable and maintainable), up-to-date dependencies (active maintenance), and clean git history that shows thoughtful development practices.
The Security Assessment
Security has become increasingly central to technical DD, driven by the frequency and cost of breaches, the complexity of regulatory compliance, and the liability that security issues can create.
Evaluators look for known vulnerabilities—issues that can be found through automated scanning or basic penetration testing. Unpatched dependencies with CVEs, SQL injection vulnerabilities, XSS issues, insecure configurations—these are discoverable and should have been addressed. Finding them signals either negligence or lack of resources, neither of which is reassuring.
Security practices matter as much as current state. Does the team do security reviews? Do they run automated scans? Is there an incident response process? How quickly do they patch vulnerabilities? Good practices mean that even if issues exist, they'll be found and addressed; poor practices mean that issues will accumulate.
Compliance requirements vary by industry. A healthcare company needs HIPAA compliance. A company handling payment data needs PCI compliance. Any company with European customers needs GDPR compliance. Being out of compliance isn't just a risk—it can be a legal liability that the acquirer inherits.
Credentials in code are an instant red flag—API keys, passwords, or secrets committed to the repository are an elementary mistake that raises questions about what else might be wrong. No access controls, no audit logging, no encryption of sensitive data—these issues can be dealbreakers depending on what the company handles.
Preparing for security DD means running your own assessments before someone else does. Identify vulnerabilities and either fix them or have a clear plan for remediation. Document your security practices so you can demonstrate maturity. Get your compliance certifications if they're relevant to your business.
The Team Assessment
Technology ultimately depends on people. Evaluators want to understand whether the current team can execute and what risks exist around team composition and retention.
Capability assessment asks whether this team has the skills to do what's needed. Are they strong enough technically? Do they have the right specializations? Can they scale with growth? Team capability matters more at early stages when execution is everything; it matters somewhat less at later stages when systems and processes can substitute for individual excellence.
Knowledge distribution is often the most important team consideration. If critical systems are understood by only one or two people, those people leaving creates catastrophic risk. Evaluators look at bus factor—how many people would need to be hit by a bus to cripple the organization? A team where knowledge is widely distributed is resilient; a team where one person holds everything in their head is fragile.
Retention risk matters for acquisitions especially. Will key engineers stay through the transition? Are they incentivized to do so? Have they agreed to retention packages? Acquirers sometimes make retention of key engineers a condition of the deal; if those engineers won't commit, the deal may not close.
Team dynamics are harder to assess but important. Is there a functional engineering culture? Do people collaborate well? Are there toxic individuals or dysfunctional relationships? Evaluators often conduct individual interviews with multiple team members to get a sense of how the team actually works.
Red flags include: single points of failure (one person who can't be replaced), recent high attrition (something is wrong), no senior engineers (limited capability), visible dysfunction (team problems will become your problems), and founders who can't explain their own system (limited technical depth).
Green flags include: distributed knowledge (resilient team), low turnover (people want to stay), clear ownership (accountability exists), strong technical leadership (can grow and execute), and a quality culture (pride in the work).
Infrastructure and Operations
How the system runs in production matters as much as how the code looks.
Scalability assessment asks whether the infrastructure can handle growth. Can it handle 10x current load? 100x? What breaks first? Companies that haven't thought about scale will face either expensive rearchitecture or reliability problems when growth arrives.
Reliability history reveals how the system actually behaves. What's the uptime history? How often are there incidents? How severe are they? How quickly are they resolved? A company with frequent outages or extended recovery times has operational problems that affect customers and will continue to do so.
Cost efficiency matters for burn rate and margin. Is the cloud spend reasonable for the scale? Or are they burning money on oversized instances, unoptimized queries, and services they don't need? Inefficient infrastructure isn't just expensive—it often indicates that nobody is paying attention to operations.
Disaster recovery is about whether they can recover from failures. Are there backups? Are they tested? How long would it take to restore from a major failure? Companies that haven't invested in disaster recovery are one bad day away from losing data or extended outages.
Operational maturity encompasses monitoring, alerting, deployment practices, and incident response. Can they see what's happening in production? Do they know when things break? Can they deploy safely and quickly? Do they have processes for handling incidents? Mature operations reduce risk; immature operations are a ticking clock.
Red flags include: no infrastructure as code (hard to reproduce, harder to scale), no monitoring (flying blind), single points of failure (reliability risk), excessive cloud spend (inefficiency signals), no disaster recovery (data loss risk), and manual deployments (reliability problems).
The DD Process
Understanding how DD works helps you prepare for it.
The typical timeline spans three to six weeks from start to findings delivery. The first week or two is preparation and document gathering. The next one to two weeks is deep dive—code review, architecture sessions, security assessment, team interviews. The final week is analysis and report writing.
Materials requested typically include: architecture documentation (system design, component interaction), codebase access (usually a read-only clone), infrastructure diagrams (cloud architecture, data flow), security documentation (policies, practices, compliance), team information (org chart, tenure, key person identification), process documentation (development, deployment, incident response), incident history (outages, post-mortems, resolutions), and technical roadmap (planned work, capacity assessment).
Interview sessions usually include: an architecture overview with the CTO or tech lead, a security review with whoever owns security, an operations review with the SRE or ops lead, a team structure discussion with engineering managers, and technical deep-dives with domain experts on specific systems.
The findings will typically categorize issues by severity (critical, high, medium, low), by effort to remediate (quick fix, moderate effort, significant investment), and by impact on valuation or deal terms. Critical findings can pause or kill deals. High findings often result in valuation adjustments or contractual protections. Medium and low findings are noted for post-close attention.
Impact on Valuations and Deal Terms
What DD finds affects more than just price.
Significant security vulnerabilities might reduce valuation by 10-20%, or the buyer might require remediation before closing, or they might build a remediation escrow into the deal where funds are held until issues are fixed.
Excessive technical debt typically results in 5-15% valuation reduction, priced as the cost the buyer will need to invest to address it. The reduction is usually the estimated remediation cost plus a discount for the uncertainty involved.
Key person dependency often results in retention requirements—the deal might require key individuals to sign retention agreements before closing, with earnout structures that tie payment to those people staying for defined periods.
Scaling concerns might result in milestone-based deal structures where a portion of the purchase price is tied to successfully handling projected growth.
IP issues (licensing problems, ownership questions, problematic dependencies) can pause deals entirely until resolved or restructure them to shift liability.
Strong technical foundations, on the other hand, can support valuations or even create premiums. Clean architecture, strong security, distributed knowledge, mature operations—these reduce buyer risk and justify confidence in projections.
Preparing Your Company
The best time to prepare for DD is long before you need to. Continuous good practices are better than last-minute cleanup.
Maintain documentation as you go. Architecture documents should evolve with the system. Decision records should capture why things are the way they are. Keeping documentation current is much easier than creating it from scratch when someone asks.
Address technical debt regularly rather than letting it accumulate indefinitely. Dedicate time each sprint or cycle to debt reduction. The goal isn't zero debt—that's impossible—but manageable debt that's understood and controlled.
Run security assessments periodically, not just when a deal is pending. Find and fix vulnerabilities before external evaluators do. The issue you find and remediate looks very different from the issue an evaluator discovers.
Distribute knowledge deliberately. Pair programming, documentation, rotation of responsibilities—all help ensure that understanding isn't concentrated in a few heads.
Track operational metrics so you can show maturity. Uptime, incident frequency and duration, deployment frequency, recovery times—having data demonstrates operational discipline.
If DD is imminent, focus your pre-DD cleanup on the most visible issues: update documentation, run security scans, prepare your data room, brief your team on the process. You can't fix years of accumulated debt in weeks, but you can present your situation honestly and show that you understand it.
The founders who lost $15M in valuation didn't get that money back. They closed at the reduced price because the buyer's assessment was accurate: their technology did have significant issues that would require investment to address.
But they learned. The issues that cost them in the acquisition—documentation, security, knowledge distribution—became priorities in their next company.
"Technical health isn't just about shipping," one of them told me later. "It's about building something that can withstand scrutiny. If we'd spent 10% of our time on the things that DD revealed, we'd have been worth the full $50M. That's a $15M lesson."
References
[^1]: SmithSpektrum technical due diligence consulting, 50+ processes, 2019-2026. [^2]: CB Insights, "M&A Due Diligence Best Practices," 2024. [^3]: Crunchbase, "Technical DD Impact on Valuations," 2025. [^4]: OWASP, "Security Assessment Guidelines."
Preparing for technical due diligence or conducting an evaluation? Contact SmithSpektrum for tech DD support.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum