Technische Due Diligence bei Software: Was Investoren wirklich prüfen

Wer nach „technische Due Diligence” sucht, landet zuerst bei Gebäuden. In der Immobilienwirtschaft prüft eine technische Due Diligence die Bausubstanz, den Instandhaltungsstau und den künftigen Investitionsbedarf. Bei Software dagegen geht es um Code, Architektur, Infrastruktur und Team eines Unternehmens vor einer Finanzierungsrunde. Dieser Artikel beschreibt, was ein Prüfer dabei tatsächlich liest — und was Sie als Gründer davon Monate vorher herstellen können.

Was eine technische Due Diligence ist — und was nicht

Eine technische Due Diligence bewertet die technische Substanz eines Software-Unternehmens vor einer Investition oder Übernahme. Englisch heißt dieselbe Prüfung Technical Due Diligence, im M&A-Umfeld auch IT Due Diligence. Sie betrachtet vier Gegenstände: den Quellcode, die Architektur, den Betrieb und das Team dahinter.

Die Abgrenzung zur Immobilie lohnt sich, weil beide Disziplinen denselben Namen tragen. Dort zielt die Prüfung auf Bausubstanz, technischen Instandhaltungsstau und die Capex-Planung eines Bauwerks. Hier geht es ausschließlich um immaterielle Werte — und um die Frage, ob sich das Produkt in den nächsten drei Jahren weiterentwickeln lässt.

Ebenso wichtig ist die zweite Abgrenzung. Eine technische Due Diligence ist weder ein Code-Review noch ein Security-Audit. Ein Code-Review verbessert einen konkreten Änderungsvorschlag, ein Security-Audit sucht Schwachstellen. Die Due Diligence dagegen liefert eine Risikobewertung mit Preisschild: Was kostet es, dieses System weiterzubetreiben und zu skalieren?

Wann sie stattfindet

In der Seed-Phase läuft die Prüfung oft informell — als Produkt-Demo plus Architekturgespräch. Ab der Series A wird sie regelmäßig formal. Zeitlich liegt sie im deutschen Markt fast immer zwischen Term Sheet und Closing, denn das Term Sheet macht ihr Ergebnis üblicherweise zur aufschiebenden Bedingung. Eine vollständige Prüfung vor dem LOI bleibt die Ausnahme; dort genügen Investoren meist ein Fragebogen und ein Gespräch auf Architekturebene.

Technische Due Diligence: Wer prüft, wann und wie lange?

Wer die Prüfung durchführt, hängt von der Phase ab. In der Seed-Runde übernehmen sie meist fonds-interne Tech-Partner oder ein CTO aus einem Portfolio-Unternehmen. Ab der Series A beauftragen institutionelle Investoren dagegen externe Gutachter und spezialisierte Audit-Boutiquen.

Der Ablauf folgt fast immer vier Schritten:

1. Zugang: Datenraum, Repository-Zugriff, Architekturdokumentation.
2. Interviews: Gespräche mit den Entwicklern — nicht nur mit dem CTO. Wer den Code geschrieben hat, beantwortet andere Fragen als wer ihn präsentiert.
3. Analyse: automatisierte Auswertung der Historie, Stichproben im Code, Prüfung von Abhängigkeiten und Lizenzen.
4. Report: Befunde mit Ampel-Bewertung, jeweils mit geschätztem Behebungsaufwand in Personenmonaten.

Zu Dauer und Kosten gibt es in Deutschland keine veröffentlichte Statistik. Die Erfahrungswerte aus Gutachter-Berichten und Praxishandbüchern, die der Recherche zu diesem Artikel zugrunde liegen, nennen für die Seed-Phase ein bis zwei Wochen und einen vierstelligen Betrag, der häufig intern verrechnet wird. Für eine Series A liegen die Angaben bei drei bis sechs Wochen und einem niedrigen bis mittleren fünfstelligen Honorar. Behandeln Sie diese Zahlen deshalb als Größenordnung, nicht als Marktpreis.

Was der Prüfer im Repository liest: die Commit-Historie

Präsentationen lassen sich vorbereiten. Die Commit-Historie nicht. Sie ist die einzige Quelle im Datenraum, die niemand für die Prüfung aufhübschen kann — jeder Versuch hinterlässt selbst wieder Spuren. Deshalb beginnt eine ernsthafte technische Due Diligence heute in der Versionsverwaltung und nicht im Quellcode.

Vier Signale liest ein Prüfer zuerst:

