Technical Due Diligence für Software, IT & KI

Technische Due Diligence für Software und Technologieunternehmen

Eine technische Due Diligence untersucht den dokumentierten technischen Zustand eines Software- oder Technologieprodukts zu einem definierten Prüfzeitpunkt. Je nach Auftrag werden Codebasis, Architektur, Repositories, Versions- und Releasehistorien, Entwicklungs- und Betriebsnachweise, Abhängigkeiten, Test- und Deploymentfähigkeit, technische Risiken sowie Daten- und KI-Komponenten untersucht. Die Prüfung beschreibt technische Tatsachen, Reife, Risiken und Aussagegrenzen; sie bestimmt weder Unternehmenswert noch Investitionserfolg.

Typische Anlässe und Ergebnis der Prüfung

Investment, Unternehmenskauf, Beteiligung oder technische Vendor-/Buy-Side-Prüfung
technische Second Opinion zu Architektur, Codebasis, Security oder Delivery-Fähigkeit
Due-Diligence-Readiness vor Finanzierungsrunde oder Transaktion

Das Ergebnis ist eine technische Entscheidungsgrundlage mit dokumentierten Befunden, Risiken, Abhängigkeiten, Nachweislücken und Aussagegrenzen. Unternehmenswert, Kaufpreis, rechtliche Eigentumsverhältnisse und die Investitionsentscheidung selbst bleiben außerhalb der technischen Prüfung.

Schwerpunkte der Analyse

Softwarearchitektur, Codebasis, Modulgrenzen, Schnittstellen und technische Reife
Repository-, Commit-, Branch-, Tag-, Build- und Releasehistorien
Build-, Test-, CI/CD- und Deploymentfähigkeit sowie Reproduzierbarkeit technischer Stände
Wartbarkeit, technische Schulden, Abhängigkeiten und Schlüsselkomponenten
Skalierungsannahmen, Performance-Risiken und technische Engpässe
Entwicklungsprozess, technische Dokumentation, Wissenskonzentration und Übergabefähigkeit
IT-Sicherheit und technische Schutzmaßnahmen im vereinbarten Prüfungsumfang
Technische Erfassung von Abhängigkeiten, Lizenzhinweisen und Provenienzinformationen; eine rechtliche Bewertung von Lizenz- oder IP-Rechten ist davon getrennt
Daten- und KI-Komponenten einschließlich Datenqualität, Modellartefakten, Robustheit und technischer Nachvollziehbarkeit, soweit auftragsrelevant

Methodischer Ansatz

Die technische Due Diligence trennt zunächst Fragestellung, Untersuchungsgegenstand, Daten- und Systemstände, Referenzkriterien, technische Befunde und fachliche Bewertung. Sie kombiniert Software-, Architektur-, Daten-, Sicherheits- und Provenienzaspekte nur soweit sie für den vereinbarten Prüfauftrag relevant und technisch belegbar sind.

Methodische Anregung: Der strukturierende Problemlösungszyklus und ausgewählte Kontrollfragen orientieren sich an Nicolai Andler, Tools für Projektmanagement, Workshops und Consulting – Kompendium der wichtigsten Techniken und Methoden, 6., überarbeitete und erweiterte Auflage, Publicis, Erlangen, 2015, ISBN 978-3-89578-453-8. Diagnose, Zielformulierung, Analyse und Entscheidungsfindung werden für die technische Prüfung adaptiert. Die Fragen werden nicht als eigene Erfindung dargestellt und nicht als vollständiger Fragenkatalog reproduziert.

Diagnose: Prüfgegenstand, Systemstände, verfügbare Evidenz, Risiken und offene Widersprüche bestimmen.
Zielformulierung: technische Prüffragen, Kriterien, Ausschlüsse und Definition of Done festlegen.
Analyse: Architektur, Code, Daten, Abhängigkeiten, Entwicklungs- und Betriebsnachweise sowie plausible Alternativerklärungen untersuchen.
Sachverständige Synthese: Befunde, Gegenhypothesen, Unsicherheiten und technische Risiken nachvollziehbar zusammenführen.

1 Scope Produkt, Codebasis, Systemstände, Datenraum, Zeitraum und technische Prüffragen abgrenzen.

2 Evidenz Repositories, Builds, Tests, Architektur, Security-, Betriebs- und Abhängigkeitsnachweise sichern und zuordnen.

3 Gegenprüfung Technische Stärken, Schulden, Schlüsselabhängigkeiten, Skalierungsannahmen und Alternativerklärungen prüfen.

4 Synthese Risiken, Unsicherheiten, offene Nachweise und technische Handlungsoptionen nach Tragweite und Evidenz einordnen.

Technische Reife ist kein Unternehmenswert: Die Prüfung beschreibt den untersuchten technischen Zustand und seine Risiken, nicht die wirtschaftliche Attraktivität einer Transaktion.

