Technische Due Diligence

Technische Due Diligence, die dir zeigt, was du wirklich kaufst.

Bevor du investierst, übernimmst oder eine Plattform freigibst, solltest du wissen, was hinter der Demo steckt. Wir prüfen den vereinbarten Code, die Architektur, die Security-Lage und den Delivery-Prozess und übergeben dir einen schriftlichen Bericht, der die Risiken gewichtet und erklärt, was ihre Behebung bedeutet.

Due-Diligence-Umfang besprechen →

KURZ ERKLÄRT

Technische Due Diligence ist eine unabhängige Prüfung der Software hinter einem Unternehmen oder Produkt vor einer Investition, einer Übernahme oder einer Entscheidung des Boards. Am Ende steht ein schriftlicher Risikobericht mit Schweregrad, Belegen und Lösungswegen, keine Rechts- oder Finanzberatung.

Passt für

Investoren, Käufer und Boards, die vor einer Entscheidung einen externen Blick auf ein Software-Asset brauchen
Gründer, die ihre eigene Plattform prüfen lassen wollen, bevor Investoren die Fragen stellen

Eine andere Leistung passt besser

Rechtliche, steuerliche oder finanzielle Due Diligence oder eine Aussage zur Bewertung
Code nach einem Anbieterwechsel übernehmen und weiter betreiben

Bei der Entscheidung beginnen, die der Bericht stützen soll

Ein Investor vor einer Runde, ein Käufer vor dem Signing und ein Board, das die eigene Plattform prüft, brauchen unterschiedliche Tiefe. Vor dem Start vereinbaren wir die Entscheidung, die Systeme und Repositories im Umfang, den verfügbaren Zugriff und den Empfänger des Berichts. Kommerzielle, rechtliche, steuerliche und finanzielle Prüfung bleiben bei deinen Anwälten und Beratern. Berührt ein technischer Befund ihre Arbeit, etwa unklare Rechte am Code oder Pflichten aus Open-Source-Lizenzen, markiert der Bericht das für sie, ohne eine rechtliche Schlussfolgerung zu ziehen.

Was die Prüfung abdeckt

Die Abdeckung folgt dem vereinbarten Umfang. Für jeden Bereich halten wir fest, was wir geprüft haben, worauf wir keinen Zugriff hatten und wie belastbar die Schlussfolgerung ist.

Code und Architektur

Struktur, Testabdeckung und Testqualität, Dokumentation, Abhängigkeit von einzelnen Personen und wie schwer sich das System ändern lässt.

Security-Lage

Zugriffe auf Code und Infrastruktur, Umgang mit Secrets, verwundbare Abhängigkeiten und offensichtliche Angriffsflächen. Das ist eine Prüfung, kein Penetrationstest.

Delivery-Prozess und Team

Wie Änderungen in Produktion kommen, Release- und Rollback-Praxis, Incident-Historie und wer das Wissen trägt.

Skalierung, Betrieb und Kosten

Hosting, Monitoring, Wiederherstellbarkeit sowie die Infrastruktur- und Drittanbieterkosten hinter dem Produkt.

KI-spezifische Nachweise

Bei KI-Produkten Evaluationsdesign, Modell- und Prompt-Dokumentation, Anbieterabhängigkeit, Fehlerbehandlung und Kosten pro Aufgabe. Unsere [Due-Diligence-Checkliste für KI-MVPs](/de/blog/technical-due-diligence-ai-mvp/) listet die Nachweise, nach denen wir suchen.

Abhängigkeiten und technische Schulden

Veraltete Frameworks, nicht mehr unterstützte Komponenten und Schulden, die die Roadmap bremsen, mit einer groben Einschätzung, was ihre Behebung kostet.

Ein Bericht, der Risiken gewichtet, statt alles aufzulisten

Jeder Befund hat einen Schweregrad, die Belege dahinter, die wahrscheinliche Auswirkung auf den Business Case und realistische Wege zur Behebung. Wenn du Aufwände sehen willst, nennen wir Spannen, klar gekennzeichnet als Schätzungen unter den für den Auftrag vereinbarten Annahmen, nicht als Angebote. Der Bericht trennt dealrelevante Risiken von normaler Engineering-Pflege und listet die Fragen, die das Management noch beantworten muss. Er sagt weder Bewertung noch Deal-Konditionen noch den Ausgang einer Transaktion voraus.

So läuft eine Due Diligence ab

Umfang, Zeitplan und Fixpreis vereinbaren wir vor Beginn in einem unterschriebenen Leistungsvertrag. Die Dauer hängt von der Größe des Systems ab und davon, wie schnell Zugriffe und Gespräche möglich sind.

Scoping und Zugriff
Entscheidung, Systeme, Empfänger und Vertraulichkeit festlegen. Lesezugriff auf Repositories, Datenraum und relevante Dokumentation erhalten.
Prüfung und Gespräche
Code und Infrastruktur prüfen und mit den Leuten sprechen, die das System bauen und betreiben. Offene Fragen gehen schriftlich an das Management.
Bericht und Besprechung
Du erhältst den schriftlichen Bericht und gehst ihn mit uns durch. Sachliche Korrekturen des geprüften Unternehmens behandeln wir so, wie es vorab vereinbart wurde.

