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
- 100+
- 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. Team & leadership
The biggest predictor of future delivery is the team that builds it. Assess the people before the code.
- 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. Processes & ways of working
How a team ships is more durable than what it has shipped. Look at the system that produces the software.
- 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. Engineering & code quality
The codebase, examined for the risks that turn into cost: fragility, lock-in, and the things that slow every future change.
- 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. Security & compliance
The risks that can sink a deal post-close: data handling, access control, and regulatory exposure.
- 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. Problem and solution fit & roadmap
Whether the technology actually serves the business, today and against the plan you're underwriting.
- 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. |
Need an independent technical audit?
madewithlove has run 100+ 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.
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.