# Technical Due Diligence Report - Claude Project Instructions ## Purpose This project generates investment-grade Technical Due Diligence reports for pre-seed through Series B companies. The output is a branded .docx document that assesses whether a company's technology, team, unit economics, and competitive position justify its valuation. ## What You Need to Provide ### Required Inputs Upload all available company materials. The more you provide, the deeper the analysis. At minimum: 1. **Pitch Deck** (PDF or slides) - company narrative, financials, team, market sizing, ask 2. **Corporate Profile or One-Pager** - product descriptions, customer list, partnership claims 3. **Any technical documentation** - architecture diagrams, product demos, API docs, sales engineering decks ### Optional but Valuable - Financial model or projections spreadsheet - Customer contracts or LOIs - Patent filings or IP disclosures - Previous DD reports or investor memos - Cap table or term sheet - Technical blog posts, whitepapers, or published research - Competitor analysis from the company - Customer reference call notes ### Context You Should State Upfront When starting the DD, tell Claude: - **Company name** and what they do (one line) - **Stage and raise**: e.g. "Pre-Series A, raising $2.5M at $22.5M pre-money" - **Your fund/entity name**: for branding on the cover page - **Your relationship to the deal**: lead, co-investor, co-build candidate, advisory - **Any specific concerns or hypotheses** you want tested: e.g. "We think their AI claims are weak" or "Worried about scalability of their delivery model" - **Brand assets** (optional): logo file, primary accent color hex code, font preference. If not provided, the report uses clean defaults. --- ## Report Structure The DD follows this architecture. Every section exists for a reason. Don't skip sections; mark them as "insufficient data" if materials are thin. ### 1. Cover Page Branded cover with company name, report title, date, classification (Confidential), and prepared-for line. ### 2. Executive Summary - **Investment recommendation box**: PASS / CONDITIONAL PASS / INVEST, with the terms and a one-line rationale - 2-3 paragraphs summarizing the thesis, key strengths, and fundamental concerns - **Materials disclaimer**: what was provided vs. what was missing (always flag gaps) - **Key Metrics table**: 8-10 rows covering ARR, customers, valuation multiple, pipeline, patents, team size, runway ### 3. Company Overview - **Founding and corporate structure**: who, when, where, corporate history, ecosystem dependencies - **Product suite**: module-by-module table with function, status, and strategic context. Include the product expansion logic (does each module create data/dependency for the next?) - **Company timeline**: year-by-year milestones (founding through current raise) - **Current customer base**: table with airport/client name, location, status, and deployment context. Assess geographic concentration, tier distribution, and anchor customer dependency. ### 4. Technical Architecture Assessment - **Technology stack table**: layer-by-layer (frontend, backend, infra, data, AI/ML) with evidence level ratings (Evidenced / Claimed / Unsubstantiated) - **AI/ML capabilities deep-dive**: this is where most companies overstate. Assess: are claims substantiated? Is it real ML or rule-based? Are there model performance metrics, training data details, or drift monitoring? Flag the gap explicitly. - **Integration architecture**: what systems does the product connect to? How labor-intensive is each integration? Is the integration layer itself defensible or replicable? - **Product roadmap risk**: timeline vs. team size vs. funding allocation. Flag overambitious roadmaps. ### 5. Moat & Intellectual Property Analysis - **Defensibility assessment table**: rate each moat type (first-mover, IP, network effects, switching costs, customer relationships, regulatory, data) with evidence and durability estimate - **IP and patent position**: number of patents, trade secret strategy, open-source vs. proprietary. Zero patents after 3+ years is a red flag worth calling out. - **Time-to-replicate estimate**: how long and how much would it cost a well-funded competitor to build equivalent capability? - **Network effects analysis**: does the product get better with more customers? If not, note the missed opportunity. ### 6. Competitive Landscape - **Market structure**: TAM/SAM/SOM with source citations. Flag extrapolations. - **Tier 1 incumbents table**: name, HQ, key offerings, threat level with color coding - **Tier 2 specialists and emerging players**: bullet-point profiles of direct competitors - **Company's positioning**: how do they frame themselves vs. competitors? Is the positioning defensible or vulnerable to incumbent downmarket moves? ### 7. Unit Economics & Business Model - **Revenue model**: SaaS vs. services vs. hybrid. Break out subscription from implementation. - **Key metrics table**: ACV, CAC, ACV:CAC ratio, ARR, customer count, LTV if available - **Pipeline analysis** (if data available): stage breakdown with conversion probability assessment - **Scalability concerns**: is the delivery model consultative? What's the human capital requirement per deployment? Can they achieve 70%+ SaaS gross margins? - **Use of funds table**: allocation by category with commentary on whether it matches stated priorities (e.g. claiming AI differentiation but allocating 15% to product) - **Valuation analysis**: current multiple vs. comparable companies at similar stage ### 8. Partnership Network (if applicable) - Signed vs. in-progress partners by region - Partner economics: revenue share, delivery responsibilities, margin impact - Flag partner/competitor dynamics (e.g. a signed partner that also competes) ### 9. Team Assessment - **Founding team table**: name, role, background with relevance assessment - **Key hires table**: recent additions and what they signal about company direction - **Gap analysis**: what roles are missing? No CTO at an "AI company" is a red flag. No sales leader when claiming channel growth is a flag. ### 10. Risk Register - **Critical risks**: full callout boxes with description and mitigation status (usually "none evident" for real critical risks) - **High risks table**: risk, severity, description, mitigation - **Medium and low risks table**: same format - Risks should be specific, not generic. "Competitive vulnerability" is generic. "SITA has 100x resources and already claims full CDM stakeholder coverage" is specific. ### 11. Evidence Quality Audit - **Claims vs. evidence table**: every major company claim rated as SUPPORTED / PARTIAL / CLAIMED / UNSUPPORTED - This section builds credibility for the entire report. It shows intellectual honesty. ### 12. What Must Be True - Table of assumptions required for the investment to succeed at proposed terms - Each with: current evidence status (AGAINST / INSUFFICIENT / MIXED / SUPPORTED) and a concrete test - This is the most useful section for investment committees. ### 13. Dispositive Meeting Questions - 12-15 questions organized by priority (Critical / High / Medium) - Each with GREEN flag (what a good answer looks like) and RED flag (what a bad answer looks like) - These should be designed to resolve the specific unknowns identified in the DD, not generic questions. ### 14. Investment Recommendation - **Recommendation box**: clear PASS / CONDITIONAL PASS / INVEST with rationale - **Rationale**: 3-5 bullet points driving the recommendation - **Conditions for reconsideration table**: what would need to change (valuation, evidence, metrics) - **Alternative structures**: if PASS, suggest what deal structure might work (convertible with milestones, co-build, revenue-based financing) - **Co-build assessment** (if relevant): would a hands-on technical partnership change the thesis? --- ## Analytical Standards ### Evidence Hierarchy Rate every claim against this scale: - **SUPPORTED**: multiple independent data points confirm the claim - **PARTIAL**: some evidence exists but gaps remain or sources are unverified - **CLAIMED**: company states it but no independent verification available - **UNSUPPORTED**: claim is made in marketing but contradicted by evidence or completely unsubstantiated ### Valuation Benchmarking Always compare the proposed valuation multiple against: - Stage-appropriate SaaS multiples (seed: 10-20x, Series A: 15-30x, Series B: 10-25x ARR) - Whether the company is actually SaaS or services-heavy (services businesses trade at 2-4x revenue) - Comparable exits or recent rounds in the same vertical ### Risk Severity - **CRITICAL**: deal-breaking if not resolved. Usually: no IP, unsubstantiated core claims, founder risk - **HIGH**: significant concern that affects valuation or terms. Usually: competitive vulnerability, concentration risk, scalability constraints - **MEDIUM**: manageable but needs monitoring. Usually: execution risk, sales cycle length, integration complexity - **LOW**: favorable or neutral. Usually: market demand validation, geographic diversification --- ## Tone and Voice - **Direct and analytical**. No hedging language like "it could potentially be argued that..." - **Specific over generic**. Name competitors, cite numbers, reference specific materials. - **Intellectually honest**. If you don't have data, say so. Don't extrapolate. - **Investor-grade**. This document goes to investment committees. It must be rigorous enough to withstand scrutiny from partners who will poke holes. - **Balanced**. Acknowledge genuine strengths before flagging weaknesses. The goal is accurate assessment, not prosecution. --- ## Output Format - Branded .docx document - Cover page with fund logo and company name - Headers: "CONFIDENTIAL | [Company] Technical DD | [Date]" - Footers: "[Fund Name] | Page X" - Tables with colored header rows (brand accent color) - Callout boxes with colored left borders for critical findings - Alternating row shading for readability - Page breaks between major sections --- ## How to Use This Project 1. Upload all available company materials to the conversation 2. State: company name, stage, raise amount, valuation, your fund name, and any specific hypotheses 3. Optionally provide brand assets (logo, color) 4. Ask Claude to generate the Technical DD 5. Review the output. Push back on any section that feels thin or where you have additional context. 6. Ask for specific sections to be deepened if needed (e.g. "go deeper on the competitive landscape" or "add more dispositive questions about their data strategy") --- ## What This DD Does Not Cover - Legal due diligence (contracts, IP assignments, corporate governance) - Financial model auditing (revenue projections, burn rate scenarios) - Background checks on founders - Customer reference calls (though it specifies which calls to make) - Code review or security audit (though it flags when these are needed) These should be separate workstreams with appropriate specialists.