Was prüft eine technische Due Diligence vor einer Investition oder einer Übernahme?

Technische Due Diligence ist für Investoren und Käufer, die wissen müssen, was sie kaufen, und für Gründer, die es sehen wollen, bevor ein Investor es tut. Sie ist kein Code-Style-Review. Die Frage ist enger: Gibt es etwas in der Technik, das den Preis, die Bedingungen oder den Plan ändern sollte? Das ist die Checkliste, so wie wir sie in einer Woche durchgehen.

Wie die Woche abläuft

Wir lesen, bevor wir eine Meinung haben: Lesezugriff auf das Repository und seine Historie, die Cloud- und CI-Konten, das Board und vorhandene Architekturdokumente, dazu Gespräche mit den Menschen, die das Produkt gebaut haben. Die meisten Befunde entstehen aus dem Vergleich dessen, was das Team sagt, mit dem, was das Repository zeigt.

Die Checkliste

Die Architektur und ihre Passung zur Roadmap

Wir halten fest, was wo läuft und wie die Teile miteinander sprechen, und legen das neben die Roadmap, die die Investition bezahlen soll. Die Frage ist, ob die nächste Phase des Plans auf dieser Architektur gebaut werden kann oder eine Neuentwicklung braucht, deren Kosten niemand berechnet hat.

Das Datenmodell und die Migrationen

Passt das Schema zu dem Geschäft, das es beschreibt? Sind die Migrationen im Repository versioniert und von einer leeren Datenbank aus reproduzierbar, oder werden sie in der Produktion von Hand angewendet? Gibt es Backups, und hat schon jemand eines wiederhergestellt? Wir notieren auch, wo personenbezogene Daten liegen, denn dort sitzt das regulatorische Risiko.

Sicherheit

Vier Bereiche. Authentifizierung und Autorisierung: wie sich Nutzer anmelden und ob der Zugriff auf dem Server durchgesetzt oder nur in der Oberfläche versteckt wird, einschließlich der Frage, ob ein Kunde die Daten eines anderen lesen kann. Secrets: ob Schlüssel und Passwörter im Code oder in seiner Historie stehen, wer sie hat und ob sie rotiert werden können. Abhängigkeiten: bekannte Schwachstellen und Pakete, die mehrere Hauptversionen zurückliegen. Angriffsfläche: was aus dem Internet erreichbar ist und es nicht sein sollte, etwa Admin-Bereiche, offene Storage-Buckets, Datenbanken und Debug-Endpunkte.

Tests und CI/CD

Gibt es Tests für die Teile, die Geld und Daten tragen? Laufen sie bei jeder Änderung? Kann das Team ausliefern und zurückrollen, ohne auf eine bestimmte Person angewiesen zu sein? Ein Produkt, das nur ein Engineer ausliefern kann, ist für sich schon ein Befund.

Infrastruktur, Kosten und Single Points of Failure

Was das Produkt jeden Monat im Betrieb kostet und wie diese Rechnung mit den Nutzern wächst. Dann die Single Points of Failure: ein Server, eine Region, ein persönliches Konto, dem die Cloud, die Domain oder der App-Store-Eintrag gehört.

Das Team und der Busfaktor

Die Commit-Historie zeigt, wer was geschrieben hat, und die Gespräche zeigen, wer es erklären kann. Wir sehen uns an, wie viel kritisches Wissen bei einer Person liegt, ob Angestellte oder Auftragnehmer die Arbeit gemacht haben und ob davon etwas aufgeschrieben ist. In einem jungen Unternehmen kann ein Busfaktor von eins akzeptabel sein; der Käufer sollte trotzdem wissen, wo er liegt.

Lizenzen und Abhängigkeiten von Dritten

Open-Source-Lizenzen, die mit dem Geschäftsmodell kollidieren, etwa Copyleft-Code in einem Produkt, das verkauft oder vertrieben wird, und Dienste von Dritten, ohne die das Produkt nicht laufen kann, mit ihren Bedingungen und ihren Preisen. Ob Auftragnehmer ihre Arbeit an das Unternehmen übertragen haben, ist eine rechtliche Frage, aber das Repository zeigt, nach wessen Arbeit zu fragen ist.

Die Frage von 2026: was KI geschrieben hat und wer es gelesen hat

Wie viel des Codes wurde von KI-Coding-Werkzeugen erzeugt, und hat ihn jemand gelesen, bevor er gemergt wurde? Wir behandeln von KI geschriebenen Code nicht an sich als Mangel; gelesen und geprüft kann er so solide sein wie jeder andere. Das Risiko ist Code, den niemand im Team gelesen hat oder erklären kann, denn niemand kann warten, absichern oder erweitern, was er nicht versteht.

Wir fragen und prüfen dann die Belege: die Historie der Pull Requests und ob Änderungen geprüft wurden und von wem, die im Repository eingecheckte Konfiguration der Werkzeuge und die Muster, die ungelesener generierter Code oft hinterlässt, etwa dieselbe Logik auf mehrere Arten geschrieben, Tests, die nichts prüfen, und Sicherheitsregeln, die vorhanden, aber ausgeschaltet sind. Wir verlassen uns nicht auf Detektoren, die angeblich erkennen, welche Zeilen ein Modell geschrieben hat. Die Review-Historie zeigt, wer den Code gelesen hat.

Was der Bericht enthält

Ein schriftlicher Bericht in klarer Sprache, nach dem auch jemand ohne technischen Hintergrund handeln kann.

• Eine Zusammenfassung für die Entscheider: was wir gefunden haben und ob etwas den Deal ändern sollte.
• Befunde nach Risiko geordnet: jeweils mit dem Beleg (die Datei, der Commit, die Einstellung), warum er wichtig ist und was die Behebung umfasst.
• Was vor dem Closing zu beheben ist: die Befunde, die ernst genug sind, um Bedingungen zu sein, etwa frei zugängliche Secrets, keine funktionierenden Backups oder Kundendaten, die für andere Kunden erreichbar sind.
• Was einzupreisen ist: echte Kosten nach dem Closing, die kein Grund zum Abbruch sind, etwa ein Modul, das für die Roadmap neu gebaut werden muss, eine Einstellung, um einen Busfaktor von eins abzudecken, oder Infrastrukturkosten, die schneller wachsen als der Umsatz.
• Was solide ist: Ein Bericht, der nur Probleme auflistet, führt in die andere Richtung in die Irre.

Für wen der Bericht gedacht ist

Der Investor oder der Käufer gibt ihn in Auftrag und erhält ihn. Wo der Deal es erlaubt, schlagen wir vor, die Befunde mit den Gründern zu teilen, die sie beheben werden; ein früh besprochener Befund ist leichter zu klären als einer, der beim letzten Gespräch vor dem Closing auftaucht.

Gründer, die eine Finanzierungsrunde vorbereiten, können dieselbe Prüfung für sich selbst in Auftrag geben. Es ist günstiger, einen frei zugänglichen Schlüssel oder ein fehlendes Backup zu finden, bevor ein Investor es tut.

Was sie nicht abdeckt

Technische Due Diligence steht neben der rechtlichen und der finanziellen Due Diligence, nicht an ihrer Stelle. Sie ist kein Penetrationstest und keine formale Compliance-Prüfung; wo eines davon nötig ist, sagt der Bericht, welches und warum. Und sie bewertet keinen Geschmack: Code, den wir anders geschrieben hätten, ist kein Befund, solange er den Käufer nichts kostet.