Technical due diligence is not a code beauty contest. Its purpose is to determine whether the technology can safely support the commercial plan, what hidden risks may cost, and whether the team can operate the system. This is the structure I would use before an investment, acquisition or aggressive growth stage.
The review should answer
- Which three risks could block the next 12 months of growth?
- What time and budget will the critical fixes require?
- Does the product depend on one person, vendor or undocumented process?
- Which conclusions have evidence and which rely on assertions?
1. Start with the commercial scenario—not the repository
The same codebase may be adequate for 500 customers and dangerous for a platform expected to serve 100,000 after funding. First document the 12–24 month scenario: user growth, geography, transaction volume, regulatory exposure and team plan.
Tie every technical question to that scenario. International expansion makes data location and localization relevant. Transaction growth makes payment-state integrity, auditability and incident response much more important.
- What exact growth scenario is being assessed?
- Which functions generate revenue or control critical risk?
- What availability and recovery targets are actually needed?
- Which data is sensitive and who may access it?
2. Build an evidence room
Interviews are useful, but they are not evidence. A credible review uses artifacts: architecture diagrams, deployment history, incident records, access matrices, monitoring screens and proof that a backup has actually been restored.
Ask the team to demonstrate one change from ticket to production, then one incident from signal to resolution. Those two paths reveal more than a long technology inventory.
- System and data-flow diagram with owners
- CI/CD flow, test results and recent deployment history
- Production monitoring, alerts and incident reviews
- Role and privileged-access inventory
- Backup policy and last tested restore
- Third-party services, licenses and critical dependencies
3. Assess six risk domains
Architecture shows whether the system has clear boundaries and whether expensive parts can change independently. Security shows whether access, secrets and audit trails are systematic. Data work reveals whether information is trustworthy, recoverable and properly governed.
Delivery, production operations and people dependencies matter just as much. Excellent code does not help if only one person can deploy it or incidents are first discovered through customer complaints.
- Architecture: boundaries, bottlenecks and synchronous failure points
- Security: authentication, authorization, secrets, vulnerabilities, audit
- Data: quality, migrations, retention, backups and ownership
- Delivery: tests, reviews, deployments and rollback
- Operations: metrics, alerts, incidents, capacity and cost
- Team: ownership, documentation and key-person risk
4. Score risk consistently
Give each finding a likelihood and impact score from 1 to 5. Their product creates a comparable priority. Add detectability where a problem may remain silent, such as a gradual financial reconciliation error.
Also state confidence: high when supported by production evidence, medium with documentation, and low when based on interviews. This avoids false precision.
5. Make the conclusion a decision document
The output should not be an 80-page engineering report. Decision-makers need a one-page view of what works, what could break the plan, the likely cost range and the first 30, 60 and 90 days of action.
Separate deal-blocking risk from ordinary technical debt. Nearly every working product carries debt. What matters is whether it is known, manageable and proportionate to the company stage.
- Three to five findings in commercial language
- Risk register with owner and evidence links
- Remediation ranges rather than false precision
- 30/60/90-day action plan
- Explicit assumptions and untested areas
Use with your team
40-point rapid review
Mark an item complete only when you have evidence—a document, metric, demonstration or an accountable owner's confirmed process.
- 01Current system and data-flow diagram exists
- 02Every critical component has an owner
- 03System boundaries and integration contracts are clear
- 04Current capacity and scale limits are known
- 05No unmanaged single-vendor lock-in
- 06Technology choices match team capability
- 07Authentication is centralized and documented
- 08Authorization is enforced server-side
- 09Privileged access is reviewed
- 10Secrets are not stored in code
- 11Dependencies are scanned regularly
- 12Security events leave an audit trail
- 13Personal data is inventoried
- 14Retention periods are defined
- 15Migrations are versioned and repeatable
- 16Backups are encrypted
- 17Restore has been tested
- 18Critical data quality is measured
- 19Core journeys have automated tests
- 20Code changes are reviewed
- 21Deployment is automated
- 22Rollback has been tested
- 23Environments are separated
- 24Production changes are traceable
- 25Business KPIs sit alongside technical metrics
- 26Critical alerts have an owner
- 27Incidents are documented
- 28Escalation is clear
- 29Cloud costs map to products or functions
- 30Capacity matches the growth plan
- 31Critical third parties are inventoried
- 32Licensing permits planned use
- 33Vendor failures have fallback paths
- 34Critical processes do not depend on one person
- 35A new engineer can run the project from documentation
- 36Product and engineering responsibilities are explicit
- 37Technical debt is recorded and prioritized
- 38The 90-day plan has real owners
- 39Remediation is included in the financial model
- 40Uncertainty is separated from verified fact
FAQ
Common questions
How long does technical due diligence take?+
A focused review of a small or mid-sized product commonly takes 5–10 working days when evidence is readily available. Regulated, multi-product or highly complex environments take longer.
Does every line of code need review?+
No. Start from risk hypotheses and inspect representative high-risk areas: access, payments, data, critical journeys and deployment. Full line-by-line review is rarely proportionate.
How is due diligence different from a technical audit?+
An audit often improves the current system for the team. Due diligence supports a specific investment, acquisition or partnership decision and translates technology risk into commercial consequence.
Who should conduct the review?+
Someone with real architecture and production-operations experience who is independent of the product team. Security or regulated areas may require additional specialists.
Primary references
For deeper technical work:
OWASP Application Security Verification Standard