Nach dem Bericht den passenden nächsten Schritt wählen

Die Due Diligence endet mit dem Bericht. Übernimmst du danach den Code oder wechselst den Anbieter, gehören Zugriffsübernahme und Stabilisierung zur Software-Übernahme. Laufende Release-Tests sind Qualitätssicherung. Angriffstests und Härtung einer KI-Funktion gehören zu AI Security, die laufende Cloud-Umgebung zu Cloud Security. Wurde das Produkt mit Lovable, Bolt oder ähnlichen Tools gebaut und muss repariert werden, passt Vibe Coding Rescue. Braucht das Unternehmen während einer Finanzierungsrunde oder eines Verkaufs eine technische Führungskraft auf seiner Seite, ist das eine Rolle für einen Fractional CTO. Falls wir später ein Angebot für die Behebung abgeben könnten, sagen wir das vor Beginn der Prüfung.

Das eigene Unternehmen auf eine Due Diligence vorbereiten

Gründer können dieselbe Prüfung vor einer Runde für ihre eigene Plattform beauftragen. Ziel ist, Lücken zu finden, solange noch Zeit bleibt, sie zu schließen oder zu erklären. Hilfreich sind ein datiertes Architekturdiagramm, ein Abhängigkeitsinventar, Zugänge in Firmenaccounts, Release- und Incident-Aufzeichnungen und bei KI-Produkten versionierte Evaluationsergebnisse. Kommt das Produkt aus einem KI-Builder, lies zuerst Due Diligence für Lovable-, Bolt- und Replit-Apps.

// beweise

Prüfarbeit in bestehenden Projekten

Keiner dieser Fälle ist eine formale Due Diligence für Investoren oder M&A. Cedars dokumentiert ein technisches Assessment mit Architektur- und Anforderungsdokumentation, gezieltem Source-Review, einer abgegrenzten KI-Prüfung und priorisierten Maßnahmen mit Kriterien für die Nachprüfung. Polity dokumentiert eine nachvollziehbare Analyse, die Behebungsbedarf über sieben Services erkannt und priorisiert hat. Soundromeda dokumentiert Risiko-Triage und Härtung eines Prototyps, bevor Förderkomitees den Build begutachtet haben. Die Fälle zeigen die Prüfmethode, kein Due-Diligence-Ergebnis.

Prüfgrundlage Architektur, Anforderungen, Assets und Verantwortlichkeiten für die Prüfung strukturiert.

Dokumentationsstrukturen, gezielte Codeprüfungen und ein abgegrenztes KI-Assessment gaben Cedars eine priorisierte Grundlage für …

PHP JavaScript Python

7 Services Vereinheitlichtes Testen

1,5 Jahre QA-Eigentümerschaft über sieben Services und mehrere Vendoren. Qualität blieb durch jeden Refactor lieferbar.

React Java/Kotlin Go

Produktion Vibe-Coded → gehärtet

QA-geführtes Härten brachte einen Vibe-Coded-Game-Prototypen in einen Zustand, den Förderkommissionen unterstützten.

Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.

Fragen vor dem Start

Ist das eine rechtliche oder finanzielle Due Diligence?

Nein. Wir prüfen die Software, ihre Auslieferung und ihren Betrieb. Verträge, Rechteübertragungen, Lizenzen, Steuern und Finanzzahlen bleiben bei deinen Anwälten und Finanzberatern. Berührt ein technischer Befund ihre Arbeit, markiert der Bericht das für sie, ohne rechtliche Schlussfolgerung.

Garantiert der Bericht eine Bewertung oder einen Deal-Ausgang?

Nein. Der Bericht beschreibt die technischen Risiken, die wir im vereinbarten Umfang gefunden haben, und die Belege dafür. Wie sich das auf Preis, Konditionen oder die Entscheidung auswirkt, entscheidest du mit deinen Beratern.

Wie lange dauert es und was kostet es?

Das hängt von der Größe des Systems, der gewünschten Tiefe und davon ab, wie schnell Zugriffe freigegeben werden. Nach einem kurzen Scoping-Gespräch vereinbaren wir Umfang, Zeitplan und Fixpreis in einem unterschriebenen Leistungsvertrag.

Welche Zugriffe braucht ihr?

Lesezugriff auf Repositories, Infrastruktur-Konfiguration und Datenraum sowie Zeit mit den Leuten, die das System bauen und betreiben. Fehlt ein Zugriff, nennt der Bericht, welche Schlussfolgerungen dadurch eingeschränkt sind.

Könnt ihr das, was ihr findet, auch beheben?

Ja, als eigener Auftrag nach dem Bericht und nur, wenn du das willst. Besteht die Möglichkeit, dass wir ein Angebot für die Behebung abgeben, legen wir das vor Beginn offen, damit du die Unabhängigkeit der Befunde einschätzen kannst.

Due-Diligence-Umfang besprechen

Beschreib kurz die Entscheidung, das Unternehmen oder System und deinen Zeitplan. Für das erste Gespräch reicht ein Überblick ohne vertrauliche Details; vor jedem Zugriff auf Datenraum oder Repositories unterschreiben wir eine NDA.