Whether you are raising funding, acquiring a company, or scaling your startup, technical due diligence determines if the technology can support your business goals. As a developer who provides fractional CTO services and has built multiple SaaS products, here is the checklist I use when evaluating technology.
Category 1: Code Quality and Architecture
1. Is there a clear architecture?
Can someone draw the system architecture on a whiteboard? Monolith, microservices, or serverless -- any pattern is fine, but it should be intentional, not accidental.
2. Is the code organized and readable?
Code should follow conventions (naming, file structure, patterns). If a new developer cannot understand the code in a week, it has a maintainability problem.
3. Is there technical debt?
All codebases have some debt. The question is: is it documented and managed, or is it a ticking time bomb? Ask about known issues and the plan to address them.
4. Are there tests?
Automated tests (unit, integration, end-to-end) are not optional. No tests means every change risks breaking something. Target: 60%+ code coverage for critical paths.
5. Is the tech stack appropriate?
Is the stack modern and maintainable? Can you hire developers for it? A product built on an obscure framework will be expensive to maintain.
Category 2: Infrastructure and DevOps
6. Is deployment automated?
Can you deploy a new version with a single command or button? Manual deployments are slow, error-prone, and block development velocity.
7. Is there a staging environment?
Changes should be tested in a production-like environment before going live. No staging = changes go directly to production = downtime risk.
8. Is the infrastructure documented?
Can you reconstruct the infrastructure from documentation? If the senior developer leaves, can someone else manage the servers?
9. Is there monitoring and alerting?
You should know when the system is down before customers tell you. Error tracking (Sentry), uptime monitoring, and performance dashboards are baseline requirements.
10. Are backups working?
Not "do backups exist" but "when was the last time you restored from backup?" Untested backups are not backups.
Category 3: Security
11. Is authentication secure?
Password hashing (bcrypt or argon2), rate limiting on login, session management, and optional 2FA. Storing passwords in plain text is an immediate deal-breaker.
12. Is data encrypted?
HTTPS for data in transit (non-negotiable). Database encryption at rest for sensitive data. API keys and secrets stored in environment variables, not in code.
13. Are there access controls?
Role-based access control (RBAC). Admin users should have different permissions than regular users. Principle of least privilege.
14. Has there been a security audit?
Professional penetration testing or code review by a security specialist. At minimum, OWASP Top 10 vulnerabilities should be addressed.
15. GDPR compliance (for European businesses)
Data processing documentation, privacy policy, consent management, data deletion capability, and breach notification procedures.
Category 4: Scalability
16. What are the current usage numbers?
Active users, requests per second, database size, growth rate. These numbers tell you how much runway the current architecture has.
17. Where are the bottlenecks?
Every system has a bottleneck -- database queries, API rate limits, memory, or CPU. Knowing the bottleneck helps you plan scaling investments.
18. Can the system handle 10x current load?
Load testing results should show how the system behaves under stress. If no load testing has been done, that is a gap to address.
19. Is the database optimized?
Indexes on frequently queried columns, no N+1 queries, query response times under 100ms for common operations. Slow queries at current scale mean crisis at 10x.
Category 5: Team and Process
20. Is there documentation?
API docs, deployment guides, architecture decision records, onboarding guide for new developers. Documentation is how knowledge survives team changes.
21. What is the bus factor?
If one developer disappears, can the team continue? If the answer is "no," that is a critical risk. Knowledge should be shared, not siloed.
22. Is there a development process?
Code reviews, pull requests, branching strategy, sprint planning. Process matters more than you think -- it is the difference between sustainable velocity and chaos.
23. How fast can new features ship?
Measure deployment frequency. Daily deployments indicate a healthy codebase. Monthly deployments suggest friction in the process.
Category 6: Business Continuity
24. Are there vendor lock-in risks?
Dependence on a single cloud provider, proprietary APIs, or non-standard tools creates risk. Can you migrate to a different provider if needed?
25. Is there a disaster recovery plan?
What happens if the primary server goes down? How quickly can you recover? Target: under 4 hours for full recovery.
26. Are third-party dependencies manageable?
How many external APIs and services does the system depend on? What happens when they go down? Are there fallbacks?
How to Use This Checklist
Score each item: Green (fully addressed), Yellow (partially addressed), Red (not addressed). Count the reds:
- 0-3 reds: Healthy technology. Normal issues that any development team can fix.
- 4-8 reds: Technical debt is accumulating. Needs investment in infrastructure and process. Factor EUR 10-30K in remediation costs.
- 9+ reds: Significant technical risk. May need a partial or full rebuild. Get a professional technical assessment before investing.
I conduct technical due diligence for investors, founders, and companies considering acquisitions. Book a technical assessment to get a comprehensive evaluation of your technology.