Architecture Due Diligence Worksheet | CoreLine

Introduction

Technical due diligence separates informed technology decisions from expensive guesses. Whether you are a CTO inheriting a platform, an investor evaluating an acquisition target, or a board member assessing engineering capability, you need a systematic way to understand what you are looking at.

This worksheet covers seven areas that collectively determine the health, scalability, and maintainability of a software platform. Use it during M&A due diligence, post-acquisition integration planning, or internal architecture reviews. Each section includes the questions to ask, what good answers look like, and the risk signals that should trigger deeper investigation.

Area 1: Infrastructure audit

Understanding how the system runs in production is the foundation of any technical assessment.

Questions to investigate

• Hosting model: Where does the application run - cloud (which provider and services), on-premise, hybrid, or co-located? Are infrastructure costs predictable and optimized?
• Infrastructure as code: Is infrastructure defined in code (Terraform, Pulumi, CloudFormation) or manually configured through console clicks? Manual infrastructure is a reliability and reproducibility risk.
• Environment parity: How closely do development, staging, and production environments match? Significant differences cause bugs that only appear in production.
• Disaster recovery: What is the recovery point objective (RPO) and recovery time objective (RTO)? When was the DR plan last tested?
• Monitoring and alerting: What observability stack is in place? Are there dashboards for key business and system metrics? How are alerts routed and who responds?
• Cost management: Is there visibility into infrastructure spend by service, team, or feature? Are there unused resources or oversized instances?

What good looks like

Infrastructure is fully codified, environments are consistent, DR is tested quarterly, and monitoring covers both system health and business metrics. Costs are tracked and optimized regularly.

Area 2: Code quality indicators

Code quality determines how fast the team can move and how many defects they introduce.

Questions to investigate

• Repository structure: Is the codebase organized logically? Are there clear module boundaries, consistent naming conventions, and a documented project structure?
• Test coverage: What is the overall test coverage? More importantly, are critical business logic paths covered by meaningful tests (not just trivial assertions)?
• Code review process: Are all changes reviewed before merge? What does the review checklist look like? How quickly are reviews completed?
• Linting and formatting: Are style and quality rules enforced automatically? Inconsistent code style is a symptom of process gaps.
• Dependency management: How current are dependencies? Are there known vulnerabilities in the dependency tree? Is there a process for regular updates?
• Dead code and feature flags: How much unused code exists? Are old feature flags cleaned up, or do they accumulate?

Risk signals

• Test coverage below 40% on core business logic
• No code review requirement on the main branch
• Dependencies more than 2 major versions behind
• Large portions of commented-out code in the repository

Area 3: Scalability assessment

Can the system handle growth without a rewrite?

Questions to investigate

• Current load profile: What are the current traffic patterns - requests per second, concurrent users, data volume growth rate?
• Headroom: How close is the system to its current capacity limits? Has load testing been performed, and what were the results?
• Horizontal vs. vertical scaling: Can the application scale by adding instances, or does it require larger machines? Vertical scaling has hard limits.
• Database scalability: Is the database a bottleneck? Are read replicas, caching layers, or sharding strategies in place?
• Stateless design: Is application state stored in the session, or externalized to a cache or database? Stateful application servers are difficult to scale.
• Async processing: Are long-running tasks handled asynchronously with queues, or do they block request threads?

What good looks like

The system has been load tested to at least 3x current peak traffic. Scaling is horizontal and automated. Database queries are optimized and monitored. Background jobs are processed asynchronously with retry logic and dead-letter queues.

Area 4: Security review

Security weaknesses can be deal-breakers in due diligence, especially in regulated industries.

Questions to investigate

• Authentication and authorization: How are users authenticated? Is authorization enforced at the API level, not just the UI? Are there role-based or attribute-based access controls?
• Data encryption: Is data encrypted at rest and in transit? What encryption standards are used? Who manages the keys?
• Secrets management: How are API keys, database credentials, and certificates stored? Secrets in code repositories or environment variables without a vault are high risk.
• Vulnerability management: Is there a process for scanning code and dependencies for vulnerabilities? How quickly are critical vulnerabilities patched?
• Penetration testing: When was the last penetration test performed? Were findings remediated? Is there a schedule for recurring tests?
• Incident history: What security incidents have occurred? How were they detected, contained, and resolved? What process changes resulted?

