Technology Due Diligence: So bewerten Investoren Produkt, Features und Tech Stack
Wenn Investoren über Technology Due Diligence sprechen, meinen sie meistens eine von zwei Sachen: die Prüfung der Bausubstanz einer Gewerbeimmobilie oder die Bewertung eines Software-Produkts vor der Übernahme. Das sind zwei komplett verschiedene Disziplinen, die sich zufällig denselben Namen teilen. Dieser Artikel handelt von der zweiten Variante: der systematischen Prüfung von Produkt, Tech Stack und Entwicklungsorganisation bei Software-Investments und M&A-Transaktionen.
Technology Due Diligence (Tech DD) prüft, ob die Technologie eines Unternehmens hält, was der Business Plan verspricht. Sie deckt Risiken in Architektur, Code-Qualität, Team und Skalierbarkeit auf, bevor der Kaufvertrag unterschrieben wird. Laut Harvard Business Review scheitern 70-90 % aller Übernahmen an ihren Zielen. Einer der häufigsten Gründe: technische Probleme, die erst nach dem Closing sichtbar werden.
Was Technology Due Diligence wirklich prüft
Eine Technology Due Diligence analysiert die Produkt- und Tech-Organisation eines Unternehmens. Im Kern geht es um eine Frage: Kann diese Technologie das Wachstum tragen, das der Investor erwartet?
Das unterscheidet die Tech DD von der klassischen Commercial Due Diligence (die den Markt und das Geschäftsmodell prüft) und der Legal Due Diligence (die Verträge und Haftung durchleuchtet). Die Tech DD ergänzt beides um die technische Perspektive: Architektur, Code, Team, Prozesse.
Zwei typische Szenarien:
- Buy-Side: Ein VC- oder PE-Team will vor einer Investition verstehen, wie reif die Technologie ist, wo die Risiken liegen und welche Initiativen nach dem Deal notwendig werden.
- Sell-Side / Gesundheitscheck: Ein CEO lässt vor einer Finanzierungsrunde oder einem Verkauf die eigene Tech-Organisation durchleuchten, um Schwachstellen proaktiv zu beheben.
In beiden Fällen führen erfahrene Prüfer*Innen die Analyse durch, oft ehemalige CTOs oder CPOs, die nicht nur Code lesen können, sondern auch Teamdynamiken und Architekturentscheidungen im Kontext bewerten.
Sechs Bereiche, die jede Technology Due Diligence abdecken muss
Der genaue Scope variiert je nach Unternehmen und Branche. Aber sechs Prüfbereiche tauchen in praktisch jeder Tech DD auf:
| Prüfbereich | Was geprüft wird | Typische Risiken |
|---|---|---|
| Architektur & Tech Stack | Programmiersprachen, Frameworks, Datenbanken, Cloud-Infrastruktur | Veraltete Technologien, fehlende Skalierbarkeit, Vendor Lock-in |
| Code-Qualität & Technical Debt | Testabdeckung, Code-Standards, bewusst genommene Abkürzungen | Hohe Wartungskosten, langsame Feature-Entwicklung |
| Skalierbarkeit | Infrastruktur unter Last, Kosten der Skalierung, Disaster Recovery | Infrastrukturkosten explodieren bei Wachstum |
| Team & Organisation | Teamstruktur, Recruiting, Autonomie, Prozesse | Key-Person-Risk, Abhängigkeit von einzelnen Entwickler*Innen |
| Produktmanagement | Roadmap, Product Discovery, UX-Fähigkeiten, Datengetriebene Entscheidungen | Fehlende Produktstrategie, keine Nutzungsmetriken |
| Rechtliches & IP | Geistiges Eigentum, Open-Source-Lizenzen, DSGVO-Konformität | IP gehört nicht dem Unternehmen, Lizenz-Konflikte |
Stripe hat in ihrem Developer Coefficient Report gemessen, dass Entwickler*Innen im Schnitt 33 % ihrer Zeit mit Technical Debt verbringen. Das ist ein Drittel der Entwicklungskapazität, das nicht in neue Features fließt. Für Investoren ist das eine direkte Auswirkung auf die Geschwindigkeit, mit der ein Portfolio-Unternehmen wachsen kann.
Warum die Feature-Analyse der unterschätzte DD-Baustein ist
Die meisten Tech DDs konzentrieren sich auf Architektur, Code und Team. Das ist richtig und wichtig. Was oft zu kurz kommt: eine systematische Analyse des Produkts selbst. Welche Features hat das Target? Wie schneidet das Produkt im Vergleich zum Wettbewerb ab? Wo gibt es Feature Gaps, die nach dem Deal geschlossen werden müssen?
Diese Fragen sind relevant, weil sie direkt auf den Business Case einzahlen. Ein Unternehmen mit einer soliden Architektur, aber einem Produkt, dem drei entscheidende Features fehlen, braucht nach dem Closing sechs bis zwölf Monate Entwicklungszeit, bevor es wettbewerbsfähig ist. Das verändert die Bewertung.
Ein systematischer Feature-Vergleich als Teil der Tech DD beantwortet drei Fragen:
- Feature-Vollständigkeit: Deckt das Produkt die Kernfunktionen ab, die der Markt erwartet?
- Feature-Differenzierung: Wo hat das Produkt einen Vorsprung, den Wettbewerber nicht leicht kopieren können?
- Feature-Velocity: Wie schnell liefert das Team neue Features im Vergleich zum Markt?
Wer das manuell für 20 oder 50 Wettbewerber durchführen will, braucht Wochen. Genau hier setzen KI-gestützte Analysetools an, die diesen Prozess von einem Drei-Wochen-Projekt in eine Stunden-Analyse verwandeln.
Red Flags, die erfahrene Investoren sofort erkennen
Nicht jedes Risiko in einer Tech DD ist ein Dealbreaker. Manche Probleme lassen sich nach dem Closing beheben. Andere sind strukturell und teuer. Erfahrene Prüfer*Innen achten besonders auf diese Signale:
Key-Person-Risk: Wenn eine einzelne Person der einzige Mensch ist, der das Deployment-System versteht oder die Datenbankarchitektur erklären kann, ist das ein ernstes Problem. Fällt diese Person weg, steht die Entwicklung still.
Fehlende automatisierte Tests: Ohne Tests wird jede Änderung am Code zum Risiko. Teams, die ohne Testabdeckung arbeiten, liefern langsamer und produzieren mehr Fehler. Das skaliert nicht.
Undokumentierte Architekturentscheidungen: Wenn niemand erklären kann, warum das System so gebaut wurde, wie es gebaut wurde, ist das ein Zeichen dafür, dass die Architektur organisch gewachsen ist, ohne bewusste Planung.
Veraltete Frameworks ohne Migrationsstrategie: Eine Anwendung auf einem Framework, das seit drei Jahren keine Sicherheitsupdates mehr erhält, ist ein Compliance-Risiko und ein Migrations-Projekt, das in die Bewertung gehört.
Ungeklärte Open-Source-Lizenzen: Copyleft-Lizenzen wie GPL können bedeuten, dass proprietärer Code offengelegt werden muss. Wenn das Team nicht weiß, welche Lizenzen in der Codebasis stecken, hat das direkte Auswirkungen auf das geistige Eigentum.
Jedes dieser Signale ist einzeln beherrschbar. In Kombination ergeben sie ein Bild, das den Unternehmenswert direkt beeinflusst.
Was kostet eine Technology Due Diligence?
Die Kosten hängen von drei Faktoren ab: Größe des Targets, Tiefe der Analyse und Branchenspezifika.
| Unternehmensgröße | Typischer Kostenbereich | Umfang |
|---|---|---|
| Klein (bis 2 Mio. EUR Umsatz) | 5.000 - 12.000 EUR | Red-Flag-Report, Fokus auf Kernrisiken |
| Mittelstand (2-50 Mio. EUR) | 12.000 - 30.000 EUR | Vollständige Tech DD mit Interviews und Code-Review |
| Größerer Mittelstand (50-250 Mio. EUR) | 30.000 - 70.000 EUR | Detailanalyse inkl. Infrastruktur und Post-Merger-Plan |
| Großunternehmen (250+ Mio. EUR) | 70.000+ EUR | Multi-Workstream mit externen Spezialisten |
Der Prozess dauert je nach Komplexität zwei bis sechs Wochen. Ein typischer Ablauf:
- Kick-Off (Tag 1-3): NDA, Scoping, Informationsmemorandum sichten
- Dokumentenanalyse (Woche 1-2): Datenraum durcharbeiten, Code-Repositories sichten
- Interviews (Woche 2-3): Management- und Expertengespräche mit CTO, Lead Engineers, Product Leads
- Reporting (Woche 3-4): Ergebnisbericht mit Risikobewertung, Red Flags und Maßnahmenplan
Spezialisierte Beratungen wie wdp, TechMiners oder OMMAX bieten modulare Frameworks an, die sich an den jeweiligen Deal anpassen lassen. PwC und Roland Berger decken das Thema als Teil größerer M&A-Due-Diligence-Prozesse ab.
Manuelle Analyse vs. KI-gestützte Technology Due Diligence
Die klassische Tech DD ist ein manuelles, expertengetriebenes Verfahren. Das hat gute Gründe: Architekturentscheidungen bewerten, Teamdynamiken einschätzen und strategischen Fit beurteilen kann kein Algorithmus. Aber bei den datenintensiven Teilschritten verschenkt das manuelle Vorgehen Zeit und Geld.
Drei Bereiche, in denen KI die Tech DD bereits verändert:
- Wettbewerbs- und Feature-Analyse: Statt manuell 30 Wettbewerber zu recherchieren und Features in Spreadsheets zu vergleichen, liefern KI-gestützte Analysetools diese Daten in Stunden. Das gibt dem DD-Team mehr Zeit für die Bewertung der Ergebnisse.
- Code-Analyse: Tools wie CAST scannen Millionen Codezeilen und visualisieren Architektur, Abhängigkeiten und Technical Debt in 3D-Maps. Was früher Wochen dauerte, ist in Tagen erledigt.
- Markt- und Produktdaten: Alternative Datenquellen wie Job-Postings, Tech-Stack-Tracker und Produktbewertungen liefern Signale zur Entwicklungsgeschwindigkeit und Marktposition eines Targets, die in klassischen Datenräumen nicht auftauchen.
Die Kombination aus erfahrenen PrüferInnen und KI-Tools ist der neue Standard. Die KI übernimmt die Datenerhebung und Mustererkennung, die ExpertInnen die Interpretation und Bewertung. Wer beides zusammenbringt, liefert bessere Ergebnisse in kürzerer Zeit.
Technology Due Diligence Checkliste
Diese Checkliste fasst die wichtigsten Prüfpunkte zusammen. Sie ersetzt kein vollständiges Gutachten, gibt aber einen strukturierten Einstieg:
Architektur & Tech Stack:
- [ ] Ist der Tech Stack aktuell und wird aktiv weiterentwickelt?
- [ ] Kann die Architektur das erwartete Wachstum tragen?
- [ ] Gibt es Single Points of Failure?
- [ ] Wie hoch sind die Cloud-/Infrastrukturkosten pro Nutzer?
Code-Qualität:
- [ ] Wie hoch ist die Testabdeckung?
- [ ] Gibt es dokumentierte Code-Standards?
- [ ] Wie groß ist der Technical-Debt-Backlog?
- [ ] Wie sieht der SDLC (Software Development Life Cycle) aus?
Team & Organisation:
- [ ] Gibt es Key-Person-Abhängigkeiten?
- [ ] Passt die Teamstruktur zur Wachstumsphase?
- [ ] Wie läuft das Onboarding neuer Entwickler*Innen?
- [ ] Wie autonom können Teams arbeiten?
Produkt:
- [ ] Gibt es eine dokumentierte Produktstrategie?
- [ ] Welche Features fehlen im Vergleich zum Wettbewerb?
- [ ] Werden Nutzungsmetriken erhoben und für Entscheidungen genutzt?
- [ ] Wie schnell liefert das Team neue Features?
Rechtliches & IP:
- [ ] Gehört das geistige Eigentum vollständig dem Unternehmen?
- [ ] Werden Open-Source-Lizenzen aktiv überwacht?
- [ ] Ist die Anwendung DSGVO-konform?
Sicherheit:
- [ ] Gibt es ein Sicherheitskonzept und regelmäßige Audits?
- [ ] Wie wird mit Schwachstellen umgegangen?
- [ ] Gibt es einen Disaster-Recovery-Plan?
Von der Checkliste zur systematischen Produktanalyse
Die Checkliste zeigt, wie viele Datenpunkte in einer Tech DD zusammenkommen. Besonders beim Produkt- und Feature-Vergleich wird es manuell schnell unübersichtlich: 20 Wettbewerber, jeweils 15-30 Features, dazu Pricing, Positionierung und Kundenfeedback.
Researchly's AI-Agenten übernehmen genau diese Arbeit. Sie analysieren Wettbewerber, vergleichen Features systematisch und liefern die Ergebnisse als strukturierte Market Map, die direkt in den DD-Report fließen kann.
Was Sie damit in Stunden statt Wochen erhalten:
- Feature-Matrix über 20+ Wettbewerber, mit qualitativer Bewertung pro Feature
- Wettbewerbs-Benchmark mit Stärken-Schwächen-Profil des Targets
- Produkt-Positionierungskarte, die zeigt, wo das Target im Markt steht
Für DD-Teams, die ihre Due-Diligence-Tools aufrüsten wollen: Researchly lässt sich 14 Tage kostenlos testen.