• Autoren-Verteilung pro Modul. Wer hat welchen Teil geschrieben, und wie viele Menschen haben ihn seither angefasst? Die Forschung zur Code-Ownership nutzt genau diese Daten, um die Wissensträger eines Moduls zu bestimmen. Ein Modul mit einem einzigen dominanten Autor ist ein Team-Risiko, ein Modul mit zwanzig Gelegenheitsbeiträgen und ohne Verantwortlichen ein Qualitätsrisiko.
• Kadenz und Rhythmus. Fließt die Arbeit kontinuierlich, oder erscheinen drei Commits mit 4.000 geänderten Zeilen in der Nacht vor dem Demo-Day? Das zweite Muster sagt mehr über den Entwicklungsprozess aus als jedes Architekturdiagramm.
• Hotspots. Ein Hotspot ist eine Datei, die häufig geändert wird und strukturell komplex ist. Änderungsfrequenz mal Komplexität — dieses Produkt zeigt zuverlässig, wo die eigentlichen Architekturprobleme sitzen.
• Secrets in der Historie. Ein einmal committetes Passwort bleibt im Repository, auch nachdem jemand die Datei gelöscht hat. Prüfer suchen gezielt danach, und sie finden es oft.

Umgeschriebene Historie fällt ebenfalls auf. Ein Repository, das mit einem einzigen Initial-Commit über 200.000 Zeilen beginnt, beantwortet keine einzige dieser Fragen — und genau das notiert der Prüfer.

Was eine gute Historie zeigt

Eine überzeugende Historie besteht aus kleinen, benannten Commits, die jeweils eine Sache tun. Reviews sind sichtbar, weil Änderungen über Merge Requests laufen. Tests liegen im selben Commit wie das Feature, nicht in einem nachgereichten Sammel-Commit „add tests”. Solche Muster entstehen allerdings nicht in den letzten Wochen vor einer Runde. Sie sind das Nebenprodukt einer Arbeitsweise — und deshalb ein so belastbares Signal.

Tests, CI und Liefergeschwindigkeit

Kaum eine Kennzahl wird so gern genannt und so selten eingeordnet wie die Test-Coverage. Eine große Industriestudie an SAP HANA mit über 16.000 Fehlerberichten zeigt zwar, dass abgedeckter Code weniger Fehler enthält als nicht abgedeckter. Der Zusammenhang ist jedoch nicht linear.

Deshalb beweist die Zahl allein nichts. Tests ohne Assertions erhöhen die Coverage genauso wie Tests, die nur Getter durchlaufen. Als Faustregel setzen Prüfer die Schwelle bei 70 bis 80 Prozent an; darüber sinkt der Nutzen zusätzlicher Tests spürbar. Eine erzwungene 100-Prozent-Quote gilt vielen Gutachtern sogar als Warnzeichen für ineffiziente Prozesse.

Erfahrene Gutachter fragen daher anders:

1. Laufen die Tests bei jeder Änderung, oder nur wenn jemand daran denkt?
2. Wie lange dauert es vom Commit bis in die Produktion?
3. Deployen Sie mehrmals täglich oder einmal im Quartal, und wie oft rollt etwas zurück?
4. Wie schnell ist ein fehlgeschlagenes Release wieder repariert?

Diese vier Fragen sind die DORA-Kennzahlen: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Recovery Time. Seit 2025 tritt als fünfte Größe die Rework Rate hinzu — der Anteil an Änderungen, die nur Nachbesserungen vorangegangener Releases sind. Zusammen messen sie das, was eine Coverage-Zahl nie zeigt: ob das Team im Monat 18 noch genauso liefert wie im Monat 3.

Architektur und Skalierbarkeit: Trägt das die nächste Stufe?

Die Leitfrage des Prüfers ist die 10x-Frage. Was passiert bei zehnfacher Last, zehnfacher Datenmenge und zehnfachem Team? Alle drei Achsen brechen an unterschiedlichen Stellen, und selten dort, wo Gründer es erwarten.

Zwei Stellen entscheiden fast immer. Die erste ist das Datenmodell: Wer Mandantenfähigkeit, Historisierung oder Mehrsprachigkeit nachträglich einzieht, zahlt ein Vielfaches. Die zweite ist der API-Schnitt zwischen den Komponenten. Ist er falsch gelegt, wächst jede Änderung über mehrere Teams — und genau daraus entsteht der Rewrite, den niemand geplant hat.

Ein Prüfer achtet außerdem darauf, ob Architekturentscheidungen dokumentiert sind. Kurze Architecture Decision Records genügen; sie zeigen, dass jemand Alternativen abgewogen hat. Verfrühte Microservices bewertet er dabei genauso kritisch wie den ungepflegten Monolithen: Fünf Services mit einer gemeinsamen Datenbank sind ein verteilter Monolith mit zusätzlichem Betriebsaufwand.

Bus-Faktor: Wenn alles an einer Person hängt