Risk signals

• Secrets committed to version control (even if later removed - they are in git history)
• No penetration test in the last 12 months
• Authentication system is custom-built without industry-standard protocols (OAuth 2.0, OIDC)
• No web application firewall or rate limiting on public APIs

Area 5: Tech debt quantification

Every system has tech debt. The question is whether it is managed or ignored.

Questions to investigate

• Debt inventory: Does the team maintain a list of known tech debt items? Are they sized, prioritized, and reviewed regularly?
• Debt allocation: What percentage of engineering capacity is allocated to debt reduction? Teams that spend zero time on debt are accumulating risk. Teams that spend more than 30% may have a structural problem.
• Migration backlog: Are there planned migrations (database upgrades, framework updates, language version bumps) that are overdue?
• Workaround count: How many known workarounds exist in the codebase? Workarounds are debt with a direct operational cost.
• Build and deploy time: How long does a full build take? How long does a deployment take? Slow pipelines are a form of debt that taxes every engineer on every change.
• Flaky tests: What percentage of test runs fail due to test instability rather than real defects? Flaky tests erode confidence in the test suite.

Quantification approach

Estimate debt in terms of engineering weeks to resolve. Group into three buckets:

1. Critical: Debt that blocks feature delivery or poses security/reliability risk. Address within 30 days.
2. Strategic: Debt that slows the team but does not block. Schedule within the next 2 quarters.
3. Cosmetic: Debt that is annoying but has minimal impact. Address opportunistically.

Area 6: Team structure evaluation

Technology is only as good as the team that builds and operates it.

Questions to investigate

• Team composition: What is the ratio of senior to junior engineers? Are there specialists (security, data, infrastructure) or is everyone a generalist?
• Key-person dependencies: Are there critical systems or domains where only one person has deep knowledge? This is a bus factor of one.
• Turnover history: What has engineering turnover been over the past 12-24 months? What were the reasons for departures?
• Development process: What methodology does the team follow? How are priorities set? How is work estimated and tracked?
• On-call and operations: Who handles production issues? Is there a rotation? How many incidents occur per month, and what is the severity distribution?
• Hiring pipeline: Are there open positions? How long have they been open? Prolonged vacancies in critical roles are a capacity risk.

Risk signals

• Bus factor of one on core systems
• Turnover exceeding 25% annually
• No defined on-call rotation
• Engineering team smaller than what the system complexity requires

Area 7: Documentation completeness

Documentation is the difference between a system that can be understood and maintained by new team members and one that requires tribal knowledge.

Questions to investigate

• Architecture documentation: Is there a current architecture diagram? Does it reflect the actual system, not an aspirational future state?
• API documentation: Are APIs documented with request/response examples, error codes, and authentication requirements?
• Runbooks: Do operational runbooks exist for common incidents, deployments, and maintenance tasks?
• Decision records: Are architectural decisions documented with context, alternatives considered, and rationale? Architecture Decision Records (ADRs) are the gold standard.
• Onboarding guide: Can a new engineer set up the development environment and make their first contribution using documentation alone?
• Data dictionary: Is there documentation of database schemas, data flows, and data ownership?

What good looks like

Architecture diagrams are updated within 30 days of significant changes. APIs are documented and examples are tested in CI. Runbooks are reviewed after every incident. New engineers can onboard in under a week using written guides.

Scoring and reporting

After completing each area, assign an overall health rating:

• Green: No significant issues. Minimal risk.
• Yellow: Issues identified but manageable with a clear remediation plan.
• Red: Significant issues that require immediate attention or represent material risk.

Present findings as a summary table with the rating, top 3 findings, and recommended actions for each area. This gives leadership a clear picture without requiring them to read a 50-page report.

Need an expert to run a technical due diligence assessment? CoreLine’s CTO and architecture review services provide an independent, thorough evaluation of your platform’s architecture, code quality, and operational readiness - delivered with actionable recommendations, not just observations.