EINBLICKE

Technische Due Diligence: was über den Code hinaus zählt

Technische Due Diligence muss beantworten, ob die Technologie den Plan trägt. Sieben Bereiche, die entlarvenden Fragen und Warnsignale, die kein Scan findet.

Von Jovan Soldatovic Veröffentlicht am 3. September 2026 9 Min. Lesezeit

TYP: ARTIKEL
THEMA: KAPITAL UND EIGENTUM / PRODUKTE UND PLATTFORMEN / DELIVERY UND TEAMS
GEPRÜFT: 2026-09-03

Hand blättert eine technische Zeichnung über einem Stapel gedruckter Tabellen und Prüfunterlagen um — Technische Prüfunterlagen werden geöffnet

ARTIKEL

Ich habe Unternehmen auf technische Due Diligence vorbereitet, und ich habe sie für Investoren und für ein großes Finanzinstitut durchgeführt, das eine Plattform bewertete, auf die es sich verlassen wollte. Beide Erfahrungen haben mich dasselbe gelehrt: Der Code ist der am wenigsten aussagekräftige Teil der Übung. Ein Team kann sauberen Code haben und einen Businessplan, den die Architektur nicht tragen kann. Ein Team kann hässlichen Code haben und ein System, das still und leise das Zehnfache der Last bewältigt hat, die der Plan verlangt. Der Sinn einer Due Diligence ist, die beiden auseinanderzuhalten.

Was das Investmentkomitee wirklich wissen muss

Ohne die Checkliste bleiben vier Fragen:

Kann die Technologie den Plan tragen? Wenn der Plan zehnmal so viele Kunden, fünf neue Märkte und ein reguliertes Enterprise-Segment vorsieht: Kommen Architektur, Infrastruktur und Team dorthin – und zu welchen Kosten?
Was wird kaputtgehen, und wann? Jedes System hat einen Engpass, den die nächste Größenordnung finden wird. Welchen, wie bald, und was kostet die Behebung?
Was kostet die Technologie wirklich? Infrastruktur, Lizenzen, die Entwicklungszeit, die in den laufenden Betrieb statt ins Bauen fließt, und die technischen Schulden, die vor der nächsten Phase zurückgezahlt werden müssen.
Wie sehr hängt das an wenigen Personen? Wer versteht das System, wer könnte gehen, und was passiert dann?

Alles andere in der Prüfung dient dazu, diese Fragen zu beantworten.

Die sieben Bereiche

Architektur und ihre Passung zum Plan. Nicht „Ist sie modern?“ – ist sie richtig für das, was das Geschäft brauchen wird? Ein Monolith, den ein kleines Team täglich ausliefert, kann die richtige Antwort sein; eine Microservice-Landschaft, die niemand betreiben kann, ist die falsche, so modisch sie auch sein mag. Ich suche nach den Grenzen, die sich mit dem Wachstum des Geschäfts verschieben müssen, und frage, ob sie das können.

Skalierbarkeit, mit Zahlen. Wie hoch sind die aktuellen Volumina? Was hat das System in der Spitze tatsächlich bewältigt? Wo ist der nächste Engpass, und hat ihn jemand gemessen? Behauptungen ohne Lastdaten sind Hoffnungen.

Sicherheits- und Compliance-Niveau. Authentifizierung, Zugriffskontrolle, Secrets-Management, Pflege der Abhängigkeiten, Datenschutzpraxis, Vorfallhistorie und ob jemals jemand außerhalb des Teams es getestet hat. Für regulierte Segmente: ob die Kontrollen, nach denen die Compliance-Abteilung eines Kunden fragen wird, existieren – oder nur auf Folien existieren.

Daten. Wo sie liegen, wem sie gehören, wie sie gesichert und wiederhergestellt werden (wurde eine Wiederherstellung jemals getestet?), wie mit personenbezogenen Daten umgegangen wird und – zunehmend – ob die Daten, die das Unternehmen als Vermögenswert ausweist, für die Modelle, die es bauen will, tatsächlich nutzbar sind.

Lieferfähigkeit. Wie oft liefert das Team aus? Wie lange braucht eine Änderung von der Idee bis in die Produktion? Gibt es automatisierte Tests, und vertraut ihnen jemand? Kann ein neuer Entwickler in einer Woche produktiv werden, oder lebt das Wissen in zwei Köpfen? Dieser Bereich sagt die nächsten zwei Jahre besser voraus als jede Code-Metrik.

