Software is becoming increasingly central to business transactions in today’s complex world. Like any other transaction assets, buyers need to know precisely what they’re buying and for the sellers to highlight the value of the asset they are selling properly. Technical due diligence (TDD) is the process of better evaluating such software assets and identifying their strengths and weaknesses. TDD is a critical step in any software-centric transaction. Entrepreneurs need to have an in-depth view of their intellectual property before it’s evaluated by the investors/acquirers. More importantly, private equity (PE) firms trying to invest and large enterprises trying to acquire more minor start-ups need a clear and detailed understanding of the main asset in the transaction. TDD is perhaps the most critical step in helping reduce risk and prevent failure in acquiring troubled assets. It also allows sellers to highlight their strengths and buyers to justify their valuation. A key question always asked in these transactions is what is a good “technical due diligence checklist”. Entrepreneurs are interested in such lists to better prepare for the future. PE firms, acquirers, and investors are looking for (TDD) service providers with a comprehensive tech due diligence checklist to examine software artifacts and components in a transaction.
If you are reading this blog post, it means you are already aware of the importance of TDD. If you have not entirely bought the idea yet, or want to learn more about TDD in general, stop here and read about why good TDD is critical. Another misconception is that technical due diligence only applies to the buy-side (PE firms and large companies investing in or acquiring targets). There is, in fact, a compelling case for sell-side diligence. Regardless of which side of a transaction you’re on, you are probably reading this page in search of a “technical due diligence checklist”. While this article does provide a checklist you’re probably looking for; it aims to underscore the importance of targeted tech due diligence based on the critical questions being asked, key risks involved in the transaction, and relevant post-transaction considerations. The danger in using a generic technical due diligence checklist is that it just checks the box and gets archived once the transaction closes. It fails to identify critical issues that cause the vast majority of M&A transactions to fail. Instead, a customized, carefully targeted technical due diligence should generate a report that serves as a guideline post transaction (especially if a merger of two technology stacks is involved).
A decade of software analysis, consultation, and numerous due diligence projects helped us create “Lighthouse”. Lighthouse is a suite of products and services incorporating various software analysis tools to run against the target software. Lighthouse checks a given software against multiple standards and best practices. We use Lighthouse to generate reports on how well the software under investigation responds to Quandary Peak’s rigorous audits.
Lighthouse
As promised, here’s Lighthouse’s comprehensive technical due diligence checklist we use to analyze the target’s people, products, and technology. Depending on the nature of our engagement (PE tech due diligence, M&A, self-audit, SPAC, IPO, VC investment, etc.), we configure Lighthouse to analyze a subset of the checklist below. The list is organized into 16 main buckets representing different prongs of Lighthouse’s analysis.
Our TDD Checklist Includes the Following
Software Development Lifecycle (SDLC)
-
SDLC Methodology Used
Scrum, Kanban, Scrumban, SAFe, Agile, Lean, Agile/Lean
-
Methodology Use
Two week sprints, SCRUM master role, daily standups, project managers, Product owners, sprint planning, backlog, retrospective.
-
Team Roles and Responsibilities
Product Owner, Scrum Master, Project Manager, Tech Lead, Architect,
Release Engineer, Senior Developer, Junior Developer, UI/UX Designer,
Front-end Developer, DevOps Manual Tester, T1 Monitoring and Operation,
Customer Care Manager. -
Tools
JIRA, Slack, ClickUp, Google Docs, spreadsheets, etc.
-
Issue Tracking
Issue types: task, bug, a new feature, stats on issue types.
-
Sessions
Regular sessions and their frequencies, standup meetings, planning, postmortem.
-
Processes
Version release, average release cycle, bug fix.
-
Planning and Estimations
User story definitions, backlog scrubbing, velocity tracking, definition of done, story point,
Time estimate for tasks methodology (Pocker, T-Shirt Sizing), reports, burndown charts, etc. -
Process Engineering
Pair programming, code review, sanity check scripts.
-
Delivery
Beta and final tests before each release.
-
Support
Level 1 and 2 teams, Help Desk.
Customer Feedback & Customer Engagement
-
Process
Involved team members and frequency of outreaches, Net Promoter Scores (NPS), surveys, A/B testing.
Documentation and Knowledge Management
-
Tools
Confluence, Javadoc, Sharepoint.
-
Processes and Roles
“When/How/What/” information by “Who”.
-
Document Types
Architecture, Root Cause Analysis (RCA), Javadocs for code, onboarding, update frequency.
Code Repository
-
Inventory Analysis
Collaborative IDE.
Inclusion of configuration files and scripts on Git in addition to the actual code.
Repository security levels, 2FA, encryption, etc.
Push access level, merge request policies, general branching strategies, and policies.
Conflict resolution policies.
Number of versions under work.
Target’s branching policy, feature branch, GitFlow or GitHub flow policy, hot-fix, cherry-pick, patch-version, branch naming policy, and release policies.
Build, Integration, Continuous Integration (CI)
-
Tools
Dependencies: Maven, Gradle, NPM, etc.
Build: Maven, Make, etc.
JAR Repository: Nexus
CI/CD pipeline: Gitlab CI, Jenkins, Bamboo, Circle CI, etc. -
CI Pipeline Automation
Average build time
CI steps and policies (DOs and DONTs)
CI triggers, and outputs
CI environment
Virtualization and containerization of CI (Docker, etc.)
Installation, Deployment, Continuous Delivery (CD), Software Update
-
CD Steps
Installation is automation
Version rollback automation -
Metrics
Downtime, restore time, MTTF, MTBF, MTTR, MTRS, MTBSI, MTTD, MTTI, MTTK, MDT, MTTA, MTTV
-
Data Governance
Migration and data role back
-
Container
Container repository and container orchestration: Docker, Kubernetes, Artifactory, HashiCorp.
Software Architecture & Framework & Scalability
-
Code Analysis, Code Review, Static Code Analysis
-
Tools
Sonar, etc.
-
Processes
CI/CD, paired code review, code review at merge request, code audit, [code] review for documentation
-
Issue Tracking
Bugzilla and bug analysis (most frequent bugs)
Metrics Blocker, Critical, Major, Minor (quality gates and rules)
Data Protection
-
Security, DevSecOps, Audit
-
Processes
Backups, encryption, access levels, monitoring, change of default settings, security processes for remote staff.
Test, Test Automation, Coverage
-
Security Audit
Log analysis, and manual checks, open redirection broken authentication, Direct Object Reference, OWASP Top 10, CWE
Plan B
-
Pen Test
SQL injection, command injection, XSS, CSRF, LFI, RFI
-
(non) Functional Tests
Data migration test, smoke test, mutation test, stress test, load test, functional test, security test, pen-test, static, acceptance test, integration test, unit test.
Log, Fault Detection, Debug
-
Tools
SLF4J
Logback for log registry and collection
ELK for log aggregation
Sentry for error tracking
Zipkin for distributed log tracing -
Techniques and Procedures
Log analysis
Stack Trace analysis
Memory Dump analysis
Thread Dump Analysis
Code instrumentation
Software probes -
Processes
Rules for log registry: DB errors classification, etc.
Log circulation: data preservation and archiving policies
Logs retrieval from log silos -
Dashboards and Reports
List of all dashboards and reports that use log analysis.
Report preparation procedures.
-
Report Types
Authentication and authorization reports
Systems and Data Change Reports
Network Activity Reports
Resource Access Reports
Malware Activity Reports
Failure and Critical Error Reports
DevOps (Monitoring and Incident Management)
-
Tools
Zabbix, SolarWinds
-
Techniques and Procedures
RCA procedures + Roles and Responsibilities
Incident Management procedures + Roles and Responsibilities
Issue discovery automation, server down notification, etc.
Announcement: procedures automation, for example, text, email, or call.
Roles and Responsibilities -
Resolution
Procedure automation, for example, server reboot automation, fault prediction, etc.
List of services under monitoring
-
SLA Management
Monitoring
SLA breach detection and automation
Dashboards
-
Managed Services
Server availability (system uptime) & load balancing.
Service availability: out of service (OOS), total time OOS, in-calls, mean-time response to each API call.
Call status: complete, fail, suspend, cancel, incomplete, time-out.
Valid/invalid messages (visible to customers).
API call success rate & API auto-throttling: over 5 seconds, technical failure, business failure.
Resource usage: CPU/RAM/Disk.
Risk Management and Technical Debt
-
High Risks Factors
Team
Departing of SSA, development team
Price change (business)
Server protection -
Risks from Different Stakeholders POV
Developers
PMs
Customers
DevOps
Business managers
Products
Scalability risk and limitations
Financial
Team
Human Resources, Intellectual Capital
-
Technical Empowerment, Education, Training
Team members academic and education background
Team members related experiences
New employee/developer onboarding
Diversity of skill in the team
Available training
Mandatory training
Employment requirements (remote working options)
Interview processes
Knowledge transfer in the team
Periodic evaluation -
Culture, Environment, Developer Experience
Team values
Norms (should and shouldn’t)
Processes
Perks and benefits
Working environment
Team buildings
Gender diversity
Punctuality and discipline
KPI, OKR -
Feedback Loop
Processes (update frequency), transparency