Ein Begriff, der im Pitch Deck auftaucht, aber selten erklärt wird
“Technische Due Diligence” steht meistens klein gedruckt in der Timeline zur Finanzierungsrunde, irgendwo zwischen Term Sheet und Signing. Die wenigsten Gründerinnen und Gründer wissen vorher genau, was dabei geprüft wird, wer es prüft und was am Ende auf dem Spiel steht. Das ist kein Wissen, das man als technischer Gründer automatisch mitbringt, und auch als nicht-technischer Gründer mit starkem CTO bleibt oft unklar, wie tief ein Investor tatsächlich reinschaut. Deshalb der Reihe nach: was passiert, warum es wichtiger ist als ein reiner Pass-Fail-Check, und wie du dich vorbereitest, ohne in Panik zu verfallen.
Was ein Investor sich tatsächlich ansieht
Technische Due Diligence ist kein Audit im Sinne einer Checkliste, die du einfach abhaken kannst. Meistens beauftragt der Investor ein externes Team oder einen erfahrenen CTO, der sich in wenigen Tagen ein Bild von deinem System macht. Fünf Bereiche tauchen dabei fast immer auf.
Code-Qualität und Wartbarkeit. Nicht, ob der Code schön ist, sondern ob ein neues Teammitglied sich innerhalb vernünftiger Zeit zurechtfindet. Testabdeckung, Struktur, Dokumentation, ob es überhaupt eine erkennbare Architektur gibt oder ob jede Funktion ihre eigene Lösung erfunden hat.
Skalierbarkeit gegenüber dem, was das Pitch Deck verspricht. Wenn dein Deck zehnfaches Nutzerwachstum in zwölf Monaten zeigt, schaut sich die Due Diligence an, ob die Architektur das überhaupt hergibt, oder ob an der Datenbank, an einzelnen Diensten oder an der Infrastruktur harte Grenzen liegen, die vorher niemand angefasst hat.
Sicherheit und Umgang mit Daten. Wie Zugänge verwaltet werden, ob es Grundlagen wie Verschlüsselung und saubere Trennung von Umgebungen gibt, ob personenbezogene Daten so gespeichert werden, wie es die eigene Datenschutzerklärung behauptet. Das ist selten spektakulär, aber genau deshalb wird es geprüft: Lücken hier sind teuer und öffentlich, wenn sie später auffliegen.
Abhängigkeit von einzelnen Köpfen. Eine der häufigsten Fragen lautet sinngemäß: Was passiert, wenn diese eine Person das Unternehmen morgen verlässt? Wenn nur eine Person weiß, wie das Deployment funktioniert oder warum eine zentrale Komponente so gebaut ist, wie sie gebaut ist, ist das ein Risiko, das ein Investor einpreist, unabhängig davon, wie gut diese Person ist.
Technische Schulden, die künftiges Wachstum bremsen. Nicht jede Abkürzung ist ein Problem, jedes Startup nimmt welche. Die Frage ist, ob bekannt ist, wo sie liegen, und ob sie das geplante Team-Wachstum ausbremsen würden. Ein Investor will wissen, ob zehn neue Entwickler in sechs Monaten produktiv werden können, oder ob sie sich zuerst monatelang durch unverstandenen Code kämpfen müssen.
Warum das mehr ist als ein Pass-Fail-Gate
Der verbreitete Irrglaube ist, dass technische Due Diligence entweder grünes Licht gibt oder die Runde platzen lässt. In der Praxis passiert das selten. Viel häufiger fließen die Ergebnisse direkt in die Bewertung und die Konditionen ein. Ein System mit klaren, dokumentierten Risiken wird anders bewertet als eines, bei dem der Investor selbst raten muss, wie groß das Risiko ist. Unklarheit wird konservativ eingepreist, und zwar meistens zu deinen Ungunsten.
Das gilt auch für sehr frühe Runden. Ein Investor erwartet bei einer Pre-Seed-Runde kein fertiges Enterprise-System, aber er will sehen, dass die Gründer wissen, wo die Schwächen liegen und wie sie priorisiert würden. Das Fehlen dieses Wissens wiegt oft schwerer als die Schwächen selbst.
Wie du dich vorbereitest, ohne alles auf einmal zu reparieren
Der wirksamste Schritt ist eine ehrliche interne Bestandsaufnahme, bevor eine externe Prüfung stattfindet. Nicht, um alles zu verstecken, sondern um vorbereitet zu sein und keine Überraschung im Gespräch mit dem Investor zu erleben.
Dabei hilft eine einfache Unterscheidung: was ist jetzt günstig zu beheben, und was kann bewusst warten. Ein fehlender Test für eine selten genutzte Funktion ist selten dringend. Ein einziger Mensch, der als einziger die Produktionsumgebung versteht, ist es. Die Priorität liegt bei Risiken, die im Gespräch schwer zu erklären sind, nicht bei jedem theoretisch denkbaren Verbesserungspunkt.
Genauso wichtig wie das Beheben ist das Erklären-Können. Ein Investor erwartet kein perfektes System, aber er erwartet, dass du technische Entscheidungen begründen kannst, nicht nur, dass sie getroffen wurden. “Wir haben uns damals für diese Datenbank entschieden, weil X, und wissen, dass wir bei Y nachziehen müssen, wenn wir Z erreichen” ist eine überzeugende Antwort. “Das war schon so, als ich angefangen habe” ist es nicht, selbst wenn beide Systeme technisch identisch sind.
Der Blick von außen, bevor ihn ein Investor wirft
Die ehrlichste Vorbereitung ist ein Blick von außen, der genau das tut, was später die technische Due Diligence tut, nur früher und ohne dass eine Bewertung daran hängt. Unser Architektur-Review macht genau das: Wir sehen uns dein System an, sprechen mit deinem Team und schreiben auf, wo die größten Risiken liegen und in welcher Reihenfolge sie sich angehen lassen. Das Review ist kostenlos, unabhängig davon, ob danach eine Zusammenarbeit entsteht, und das Dokument gehört dir.
Die Frage, die sich lohnt, bevor du in die nächste Investorenrunde gehst: Wenn dich heute jemand fragt, was passiert, wenn deine wichtigste technische Ansprechperson morgen ausfällt, hast du eine Antwort, die über einen Namen hinausgeht?