Technical Due Diligence: So bereiten sich Startups ohne Theater vor
Due Diligence belohnt nicht perfekte Systeme, sondern nachvollziehbare Entscheidungen und kontrollierte Risiken. Kurz vor dem Datenraum kosmetisch Dokumente zu erzeugen ist weniger wirksam als Lücken offen zu benennen und zu steuern.
Was typischerweise geprüft wird
- Produktarchitektur und kritische Abhängigkeiten
- Codequalität, Tests, Delivery- und Release-Prozess
- Cloud-Betrieb, Verfügbarkeit, Backups und Monitoring
- Security, Datenschutz und Incident-Historie
- Skalierungsgrenzen und laufende Kosten
- Team, Schlüsselpersonen und externe Abhängigkeit
- Eigentum an Code, Konten, Domains und geistigem Eigentum
Der schlanke Datenraum
Stelle Architekturübersicht, Systeminventar, Roadmap, Betriebskennzahlen, Security-Prozesse, wesentliche Verträge und ein aktuelles Risikoregister bereit. Dokumente sollten Datum, Owner und Status tragen. Zugang erfolgt nach Need-to-know und wird protokolliert.
Vorher selbst testen
Wähle fünf kritische Behauptungen – etwa Restore-Fähigkeit, Deployment, Eigentum, Skalierung und Zugriffskontrolle – und verlange Evidenz. Führe ein Probeinterview mit Produkt- und Tech-Verantwortlichen durch. Widersprüche zwischen Pitch, Architektur und Realität sind meist problematischer als eine erklärte technische Schuld.
Lücken richtig kommunizieren
Für jede wesentliche Lücke: Auswirkung, aktueller Schutz, Owner, Termin und Aufwand. Verstecken erzeugt Vertrauensverlust; eine glaubwürdige Roadmap zeigt Kontrolle.
Der Technical-Founder-Check gibt eine erste Readiness-Einschätzung. Ein unabhängiges Review sollte vor dem eigentlichen Prozess genügend Zeit für echte Korrekturen lassen.