Die allgemeine Entscheidungsfindung des Problemlösungszyklus wird dabei nicht mit der Investitionsentscheidung gleichgesetzt. Das Gutachten liefert eine technische Entscheidungsgrundlage; Investitions-, Vertrags- und Rechtsentscheidungen verbleiben bei den jeweils zuständigen Personen und Beratern. Quellen und Methodik dokumentiert diese Abgrenzung.

Eine technische Due Diligence macht den untersuchten technischen Zustand, nachvollziehbare Risiken, Potenziale und Aussagegrenzen sichtbar. Sie ist eine technische Entscheidungsgrundlage und keine Garantie für den wirtschaftlichen Erfolg oder eine rechtliche Freigabe.

Typische Anwendungsfälle

Technische Prüfung vor Finanzierungsrunden, Beteiligungen oder Technologiepartnerschaften
Software Due Diligence im Rahmen vorbereitender M&A- oder Beteiligungsprozesse
Technische Bestandsaufnahme vor Übernahme eines Produkts, Teams oder Entwicklungsprojekts
Bewertung von Produkt-, Plattform- und KI-Reife aus technischer Sicht
Prüfung von Übergabefähigkeit, Wissenskonzentration und technischen Schlüsselabhängigkeiten
Technische Zweitmeinung zu bereits vorhandenen Prüfberichten oder Risikolisten
Rekonstruktion des tatsächlichen Entwicklungs-, Build- und Releasezustands vor einer Entscheidung

Technische Aussagegrenze

Ziel ist eine methodisch nachvollziehbare, evidenzbasierte technische Entscheidungsgrundlage. Das Gutachten ordnet belegbare technische Stärken, Schwächen, Risiken, Abhängigkeiten, Unsicherheiten und offene Punkte ein. Es ersetzt weder eine Unternehmensbewertung noch eine rechtliche, steuerliche oder finanzielle Due Diligence und spricht keine Investitions- oder Transaktionsempfehlung aus.

Fallstudie: Methodischer Ablauf einer Technischen Due Diligence & Startup-Bewertung

Strukturierte technische Bewertung von Software, Systemarchitektur und Entwicklungsreife in Anlehnung an Nicolai Andlers Problemlösungsphasen

Konstruiertes Prüfszenario: Diese Darstellung beschreibt kein reales Mandat und keine tatsächliche gerichtliche Beauftragung; sie enthält keine realen Ergebnisse.

1. Diagnose – Technologische Ausgangslage und Zielsystemanalyse

Die Fallstudie beginnt mit der Bestandsaufnahme des technologischen Status quo: Es werden Softwarearchitektur, Codebasis, Entwicklungsprozesse und technische Infrastruktur untersucht. Ziel ist, ein klares Bild der technologischen Reife, Skalierbarkeit und Wartbarkeit zu erhalten. Besonderes Augenmerk gilt den Entwicklungspraktiken, Dokumentationen, Abhängigkeiten und der organisatorischen Einbettung des Technikteams. Diese Phase schafft Transparenz über die tatsächliche Leistungsfähigkeit und technische Substanz des Startups.

2. Zielformulierung – Bewertungsrahmen und Prüfkriterien definieren

Im zweiten Schritt werden die Bewertungsziele und -kriterien festgelegt – abgestimmt auf den Investitionskontext. Typische Prüffelder sind:

Softwarequalität, Architekturdesign und technische Skalierbarkeit,
Teamorganisation, Entwicklungsprozesse und Dokumentationsstand,
Cybersecurity, IT-Governance und Compliance,
Lizenzmodelle, technische Abhängigkeiten und die hierzu vorhandene Dokumentationslage,
Reifegrad von KI- oder Data-Science-Komponenten (Nachvollziehbarkeit, Fairness, Bias).

Diese Phase definiert, welche technischen und organisatorischen Aspekte für die Entscheidungsfindung entscheidend sind.

3. Analyse – Technische, organisatorische und risikoorientierte Bewertung

In der Analysephase erfolgt eine vertiefte Prüfung der identifizierten Schlüsselfaktoren.

Technische Analyse: Quellcode-Bewertung, Architektur-Review, Prüfung auf Skalierbarkeit und technische Schulden.
Organisatorische Analyse: Evaluierung der Teamstruktur, Entwicklungsprozesse und Kommunikationsflüsse.
Risikobewertung: Identifikation von Abhängigkeiten, technischen Engpässen und Sicherheitsrisiken.
Due-Diligence-Spezifika: Analyse technischer Lizenz- und Abhängigkeitsstrukturen, der Dokumentationslage zu IP-Fragen sowie der technisch dokumentierten Umsetzung regulatorischer Anforderungen.

Alle Ergebnisse werden nachvollziehbar dokumentiert, mit technischen Belegen untermauert und in ihrer Relevanz für Investitionsentscheidungen eingeordnet.

