The Technical Due Diligence Defence Kit.

Do you have current, production-accurate architecture diagrams (components, data stores, network boundaries, trust zones), and can you prove they match reality (IaC + runtime topology)?

What are your known bottlenecks under peak load (CPU, IO, DB locks, queue depth), and what profiling/load evidence proves it?

What is your scaling model (horizontal vs vertical), and which services or data stores are not horizontally scalable today?

Can you define your system's SLOs (availability, latency, error rate) and show recent performance at p95/p99 during peak traffic?

If you are multi-tenant: how do you enforce tenant isolation (data partitioning, authZ boundaries, noisy-neighbour controls, per-tenant rate limits)?

How does your data layer scale: do you have a strategy for read scaling, write scaling, partitioning/sharding, and backfills without downtime?

What is your failure-domain design (zones / regions): which components are single points of failure, and what is the evidence (tested failover) that they aren't?

How do you handle asynchronous work (queues / jobs): retry policies, idempotency guarantees, poison-message handling, backpressure, dead-letter queues?

Can you state (and demonstrate) your RPO / RTO, and have you performed a full restore drill (not a theoretical backup)?

What is your unit economics under scale (cost-per-transaction / cost-per-customer at 10× traffic), and what architectural choices dominate that curve?

Do you have documented coding standards and enforced quality gates (linting / formatting / static analysis) that block merges on high-severity findings?

Can you quantify technical debt in a way an investor can price (top ten debt items, estimated remediation cost, and timeline), and show active paydown?

What is your automated test coverage percentage (unit / integration / e2e split), and how do you measure and prevent test rot?

What is your flake rate (tests that fail non-deterministically), and what is your policy for addressing it before it metastasises?

Where are your highest-risk modules (high churn + high complexity + low test coverage), and what is the mitigation plan?

Are there any "hero components" (critical modules only one engineer can modify safely), and can you prove knowledge distribution?

Do you maintain Architecture Decision Records (ADRs) for irreversible choices (data model, tenancy model, eventing, authN / authZ), and are they current?

What is your policy for dependency hygiene (pinning, upgrades, deprecations), and how quickly do you remediate "vulnerable / outdated components" findings?

Can you demonstrate build determinism (same source → same artefact) across environments, with no manual steps or "it works on my machine" branches?

How do you prevent architecture drift (ad-hoc patterns, inconsistent service boundaries): is there a formal review board or enforcement mechanism?

Do you have a living threat model (assets, actors, attack paths, mitigations) for your highest-value flows (auth, billing, data export, admin actions)?

Are secrets ever committed to source control (keys, tokens, credentials), and do you run automated secret detection over full git history?

Is access control implemented as deny-by-default with explicit authorisation decisions (RBAC / ABAC), and can you demonstrate defence against broken-access-control classes of failure?

Do you enforce least privilege across cloud, CI, and production access (with MFA, short-lived credentials, break-glass procedure, and audited escalation)?

Is data encrypted in transit and at rest, and do you have key management practices (rotation, separation of duties, audit trails)?

Do you have security testing in CI (SAST / SCA / DAST where appropriate), and are findings triaged with defined SLAs and ownership?

Can you produce a Software Bill of Materials (SBOM) (components + supply-chain relationships) for each deployed service within a defined timeframe?

Do you have supply-chain integrity controls (signed builds, provenance, hardened build pipeline), and can you map your posture to a framework such as SLSA?

What is your incident response reality: incident log, mean time to detect / contain, postmortems, and proof that lessons changed controls (not just documents)?

What compliance obligations apply (privacy, industry, customer contracts), and can you show the controls (audit logs, retention, access reviews) that substantiate compliance claims?

Is your CI pipeline a hard gate (tests + lint + security checks), or can engineers bypass it "temporarily"?

Do you run production-like environments (config parity, seeded-data strategy, dependency parity), or are staging and prod fundamentally different?

Can you deploy with zero-downtime patterns (blue / green, canary, rolling with safe migrations), and do you have proven rollback / roll-forward procedures?

Is infrastructure managed as code (versioned, reviewed, reproducible), or are there manual console changes and undocumented drift?

Do you have feature-flag discipline (kill switches, staged rollouts, auditability), or do you ship irreversible behaviour changes by default?

What are your DORA-style metrics (deployment frequency, lead time, change-fail rate, recovery time), and what is the trend over the last two quarters?

Do you have observability that engineers actually use (structured logs, traces, metrics, SLO dashboards, alert hygiene), or just a monitoring vendor invoice?

How is on-call run: incident severity model, escalation, paging policy, postmortems, and evidence that postmortems reduce repeat incidents?

Are releases reproducible and traceable (artefact versioning, provenance, deploy logs, change approvals), and can you tie any production state back to a commit?

Can you demonstrate backup + restore automation and periodic disaster drills, including dependency recovery (not just database snapshots)?

Do all founders, employees, and contractors have signed IP assignment (present assignment, moral-rights handling where relevant, invention assignment, confidentiality)?

Can you prove the company owns the critical repos, domains, cloud accounts, signing keys, and CI / CD credentials (not an individual engineer's personal account)?

Do you maintain an open-source inventory and perform OSS due diligence for licence obligations and vulnerability exposure?

Are there any licences in your codebase that could trigger reciprocal source-disclosure obligations (and do you have counsel-reviewed answers)?

Can you produce a clean data lineage story (where training / production data came from, usage rights, retention, deletion), including contracts where applicable?

What is your effective bus / truck factor for the system (how many people can disappear before you are incapacitated), and what have you done to raise it?

Do you have operational artefacts that survive attrition: runbooks, onboarding, architecture docs, ADRs, incident retros, and are they used (not archived)?

Are any core components dependent on a single vendor or proprietary dependency without an exit plan (migration path, dual-run strategy, cost of escape)?

Can a new senior engineer get a full dev environment running from scratch in under a day, using documented steps and reproducible tooling?

If your CTO or lead architect left tomorrow, what would actually break inside thirty days (delivery, reliability, security, customer escalations), and what mitigations exist today?