Der Bus-Faktor beziffert, wie viele Menschen ausfallen müssen, damit ein Projekt stehen bleibt. Gemessen wird er aus derselben Commit-Historie, ergänzt um die Interviews. Die einschlägige Forschung berechnet dafür einen Autorschaftsgrad pro Datei und kommt zu einem unbequemen Ergebnis: Ein Großteil der untersuchten Open-Source-Systeme hat einen Bus-Faktor von eins oder zwei.

Bei Startups ist die Lage selten besser. Häufig hält ein technischer Gründer die Kernlogik, und zwei Freelancer betreiben die Infrastruktur — inklusive der einzigen Zugänge zu Cloud-Konten und Deploy-Pipeline. Investoren behandeln das als Key-Person-Risiko und fragen konkret nach: Wie lange bräuchte ein neuer Entwickler bis zum ersten produktiven Deployment? Wer kann außer dieser Person die Datenbank wiederherstellen?

Ein Bus-Faktor von eins in einem unkritischen Modul ist ein Hinweis. In der Abrechnungslogik ist er ein Befund mit Preisschild. Dass Teamrisiken früher wirken als Technikrisiken, zeigt sich übrigens auch abseits von Finanzierungsrunden — die Gründe, warum Startups scheitern, liegen selten im Code.

Abhängigkeiten, Lizenzen und Quellcode-Eigentum

Drei Prüfungen lässt kein Investor aus. Sie sind vergleichsweise schnell erledigt und erzeugen trotzdem die härtesten Befunde.

Erstens die Abhängigkeiten. Wie alt sind die eingesetzten Bibliotheken, und welche bekannten Schwachstellen tragen sie? Als Nachweis erwarten Prüfer inzwischen eine Software Bill of Materials in einem Standardformat wie SPDX oder CycloneDX, erzeugt aus der eigenen Pipeline.

Zweitens die Lizenzen. Copyleft-Lizenzen im eigenen Abhängigkeitsbaum sind ein reales Risiko für ein SaaS-Produkt. Die AGPL schließt gezielt die Lücke der reinen Netzwerknutzung: Wer eine AGPL-Komponente in seinem Backend betreibt und Nutzer über das Netz darauf zugreifen lässt, muss den Quellcode seiner Anwendung offenlegen. Eine solche Komponente im proprietären Kern stoppt Deals.

Drittens die Rechtekette. Bei Angestellten regelt § 69b UrhG die vermögensrechtlichen Befugnisse zugunsten des Arbeitgebers, sofern der Arbeitsvertrag die Entwicklung als Aufgabe benennt. Für Freelancer, Agenturen und Mitgründer vor der GmbH-Gründung gilt das jedoch nicht. Dort greift die Zweckübertragungslehre: Ohne ausdrückliche Vereinbarung räumt der Urheber nur die nötigsten Nutzungsrechte ein. Fehlt ein einziger Vertrag, gehört ein Teil des Produkts jemand anderem — ein Muster, das in Investoren-Prüfungen regelmäßig auffliegt.

Der Prüfer will hier Dokumente sehen, keine Zusicherungen: Arbeitsverträge, unterschriebene Rechteübertragungen aller Externen, den Lizenz-Scan-Report. Welche Vertragsmodelle dahinterstehen und wie Sie sie von Anfang an richtig aufsetzen, steht in unserem Artikel dazu, wem der Quellcode gehört.

KI-generierter Code in der technischen Due Diligence

Seit 2025 stellt praktisch jeder Prüfer eine neue Frage: Welcher Anteil des Codes stammt von KI-Agenten, und wer hat ihn verstanden? Die Sorge gilt dabei nicht exotischen Bugs, sondern der Struktur. Auswertungen von GitClear über hunderte Millionen geänderter Codezeilen zeigen einen deutlichen Anstieg von Duplikaten und kurzlebigem Code: KI-Assistenten fügen lieber einen neuen Block ein, als eine bestehende Funktion wiederzuverwenden.

Im Audit äußert sich das als Duplikation, inkonsistente Muster über vergleichbare Module hinweg, schwer testbare Bausteine und hartcodierte Zugangsdaten. Der Prüfer fragt dabei nicht, ob KI im Spiel war. Er fragt, ob jemand im Team jede Zeile verantworten kann. Wie diese unsichtbare Last entsteht und mit welchen Leitplanken Sie sie vermeiden, haben wir unter Shadow Tech Debt beschrieben.

Für KI-Produkte kommen zwei weitere Prüffelder hinzu. Prüfer fragen nach der Herkunft der Trainingsdaten und nach der Einordnung unter dem EU AI Act, dessen Transparenzpflichten gestaffelt greifen. Eine dokumentierte Risikoklassifizierung ist hier billiger als jede nachträgliche Erklärung.