4. Sachverständige Synthese – Bewertung, Risiken und Handlungsempfehlungen

Der abschließende Bericht fasst die Ergebnisse in strukturierter Form zusammen. Er enthält:

eine klare Bewertung der technologischen Substanz,
eine Risikoeinschätzung für Investoren und Stakeholder,
eine Analyse der Wachstums- und Skalierungspotenziale,
und konkrete Handlungsempfehlungen zur Stärkung technischer Stabilität und Governance.

Das Gutachten bietet damit eine fundierte, objektive und nachvollziehbare Grundlage für Investitionsentscheidungen, M&A-Prozesse oder die strategische Weiterentwicklung des Unternehmens.

Methodische Anregung:
Nicolai Andler: Tools für Projektmanagement, Workshops und Consulting – Kompendium der wichtigsten Techniken und Methoden, 6. überarbeitete und erweiterte Auflage, Publicis, Erlangen, 2015, ISBN 978-3-89578-453-8. Die sachverständige Synthese und die Beispiele sind eigene fachliche Adaptionen. Quellen und Methodik.

Beispiel für ein Gutachtenangebot

Analyse von Softwarearchitektur, Codebasis, Repositories und technischer Dokumentation
Rekonstruktion relevanter Build-, Test-, Release- und Deploymentstände
Technische Bewertung von Entwicklungsprozess, Abhängigkeiten, Wartbarkeit und Übergabefähigkeit
Technische Erfassung von Sicherheits-, Provenienz- und Lizenzhinweisen im vereinbarten Prüfungsumfang
Bewertung auftragsrelevanter KI- oder datengetriebener Komponenten
Bericht mit Befunden, technischen Risiken, Priorisierung, Gegenhypothesen und Aussagegrenzen

Orientierung nach Untersuchungstiefe:

Klar abgegrenzte technische Prüfung oder Stellungnahme: ca. 1.500 € bis 4.500 € netto
Umfangreichere technische Begutachtung: ca. 4.500 € bis 10.000 € netto
Komplexes IT-Gutachten mit umfangreicher technischer Untersuchung: ca. 10.000 € bis 20.000 € netto oder darüber

Maßgeblich sind insbesondere die konkrete Fragestellung, Projekt- und Systemgröße, Anzahl und Zustand der zu untersuchenden Artefakte, Qualität der verfügbaren Unterlagen sowie die erforderliche Untersuchungstiefe und Berichtsdokumentation.

Nach einer ersten Sichtung der Fragestellung und der verfügbaren Unterlagen kann ein individuelles und unverbindliches Angebot erstellt werden. Je nach Untersuchungsgegenstand kann insbesondere ein Festpreis oder eine andere geeignete Vergütungsstruktur vereinbart werden.

Hinweis: Die genannten Größenordnungen dienen ausschließlich der ersten Orientierung und stellen kein verbindliches Angebot dar. Der konkrete Aufwand kann im Einzelfall auch außerhalb dieser Bereiche liegen.

Kontakt zum IT-Sachverständigen Mathias Ellmann

Benötigen Sie eine unabhängige technische Due Diligence zur objektiven Bewertung der technologischen Substanz und Investitionsreife eines Startups?

Kontakt aufnehmen

Häufige Fragen zur technischen Due Diligence

Was ist eine technische Due Diligence?

Sie ist eine strukturierte Prüfung der technologischen Substanz eines Startups oder Unternehmens – einschließlich Softwarearchitektur, Codequalität, IT-Sicherheit und Skalierbarkeit.

Was ist der Unterschied zwischen einer IT Due Diligence und einer Software Due Diligence?

Eine IT Due Diligence bewertet Infrastruktur, Prozesse und Systeme, während eine Software Due Diligence den Fokus auf Codequalität, Architektur und Entwicklungsreife legt – oft kombiniert in einem Gesamtgutachten.

Wann ist eine technische Due Diligence sinnvoll?

Vor Investitionen, Übernahmen oder bei der Bewertung von Technologiepartnerschaften. Sie reduziert Risiken und erhöht die Transparenz für Investoren und Gründer.

Wer führt eine technische Due Diligence durch?

Sie wird von unabhängigen IT-Sachverständigen oder technischen Prüfern durchgeführt, die Erfahrung in Softwareentwicklung, IT-Governance und Compliance besitzen.

Weiterführendes Wissen

Fachliche Vertiefungen zu Projektstand, Software-Provenienz, Build- und Deploymentzuständen sowie technischer Rekonstruktion.

Repository, Commit, Branch & Build Technischen Softwarestand nachvollziehbar bestimmen. Git-Historie & Software-Provenienz Entstehung und Herkunft von Software technisch rekonstruieren. Deployment & Produktivstand Build, Hosting und tatsächlich betriebenen Systemstand abgrenzen. IT-Projektverlauf rekonstruieren Anforderungen, Änderungen, Releases und technische Chronologie untersuchen.