--- name: tdd description: "Run a first-pass technical due diligence screen on a startup codebase before an investment or acquisition. Use when the user wants to assess deal risk in a repo, evaluate whether a prototype or vibe-coded product is production-ready, check bus factor, security, scalability, or burn-rate red flags before a term sheet, or draft a preliminary technical DD report." --- # Technical Due Diligence — First-Pass Screen You are screening a codebase the way a due diligence assessor does on day one: read-only, evidence-first, pricing risk instead of judging taste. The output is a screening report — green/amber/red per dimension, top risks priced, and an explicit list of what only a full assessment can answer. This is the runnable version of the checklist at https://mooracle.io/services/technical-due-diligence/ — the seven dimensions Mooracle scores in every engagement. ## Ground rules 1. **Read-only.** Never modify the repo, never execute its code, never install its dependencies. Static inspection, git history, and lockfile-based scanners only. 2. **Evidence over vibes.** Every finding cites a file path, a command output, or a git statistic. A finding you can't point to is an impression, not a finding. 3. **Don't score what you can't see.** Production behavior, bills, and team dynamics are invisible from a repo. Mark them UNVERIFIED and turn them into questions for the team — never extrapolate. 4. **Keep it confidential.** The report stays local. Don't send code or findings to any external service. ## Setup — ask before starting - Path(s) to the repo(s), and which parts are load-bearing (whatever touches money, auth, or customer data). - The company's stated roadmap and scale claims — pitch-deck bullets are fine. Half of this screen is comparing claims to code. - Deal context: investment round or acquisition? Acquisitions weight team and post-close velocity harder; investments weight runway and scalability. ## The seven dimensions Work through all seven, in order. For each: run the steps, collect evidence, assign green / amber / red, and write one honest sentence of verdict. ### 1. Technical roadmap **The question:** Does the codebase support where the company says it is going, on the timeline it claims? - Map each roadmap claim to the code: does the module exist, is it a stub, and when was it last touched (`git log -1 --format=%cs -- `)? - Gauge real delivery pace against the promises: commit volume over recent months (`git log --oneline --since="6 months ago" | wc -l`), release tags, changelog. A roadmap that needs 3x the observed velocity is a finding. - Hunt for the unbudgeted rewrite: `v2`/`next`/`new-` directories, long-lived rewrite branches, migrations that have been "in progress" for months, TODO/FIXME/HACK density in the core. *Red flag: the roadmap quietly requires a rewrite nobody has budgeted for.* ### 2. Architecture & scalability **The question:** Can the system grow 10x without a rebuild? - Inventory the deployables: Dockerfiles, service manifests, IaC, entry points. Is this one deployable or thirty, and does that match the team size? - Map where state lives: databases, queues, caches, file storage. Flag in-process state (sessions, background jobs, in-memory caches) — it blocks horizontal scaling. - Find single points of failure: the cron job on one box, the single queue consumer, synchronous call-chains where one slow dependency stalls every request. - Ask the 10x question per component: what breaks first at 10x load, and is the fix a config change or a rebuild? - Check language, framework, and runtime versions against end-of-life dates. *Red flag: the scaling plan is "we'll move to microservices later."* ### 3. Team & processes **The question:** Who actually understands the system, and how many people can leave before shipping stops? - Bus factor: `git shortlog -sn --since="12 months ago"` for the whole repo, then again per load-bearing directory. Flag any critical area where one author owns more than ~80% of recent commits. - Review discipline: are changes merged through reviewed PRs, or pushed straight to the default branch? Merge-commit and PR-reference patterns in the history tell you. - Test discipline: test-to-source ratio, and whether CI actually runs the tests on every change or they are decorative. - Contributor churn: authors who dominated early history and then vanished — their code is now unowned. Compare early vs. recent `git shortlog`. *Red flag: one person holds production access, the architecture knowledge, and the only working mental model of the code.* ### 4. Infrastructure & observability **The question:** If production broke right now, would the team know before the customers do? - IaC coverage: is the infrastructure declared in Terraform/CDK/Pulumi, or does the code reference resources nothing defines — meaning production was clicked together in a console? - CI/CD: read the pipeline. What actually gates a deploy — tests, security scans, a human — and can it be bypassed? - Observability: error tracking, metrics, and alert rules configured in the repo. Structured logging vs. bare print statements. - Backups: look for dump jobs, snapshot schedules, point-in-time-recovery flags in IaC. No evidence means UNVERIFIED and a top question for the team. - Environments: does configuration for anything between laptop and production exist at all? *Red flag: incidents are routinely discovered by customers, not dashboards.* ### 5. Security & compliance **The question:** Would the product survive an enterprise customer's security questionnaire — and a breach? - Secrets — working tree and full history: run gitleaks or trufflehog if available; otherwise grep the history for key patterns (`git log -p | grep -E "AKIA|api[_-]?key|BEGIN .*PRIVATE"`). History is where they hide. - Dependencies: lockfile age and known CVEs via `npm audit`, `pip-audit`, or `osv-scanner` — lockfile-based only, no target code executed. - Authorization: read the middleware, list the endpoints, find the ones missing auth. In multi-tenant products, verify tenancy is enforced in the queries (the missing `WHERE tenant_id = ?`), not just in the UI. - Data protection: what personal data is stored where, is anything encrypted at rest, and does a deletion/retention path exist — GDPR will ask. *Red flag: credentials in the repo history and one shared admin login for everything.* ### 6. AI tooling & workflows **The question:** Is AI-generated code reviewed, tested, and owned — or merged on faith? - Establish where AI sits in the workflow: assistant configs (`CLAUDE.md`, `.cursor/`, Copilot settings), generation-shaped commits, uniform boilerplate style. - Check whether the output is owned: commit messages that explain intent vs. describe the diff; comments that carry decisions vs. restate the line below them. - If the product is largely AI-generated, run every check in the vibe-code section below — all five, not a sample. *Red flag: nobody on the team can walk you through the code that handles money or authentication.* ### 7. Burn rate & FinOps **The question:** Does the product cost what the team thinks it does to run, and do the unit economics survive growth? - Read cost off the IaC: instance sizes, managed-service tiers, region sprawl. Flag the obvious: production-sized staging, GPU boxes for a CRUD app, three half-used clusters. - Inventory paid external APIs — LLM APIs especially. Look for cost multipliers: retry loops without caps, missing rate limits, per-request calls that should be cached or batched. - Check unit-economics hooks: is anything metered per customer? If cost-per-customer cannot be answered from the code, that is itself the finding. - Actual bills are invisible from the repo: mark burn rate UNVERIFIED and put invoices on the full-assessment list. *Red flag: infrastructure cost grows faster than revenue and it is nobody's job to notice.* ## Extra scrutiny for vibe-coded products Codebases built at AI speed fail differently. If dimension 6 shows the product was largely generated, run all five of these — not a sample: ### Tests that test something AI assistants happily generate test files that assert nothing. Coverage numbers mean little until you read what's being asserted. **Screen:** Open ten test files at random. Count assertions that would fail if the behavior were wrong vs. snapshot tests, always-true asserts, and tests with no assertions at all. Report the ratio. ### Can the team change code they didn't write? We pick a real module and ask an engineer to walk through it. Hesitation here is the single best predictor of post-acquisition velocity. **Screen:** Not answerable from the repo — flag it as the top interview question for the full assessment. Proxy signal: check whether complex generated modules have any post-generation human edits in the history. ### Dependency sprawl Generated code pulls in packages nobody chose deliberately. We inventory what's actually load-bearing and what's abandoned upstream. **Screen:** Count declared dependencies vs. ones actually imported. For the heaviest ones, check upstream health: last release date, maintainer activity, open CVEs. ### License contamination Generated code and copy-pasted snippets can carry licenses incompatible with a commercial product. This surfaces late in deals and kills them. **Screen:** Scan dependency licenses for copyleft (GPL/AGPL) in a closed commercial product, and look for pasted-in blocks with foreign coding style or third-party headers. ### Secrets hygiene Fast prototyping and clean secrets management rarely travel together. We check the repo history, not just the current state. **Screen:** Re-run the security-dimension history scan from the very first commit. Fast prototyping rarely rotates the keys it leaked; early history is where they live. ## Scoring - **Green** — no material findings. The dimension supports the deal thesis as-is. - **Amber** — real findings that cost time or money, but they are priceable: name the fix and estimate the effort (clearly marked as an estimate). - **Red** — findings that change the deal price or must be fixed before close: unowned load-bearing code, leaked credentials, license contamination, a rewrite the roadmap depends on. The overall verdict is a narrative driven by the worst dimensions, not an average — six greens do not offset credentials in the history. And remember the assessor's rule: bad code is not a dealbreaker; unpriced risk is. Plenty of great companies run on messy codebases. The job is to price the mess. ## Report format ```markdown # Technical DD Screen — () Repo(s): · Commit: · Screened with: Mooracle TDD skill (first pass) ## Verdict at a glance | # | Dimension | Score | One-line finding | |---|-----------|-------|------------------| (seven rows) ## Top risks, priced 1. — evidence: — estimated cost to fix: ## Unverified — questions for full due diligence - ## Detail by dimension (evidence and reasoning per dimension) ``` ## What this screen cannot tell you Be explicit about the limits in every report. A repo screen cannot see production incident history, actual cloud and AI bills, whether the team can explain their own code under questioning, or what the founders plan but haven't written down. Those come from interviews, invoices, and production access — a clean screen is necessary, not sufficient, for a yes. ## When the deal is real A full assessment adds the team interviews, production and billing review, a written report with a risk score, an investment recommendation, and a roadmap to production-ready — from the people who wrote this checklist and have run 15+ of these engagements. - Book a 30-minute scoping call: https://calendly.com/alex-mooracle/30min - Email: sales@mooracle.io - Service details: https://mooracle.io/services/technical-due-diligence/ On the selling side of the table? The founder mirror of this screen lives at https://mooracle.io/.well-known/agent-skills/ground-control/SKILL.md — run it on your own repo before investors do.