Welche Red Flags der technischen Due Diligence kosten den Deal?

Nicht jeder Befund wiegt gleich schwer. Auswertungen von Prüfungsanbietern — belastbare unabhängige Zahlen fehlen — nennen für einen erheblichen Teil aller Prüfprozesse Anpassungen an Bewertung, Konditionen oder Struktur. Gutachter sortieren ihre Funde deshalb nach Konsequenz:

Stufe	Typischer Befund	Was der Prüfer daraus schließt
Deal-Breaker	Lücke in der IP-Kette ohne Heilung, AGPL im proprietären Kern, Secrets im Repository, keine funktionierenden Backups	Das Unternehmen besitzt sein Produkt nicht vollständig oder kann es verlieren
Bewertung und Konditionen	Bus-Faktor 1 in einem Kernmodul, keine automatisierten Tests, ungepatchte Schwachstellen, absehbarer Rewrite	Der Käufer zahlt die Sanierung — also senkt er den Preis
Auflage mit Frist	fehlende Dokumentation, kein Monitoring, unvollständiges Verarbeitungsverzeichnis, ausstehender Penetrationstest	Behebbar, aber vertraglich abzusichern

Die Stufen sind durchlässig. Ein einzelnes hartcodiertes Passwort ist eine Auflage; dasselbe Passwort in einem öffentlichen Repository, seit acht Monaten gültig und nie rotiert, ist ein Deal-Breaker. Entscheidend ist selten der Fund selbst, sondern was er über den Prozess dahinter verrät. Genau das beschreiben auch Gutachter, die wiederkehrende Red Flags aus Seed- und Series-A-Prüfungen zusammentragen.

Auf die technische Due Diligence vorbereiten: DD-ready in sechs Bündeln

Beginnen Sie drei bis sechs Monate vor der Runde. Die reine Zusammenstellung der Unterlagen dauert erfahrungsgemäß mehrere Wochen, und die inhaltlichen Lücken, die dabei auffallen, brauchen länger.

In den technischen Datenraum gehören sechs Bündel:

1. Architektur: ein aktuelles Diagramm der Systemgrenzen plus kurze Entscheidungsprotokolle.
2. Abhängigkeiten: Inventar mit Lizenz-Scan, erzeugt aus der Pipeline statt von Hand gepflegt.
3. Rechte: Arbeitsverträge und alle Übertragungserklärungen von Externen, vollständig und unterschrieben.
4. Tests und CI: Coverage-Berichte, Pipeline-Konfiguration, Kennzahlen der letzten zwölf Monate.
5. Betrieb: Incident-Log, Post-Mortems, nachgewiesene Restore-Tests.
6. Zugriffe: Rollen- und Rechtekonzept, Secrets-Management, Notfallzugänge.

Am meisten bringt jedoch eine Mock-DD: Lassen Sie jemanden prüfen, der nicht am Code beteiligt war. Ein unabhängiges Architektur-Audit findet in wenigen Tagen dieselben Muster wie ein Gutachter — nur ohne Term Sheet im Hintergrund. Als Rückgrat der Vorbereitung dient das Protokoll, das wir auf unserer Seite für Tech-Partner für Startups beschreiben: Tests bei jeder Änderung, eine Architektur für die nächste Stufe, Secrets außerhalb von Code und Historie, geklärte Lizenzen, Code im Eigentum des Unternehmens und Liefergeschwindigkeit auch im Monat 18.

Der wichtigste Satz zum Schluss dieses Abschnitts: Kein Prüfer erwartet ein perfektes System. Er erwartet, dass Sie Ihre Schwächen kennen, benennen und einen datierten Plan dafür haben. Ein bekannter Befund mit Lösungsweg kostet Verhandlungsspielraum. Ein unbekannter kostet Vertrauen.

Fazit

Eine technische Due Diligence prüft nicht, ob Code schön ist. Sie prüft, ob ein Unternehmen sein Produkt weiterentwickeln kann — ohne Rewrite, ohne Rechtsstreit und ohne eine einzige unersetzliche Person. Alles, was dabei zählt, entsteht in den Monaten davor: in der Commit-Historie, in der Pipeline, in unterschriebenen Verträgen.

Wenn Sie Ihr Produkt von einem Team bauen lassen wollen, das diese Prüfung von Anfang an mitdenkt, sprechen Sie mit uns über individuelle Softwareentwicklung. Wir liefern den Code, der später geprüft wird — und die Nachweise gleich mit.

---

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Für rechtliche Fragen zu Ihrem konkreten Fall wenden Sie sich bitte an einen Rechtsanwalt. Trotz sorgfältiger Recherche übernehmen wir keine Haftung für die Richtigkeit, Vollständigkeit oder Aktualität der Inhalte.