Betrieb und Kosten. Monitoring, Rufbereitschaft, Umgang mit Vorfällen, Infrastrukturkosten pro Kunde und die Entwicklung dieser Kosten. Ein Produkt, dessen Infrastrukturkosten schneller wachsen als sein Umsatz, ist ein Problem, das die GuV irgendwann findet.

Menschen und Abhängigkeiten. Wer sind die Schlüsselentwickler, was verantworten sie, bleiben sie, und was ist der Plan, falls nicht? Wo sind die Externen, und wem gehört, was sie gebaut haben? Ist das geistige Eigentum tatsächlich übertragen?

Fragen, die mehr offenlegen als ein Scan

„Zeigen Sie mir die letzten drei Vorfälle und was Sie danach geändert haben.“
„Welche Änderung schieben Sie schon länger vor sich her, und warum?“
„Wenn Ihr bester Entwickler am Freitag ginge – was würde am Montag nicht mehr ausgeliefert?“
„Führen Sie mich durch ein Deployment. Und jetzt durch einen Rollback.“
„Was stand im letzten Sicherheitsfragebogen eines Kunden, das Sie nicht beantworten konnten?“
„Welchen Teil des Systems soll ich mir lieber nicht ansehen?“ – mit einem Lächeln gefragt, und immer aufschlussreich.

Warnsignale, die ein Code-Scan nie finden wird

Das Architekturdiagramm wurde für die Due Diligence gezeichnet.
Niemand kann aktuelle Volumina oder Spitzenlast aus dem Kopf nennen.
Die Testabdeckung ist hoch, und niemand führt die Tests aus.
Das Datenmodell hat eine Tabelle namens misc mit vierzig Spalten.
„Sicherheit bauen wir ein, wenn wir Enterprise-Kunden haben.“
Der Gründer ist die einzige Person, die jemals in Produktion deployt hat.
Die KI-Funktion im Pitch-Deck ist ein Prompt ohne Evaluation, ohne Monitoring und ohne Kostenmodell.

Für Unternehmen, die sich auf eine Prüfung vorbereiten

Alles oben ist auch eine Vorbereitungsliste. Wenn Sie auf eine Finanzierungsrunde zusteuern, tragen Sie die Belege zusammen, bevor der Prüfer fragt: die Architektur, wie sie ist, Last- und Performance-Daten, ein Dokument zum Sicherheitsniveau, eine Datenlandkarte, Delivery-Kennzahlen, Kosten pro Kunde, das Bild der Schlüsselpersonen und ein ehrliches Register der technischen Schulden mit Plan. Ein vorbereitetes Unternehmen beantwortet an einem Tag, was ein unvorbereitetes wochenlang zusammensuchen muss, und der Unterschied ist für den Investor sichtbar. Über die Vorbereitung auf eine Runde habe ich gesondert geschrieben.

Wie ein guter Bericht aussieht

Geschrieben für das Investmentkomitee, nicht für das Entwicklungsteam. Befunde geordnet nach ihrer Wirkung auf den Plan. Jedes wesentliche Risiko mit Kosten und Zeitrahmen für die Behebung. Eine klare Aussage dazu, was die Technologie tragen kann und was nicht. Und – hier scheitern die meisten Berichte – eine Meinung. Das Komitee bezahlt für ein Urteil, nicht für ein Inventar.

ÜBER DEN AUTOR

JOVAN SOLDATOVIC – Gründer & Managing Partner, Technologie, Architektur & Ventures. Jovan hat technische Due Diligence für Venture-Finanzierungen vorbereitet, die technische Due Diligence einer Datenplattform für ein großes Bankinstitut geleitet und als CTO die Technologie von SaaS- und Consumer-Plattformen verantwortet. Jovan Soldatovic

VERWANDTE EINBLICKE

Ein Technologieunternehmen auf eine Finanzierungsrunde vorbereiten Ein Technologieunternehmen auf eine Finanzierungsrunde vorbereiten
Softwareentwicklung einkaufen, ohne sich die Finger zu verbrennen Softwareentwicklung einkaufen, ohne sich die Finger zu verbrennen

PROJEKT STARTEN

Sie brauchen eine technische Prüfung, geschrieben für ein Investmentkomitee?

Wir führen technische Due Diligence für Investoren durch und bereiten Unternehmen darauf vor. Sagen Sie uns, auf welcher Seite Sie stehen.

Projekt starten