Ob bei einer Finanzierungsrunde, einem M&A-Deal oder einer strategischen Partnerschaft. die technische Due Diligence wird immer wichtiger. Investoren und Käufer wollen verstehen, ob die Technologie hält, was das Pitch Deck verspricht. Dieser Artikel gibt Einblick, worauf wirklich geachtet wird.
Was ist Tech Due Diligence?
Tech Due Diligence ist die systematische Prüfung der technologischen Assets, Risiken und Fähigkeiten eines Unternehmens im Rahmen einer Transaktion. Sie beantwortet zentrale Fragen:
- Ist die Technologie solide und skalierbar?
- Gibt es versteckte technische Risiken?
- Kann das Team die Roadmap umsetzen?
- Stimmen die technischen Behauptungen im Pitch?
Die 8 Dimensionen der Tech Due Diligence
1. Architektur und Skalierbarkeit
Was geprüft wird:
- Systemarchitektur (Monolith, Microservices, Serverless)
- Skalierungsfähigkeit (horizontal, vertikal)
- Datenbank-Design und -Performance
- API-Design und Versionierung
- Cloud-Infrastruktur und IaC
Typische Fragen:
- Wie würde das System mit 10x mehr Nutzern umgehen?
- Gibt es Single Points of Failure?
- Wie lange dauert ein Deployment?
- Was ist die aktuelle Latenz/Uptime?
Red Flags:
- Keine dokumentierte Architektur
- Starke Vendor-Abhängigkeit
- Manuelle Skalierung erforderlich
- Keine Monitoring-Strategie
2. Code-Qualität und Tech Debt
Was geprüft wird:
- Code-Review-Prozesse
- Test-Coverage und -Qualität
- Dokumentation (Code, APIs, Architektur)
- Dependency-Management
- Technische Schulden
Metriken:
| Metrik | Gut | Akzeptabel | Kritisch |
|---|---|---|---|
| Test Coverage | >80% | 50-80% | <50% |
| Code Duplication | <5% | 5-15% | >15% |
| Dependency Age | <1 Jahr | 1-2 Jahre | >2 Jahre |
| Security Vulnerabilities | 0 Critical | <3 High | Any Critical |
Red Flags:
- Keine automatisierten Tests
- Veraltete Dependencies mit bekannten Vulnerabilities
- "Nur Entwickler X versteht diesen Code"
- Keine Code-Reviews
3. Team und Organisation
Was geprüft wird:
- Team-Struktur und Verantwortlichkeiten
- Skill-Mix und Erfahrung
- Retention und Fluktuation
- Hiring-Pipeline und -Prozesse
- Key Person Dependencies
Typische Fragen:
- Wie ist das Team organisiert?
- Welche Skills fehlen aktuell?
- Wie hoch ist die Fluktuation?
- Was passiert, wenn die Lead-Entwickler gehen?
Red Flags:
- Hohe Fluktuation im Tech-Team
- Single Point of Failure bei Schlüsselpersonen
- Keine klaren Ownership-Strukturen
- Offshore-Team ohne klare Governance
4. Security und Compliance
Was geprüft wird:
- Security-Policies und -Prozesse
- Verschlüsselung (at rest, in transit)
- Access Control und IAM
- Compliance-Status (DSGVO, SOC 2, ISO 27001)
- Incident History
Due-Diligence-Anforderungen:
- Penetration Test Results (letzte 12 Monate)
- Security Audit Reports
- Data Processing Agreements
- Privacy Policy und Cookie-Compliance
- Incident Response Plan
Red Flags:
- Keine Security-Audits oder Pentests
- Bekannte ungepatchte Vulnerabilities
- Keine Verschlüsselung sensibler Daten
- Compliance-Verstöße
5. Intellectual Property
Was geprüft wird:
- Eigentum am Code (Employment Agreements, IP Assignments)
- Open-Source-Compliance (Lizenzen)
- Patente und Trade Secrets
- Third-Party-Code und -Lizenzen
Typische Dokumente:
- IP Assignment Agreements für alle Entwickler
- Open-Source-Lizenz-Audit
- Patent-Portfolio (falls vorhanden)
- Vendor/License Agreements
Red Flags:
- Freelancer ohne IP-Assignment
- GPL-Code in proprietärem Produkt
- Unklare Eigentumsverhältnisse
- Lizenz-Verstöße
6. DevOps und Operations
Was geprüft wird:
- CI/CD-Pipeline und Deployment-Prozess
- Monitoring und Alerting
- Incident Management
- Disaster Recovery und Business Continuity
- SLAs und Uptime History
Metriken (DORA):
| Metrik | Elite | Durchschnitt | Warnsignal |
|---|---|---|---|
| Deployment Frequency | Täglich+ | Wöchentlich | Monatlich |
| Lead Time | <1 Tag | 1-7 Tage | >1 Monat |
| MTTR | <1h | <1 Tag | >1 Woche |
| Change Failure Rate | <15% | 15-30% | >30% |
Red Flags:
- Manuelle Deployments
- Keine Staging-Umgebung
- Kein Monitoring/Alerting
- Kein dokumentierter DR-Plan
7. Data und Analytics
Was geprüft wird:
- Datenmodell und -qualität
- Data Pipeline Architecture
- Analytics Capabilities
- ML/AI-Modelle (falls relevant)
- Data Governance
Typische Fragen:
- Wie werden Daten gesammelt und verarbeitet?
- Welche Daten sind wirklich proprietär/wertvoll?
- Wie gut ist die Datenqualität?
- Gibt es Data Governance Policies?
Red Flags:
- Keine Datenvalidierung
- DSGVO-Verstöße bei Datensammlung
- Keine Backups oder Backup-Tests
- ML-Modelle ohne Dokumentation
8. Product-Tech Alignment
Was geprüft wird:
- Passt die Architektur zur Product-Vision?
- Ist die Roadmap realistisch umsetzbar?
- Stimmen die technischen Behauptungen im Pitch?
- Gibt es Tech-Blocker für geplante Features?
Typische Fragen:
- Kann das Team die Roadmap in der angegebenen Zeit umsetzen?
- Welche technischen Risiken gibt es für die geplanten Features?
- Wo wird die meiste Engineering-Zeit verbracht (Features vs. Maintenance)?
Der Due-Diligence-Prozess
Ablauf (typischerweise 2-4 Wochen)
Woche 1: Dokumentation
- Data Room mit allen relevanten Dokumenten
- Architektur-Dokumentation
- Security Reports
- Team-Informationen
Woche 2: Interviews
- CTO/VP Engineering
- Key Technical Leads
- DevOps/Security
- Optional: Product
Woche 3: Code und System Review
- Code-Walkthrough
- System-Demo
- Repository-Analyse
- Security Assessment
Woche 4: Findings und Report
- Zusammenfassung der Erkenntnisse
- Risk Assessment
- Empfehlungen
- Q&A mit dem Investor/Käufer
Typische Deliverables
- Technical Assessment Report
- Executive Summary
- Bewertung je Dimension
- Identified Risks
- Empfehlungen
- Risk Matrix
- Critical/High/Medium/Low Risks
- Mitigations
- Timeline für Behebung
- Technical Scorecard
- Scoring je Dimension
- Benchmark gegen Industry Standards
- Trend (falls Follow-up DD)
Vorbereitung auf die Tech DD
Was Sie vorab tun sollten
Dokumentation aufbereiten:
- Architektur-Diagramme aktualisieren
- README und Onboarding-Docs
- API-Dokumentation
- Security Policies
Technical Debt adressieren:
- Kritische Vulnerabilities fixen
- Dependency-Updates durchführen
- Test-Coverage erhöhen
Team vorbereiten:
- Key Persons briefen
- Konsistente Narrative sicherstellen
- Potenzielle Fragen antizipieren
Typische Stolpersteine
- Übertreibungen im Pitch: Was technisch behauptet wurde, muss stimmen
- Undokumentierte Systeme: Investoren misstrauen Black Boxes
- Defensive Haltung: Transparenz schafft Vertrauen
- Last-Minute Cleanup: Wird erkannt und wirkt unprofessionell
Ausblick
Tech Due Diligence ist keine Prüfung, die man bestehen oder nicht bestehen kann. Sie ist eine Gelegenheit, die technische Substanz des Unternehmens zu demonstrieren und Vertrauen aufzubauen.
Die wichtigsten Erfolgsfaktoren:
- Vorbereitung: Dokumentation und Team ready machen
- Transparenz: Probleme proaktiv ansprechen, nicht verstecken
- Narrative: Konsistente Story über Technologie und Roadmap
- Professionalität: Strukturierte Antworten, realistische Einschätzungen
Ein positives DD-Ergebnis kann die Bewertung erhöhen und Verhandlungspositionen stärken. Ein negatives kann Deals platzen lassen oder zu erheblichen Abschlägen führen. Die Investition in solide technische Grundlagen zahlt sich spätestens hier aus.