The technical due diligence checklist investors actually use

Architecture & scalability

The question is never "is the architecture modern?" It's "does the architecture survive the business plan?"

• ☐ System diagram exists, matches reality, and an engineer other than its author can walk through it.

• ☐ Load headroom is known: what breaks first at 10× current volume, and has anything like that scale been tested or reasoned about.

• ☐ Single points of failure are identified — databases, queues, third-party APIs — with a stated tolerance for each.

• ☐ Infrastructure cost per customer/transaction is known and doesn't quietly destroy gross margin at plan targets.

• ☐ Build-vs-buy decisions look sane: no hand-rolled auth, payments, or crypto where proven services exist; no vendor lock-in that blocks the roadmap.

• Red flags: "only Dave understands that service" · a rewrite already underway without a migration plan · architecture chosen to pad résumés, not serve load.

Code quality & delivery pipeline

Code quality is not aesthetics — it's the cost of the next feature.

• ☐ A new engineer can run the system locally and ship a small change in under a week — the single best proxy for codebase health.

• ☐ Tests exist where they matter: revenue paths, data integrity, integrations. Coverage percentage is less telling than what's covered.

• ☐ CI/CD is real: automated builds, repeatable deploys, a rollback story that has been exercised — not a wiki page of manual steps.

• ☐ Delivery metrics trend visibly: deployment frequency, lead time, change-failure rate. Teams that don't measure these usually can't answer "when will it be done."

• ☐ Technical debt is inventoried and priced, not denied. Every codebase has it; mature teams know where theirs is.

• Red flags: deploys require a specific person · long-lived feature branches merged quarterly · "we'll add tests after the raise."

Team & key-person risk

• ☐ Bus factor: for each critical system, at least two people can operate and extend it. A bus factor of one anywhere critical is a valuation problem, not a staffing note.

• ☐ Ownership is legible: who decides architecture, who owns production, who is accountable for delivery — answered identically by the CEO and the engineers.

• ☐ Retention risk is assessed: vesting cliffs near the transaction, key people whose equity outcome makes them flight risks at close.

• ☐ Contractor and agency work is contractually clean: IP assigned, access revocable, knowledge transferred — not living in a departed freelancer's head.

• Red flags: the founder is still the only person who can deploy · interviews where engineers contradict the CEO's technical story · a team that describes the roadmap as "whatever comes in this week."

Security & compliance

• ☐ Access control basics: SSO/MFA on critical systems, least-privilege on production, offboarding that provably revokes access.

• ☐ Secrets management: no credentials in the repository or its history; rotation is possible without a war room.

• ☐ Incident history is documented — including the embarrassing ones. Zero recorded incidents means nobody's looking.

• ☐ Backups exist AND restores have been tested. An untested backup is a hope, not a control.

• ☐ Compliance posture matches the market: SOC 2 / ISO 27001 where enterprise buyers demand it; GDPR / PIPEDA / CCPA data handling where users are; sector rules (HIPAA, PCI-DSS) where applicable.

• Red flags: shared admin accounts · production data in developer laptops · a pen test that was never remediated · "we're too small to be a target."

IP & open-source licensing

• ☐ Every contributor — employee, contractor, agency, co-founder's friend from 2019 — has signed IP assignment. Gaps here stall closings.

• ☐ A dependency inventory exists with licenses classified. Copyleft licenses (GPL, AGPL) linked into proprietary code are a legitimate deal-stopper; permissive licenses (MIT, Apache-2.0, BSD) need attribution hygiene.

• ☐ Nothing proprietary was published publicly by accident, and nothing public is passing as proprietary.

• ☐ Trademarks, domains, and app-store accounts are owned by the company, not a founder's personal account.

• Red flags: "we forked it years ago, license unclear" · a core algorithm copied from a previous employer · AGPL in the backend of a SaaS.

Data & AI exposure — the 2026 additions

Two years of AI-assisted building created a new diligence category. Most checklists haven't caught up.

• ☐ AI-generated code provenance: how much of the codebase was AI-written, and was it reviewed by someone who understands it? Unreviewed generated code is unaudited code.

• ☐ Model and provider dependencies: which product features die if a model provider changes pricing, deprecates an API, or bans the use case? Is there a fallback?

• ☐ Customer data and third-party AI: what leaves the boundary, under which data processing agreements, and does the privacy policy actually permit it?

• ☐ Prompt-injection and abuse surface for user-facing AI features: has anyone tried to break it before a customer does?

• ☐ Unit economics of AI features: inference cost per user at plan scale — margins have quietly inverted on this line item.

• Red flags: "the AI part was built by a contractor with ChatGPT and he's gone" · customer PII in fine-tuning sets · demo features that cost more per use than the product's price.

Roadmap credibility

• ☐ The financial model's product promises are costed in engineering time by someone who has shipped comparable systems — and the two documents agree.

• ☐ Recent delivery history supports the projected velocity. Teams do not triple their shipping rate because a deck says so.

• ☐ The hiring plan is realistic for the market and the team can absorb it — doubling headcount halves velocity for a quarter before it helps.

• Red flags: a roadmap with no dependencies on the debt inventory · "the rewrite will make everything after it fast" · enterprise features promised with no compliance line item.

For founders: how to prepare (sell-side)

The highest-leverage move is running this checklist on yourself before your investors do.

• Build the data room early: architecture overview, dependency/license inventory, security policies and incident log, delivery metrics, org chart with ownership, and an honest technical-debt register with remediation costs.

• Disclose weaknesses with plans attached. "Known, priced, scheduled" reads as operational maturity. Discovered concealment reprices the whole company, not just the finding.

• Fix the two-week items: secrets out of the repo, MFA everywhere, an IP-assignment sweep, a tested restore. Cheap fixes that remove entire finding categories.

• Consider a readiness review: an independent audit before the raise — here's what that looked like for one client — turns diligence from an exam into a confirmation.