About this service
Build scalable, maintainable software with our experienced engineering teams. We deliver high-quality code and best practices that help your product succeed.
Go to service
Guide
Technical Due Diligence Checklist for SaaS Acquisitions
Technical due diligence (TDD) is a structured evaluation of a software company's codebase, architecture, engineering team, and processes, run before an investment or acquisition to replace assumptions with evidence. A good TDD answers one question for the buyer: what are the technical risks behind this product, how serious are they, and how much will they cost to fix? It is broader than a code review. The people and processes that produce the code usually matter more than any single line of it.
By Andreas Creten · Founder & CEO, madewithlove · Updated 24 June 2026
- 180+
- technical audits run for investors and SaaS companies
- 5
- pillars assessed: team, process, engineering, security, fit
- ~2 weeks
- from baseline interview to a decision-ready report
The five-pillar technical due diligence checklist
A thorough technical audit looks beyond the code at the whole system that produces it. These are the five areas to assess, and the concrete questions to answer in each.
1. How strong is the team and leadership?
The team that builds the product is the biggest predictor of what it will deliver next, so assess the people before the code. Look at who holds critical knowledge, whether leadership can scale with the plan, and how openly problems surface.
- Key-person risk: how many people understand the critical parts of the system, and what happens if one leaves?
- Seniority mix and whether technical leadership can scale with the company's plan
- Hiring, onboarding and retention, recent attrition and time-to-productivity for new engineers
- Psychological safety and feedback culture, which determine whether problems surface early or stay hidden
- Whether the founders or current CTO can credibly lead the next stage of growth
2. How does the team build and ship software?
How a team ships is more durable than what it has shipped, so look at the system that produces the software. Strong delivery is frequent, reviewed and recoverable; weak delivery leans on heroics and manual steps that will not survive scale.
- Delivery flow: cycle time, deployment frequency and how predictably work reaches production (DORA metrics)
- Code review practices and whether changes are reviewed before they ship
- Incident handling, on-call and mean time to recovery
- Planning, prioritisation and how technical debt is tracked and paid down
- Dependency on heroics or manual steps that don't scale
3. How healthy is the codebase?
Examine the codebase for the risks that turn into cost: fragility, lock-in, and the things that slow every future change. The question is not whether the code is perfect, but whether the team can change it safely and at the pace the business needs.
- Architecture fit: does the design match the product's actual scale and roadmap, or is it over- or under-engineered?
- Test coverage where it matters, and confidence that changes can be made safely
- Automated CI/CD versus manual, error-prone deployments
- Technical debt: how much, where, and how much it slows delivery today
- Third-party and open-source dependencies, their licences, and supply-chain exposure
- Scalability and performance headroom against projected growth
4. How is security and compliance handled?
Security and compliance are the risks that can sink a deal after close, through data handling, access control and regulatory exposure. Investors react to these faster than to any other category, so treat unmanaged secrets or unclear data ownership as priority findings.
- Authentication, authorisation and secrets management
- Data protection, privacy and GDPR/regulatory posture for the markets served
- Known vulnerabilities, patching discipline and dependency hygiene
- Audit logging, monitoring and the ability to detect and respond to incidents
- Relevant certifications or the realistic effort to reach them (e.g. SOC 2, ISO 27001)
5. Does the technology fit the business and roadmap?
Check whether the technology actually serves the business, today and against the plan you are underwriting. A capable team and a clean codebase still carry risk if the roadmap is unrealistic or the product has drifted from what customers pay for.
- Alignment between what's built and what customers use and pay for
- Whether the roadmap is realistic given the team and the codebase
- Build-versus-buy decisions and the cost of any in-house reinvention
- Documentation and knowledge management, can a new team take this over?
- Total cost of ownership: infrastructure spend, licences and the engineering cost of the current design
Green flags vs red flags
No single red flag is automatically a deal-breaker, what matters is how much it will cost and how long it will take to fix. Use these as signals to investigate, not verdicts.
| Green flag | Red flag |
|---|---|
| Knowledge is shared; multiple engineers can work on any critical area. | One person is the single point of failure for a core system. |
| Changes ship frequently and safely, with automated tests and deployment. | Releases are rare, manual and stressful, and rollbacks are common. |
| Technical debt is tracked, understood and deliberately managed. | Debt is invisible. Nobody can say what's slowing the team down or why. |
| Architecture matches the product's real scale and near-term roadmap. | The system is over-engineered for vanity scale, or already buckling under load. |
| Security and data handling are designed in, with clear ownership. | Security is an afterthought; secrets, access and data flows are undocumented. |
The risks we see most often
Across the technical audits we run, the same gaps come up again and again. These are the patterns a buyer should expect to find, and why each one matters once the deal closes.
| Risk | How often we see it | Why it matters to a buyer |
|---|---|---|
| Documentation debt | ~90% of audits | Knowledge lives in people's heads rather than in writing, which slows integration and onboarding for a new owner. |
| Manual or missing automated testing | ~85% of audits | Most teams ship without meaningful automated testing, so every change risks a regression that reaches customers. |
| Key-person risk | ~80% of audits | One person understands a critical system. If they leave, much of the value you are paying for leaves with them. |
| A weak or missing roadmap | ~75% of audits | Without a realistic plan, it is hard to underwrite the growth you are funding. |
| Secrets in the codebase | ~40% of audits | Credentials committed to source control are an immediate security and compliance exposure. |
Figures are approximate, drawn from madewithlove's own analysis of the audits we have run. We never name the companies we assess.
Need an independent technical audit?
madewithlove has run 180+ technical due diligence audits for investors and SaaS companies. Senior engineers and CTOs, an honest report in about two weeks, and clear recommendations you can act on.
Further reading from our blog
Technical due diligence FAQ
The questions investors and acquirers ask most often before commissioning a technical audit.
Technical due diligence is a structured assessment of a software company's codebase, architecture, engineering team and processes, carried out before an investment or acquisition. It replaces assumptions with evidence so a buyer can understand the technical risks behind a product, how serious they are, and what they will cost to fix.
Five areas: (1) team and leadership, including key-person risk; (2) processes and delivery flow; (3) engineering and code quality, including architecture, testing and technical debt; (4) security and compliance; and (5) problem and solution fit and roadmap. A checklist that only reviews code misses the people and processes that usually carry the real risk.
A focused SaaS technical due diligence typically runs in about two weeks, from an initial baseline interview, through codebase review and team interviews, to a decision-ready report. Timelines stretch with the size of the codebase, the number of systems and how much access is available.
No. A code review inspects the code; technical due diligence inspects the system that produces it. The team, delivery process, security posture and roadmap usually reveal more about future risk than the source code alone, which is why a thorough TDD covers all five areas.
Buy-side TDD should be run by an independent technical party with no stake in the deal closing, so findings are honest. Target companies can also commission a self-initiated audit before going to market, which surfaces and fixes risks on their own terms and strengthens their position in a funding round or sale.
The most common deal-relevant red flags are key-person risk (one person who understands a critical system), rare and manual releases, invisible or unmanaged technical debt, architecture that doesn't match the product's real scale, and security treated as an afterthought. None are automatically deal-breakers, what matters is the cost and time to remediate them.