Technische Due Diligence ist kein Code-Review. Sie beantwortet eine Frage: Was kostet es, diese Technologie dorthin zu bringen, wo die Investmentthese sie braucht?
Die meisten technischen Due-Diligence-Prüfungen produzieren ein Dokument, das niemand nutzt. Es listet Frameworks auf, zählt Tests und merkt an, die Dokumentation könnte besser sein — und dann kommt der Deal zustande oder nicht, aus völlig anderen Gründen. Das verschenkt eine echte Gelegenheit, Risiko zu bepreisen.
Nützliche technische Due Diligence beantwortet drei Fragen in betriebswirtschaftlichen Begriffen: Kann diese Technologie den Plan tragen, den Sie finanzieren, was kostet es, die Lücken zu schließen, und welche Risiken können Wert vernichten statt ihn nur zu verlangsamen.
Wozu technische Due Diligence tatsächlich dient
Ein Venture-Investor kauft keine Codebasis. Er kauft eine These: Dieses Team erreicht jene Größenordnung in diesem Zeitraum. Technologie zählt nur dort, wo sie diese These wahrscheinlicher oder unwahrscheinlicher macht.
| Die These besagt | Also muss die Prüfung klären |
|---|---|
| 10x Nutzerwachstum in 24 Monaten | Wo die Architektur bricht und was es kostet, diese Decke anzuheben |
| Expansion in die EU | Ob die Datenverarbeitung DSGVO übersteht und was eine konforme Version kostet |
| Das ist ein Payments-Geschäft | Ledger-Integrität, Idempotenz, Abstimmung — die Dinge, die echtes Geld verlieren |
| Das Team kann liefern | Delivery-Durchsatz und Bus-Faktor, nicht Lebenslaufqualität |
| Verteidigbare Technologie | Ob der Burggraben echtes Engineering ist oder eine dünne Schicht über fremdem API |
Die fünf Bereiche, auf die es ankommt
1. Architektur und Skalierungsspielraum
Jedes System hat eine Decke. Die Frage ist, wo sie relativ zum Plan liegt und wie teuer es ist, sie anzuheben. Ein Monolith, der 100.000 Nutzer problemlos bedient, ist kein Befund; ein Monolith mit einer einzigen Write-Master-Datenbank und einem Wachstumsplan auf 10 Millionen schon.
- Single Points of Failure — und ob das Team sie kennt
- Die Datenschicht — meist die eigentliche Decke und das Teuerste, was sich später ändern lässt
- Ob Last je getestet wurde oder Skalierung nur angenommen wird
- Cloud-Kostenkurve: Überlebt die Unit Economics 10x, oder frisst die Infrastruktur die Marge?
2. Geld- und Datenintegrität
Für jedes Unternehmen, das Zahlungen, Salden oder regulierte Daten berührt, ist dies der Bereich mit den höchsten Fehlerkosten — und der, der am häufigsten übersprungen wird, weil seine Prüfung Fachwissen erfordert.
- Wird der Saldo aus einem unveränderlichen Ledger abgeleitet oder ist er eine veränderbare Zahl, die Code überschreiben kann?
- Idempotenz auf Zahlungs- und Webhook-Pfaden — kann ein Retry doppelt belasten?
- Geld als Ganzzahlen in Minor Units gespeichert, niemals als Float
- Abstimmung: Würde eine Abweichung intern entdeckt — oder von einem Kunden?
3. Sicherheits- und Compliance-Exponierung
Sicherheitsbefunde sind nur sinnvoll, wenn sie an eine Konsequenz gebunden sind. «Abhängigkeiten sind veraltet» ist Rauschen. «Ein nicht authentifizierter Endpunkt liefert Datensätze anderer Mandanten» ist eine Vertragsklausel.
- Autorisierung serverseitig pro Anfrage durchgesetzt, nicht im UI versteckt
- Mandantentrennung — der mit Abstand häufigste ernste Befund in B2B-SaaS
- Secrets-Management und ob Zugangsdaten in der Git-Historie liegen
- Welche regulierten Daten gespeichert werden — und ob sie überhaupt gespeichert werden sollten
- Abstand zur Zertifizierung, die der Go-to-Market erfordert (SOC 2, ISO 27001, PCI DSS)
4. Lieferfähigkeit
Das sagt die nächsten zwei Jahre besser voraus als die aktuelle Codebasis. Eine mittelmäßige Codebasis mit starker Lieferdisziplin verbessert sich. Eine elegante Codebasis ohne die Fähigkeit, sicher auszuliefern, nicht.
- Deployment-Frequenz und Durchlaufzeit für eine kleine Änderung
- Ob Rollback geübte Routine oder Theorie ist
- Testabdeckung auf den Pfaden, die zählen (Geld, Auth), statt einer globalen Prozentzahl
- Incident-Erkennung: Finden sie Probleme vor den Kunden?
5. Team- und Schlüsselpersonenrisiko
- Bus-Faktor: Wie viele Menschen verstehen die kritischen Subsysteme — lautet die Antwort «einer», ist das ein Deal-Risiko
- Ob Wissen außerhalb von Köpfen existiert
- Abhängigkeit von Contractors bei Kern-IP und ob die IP-Übertragung sauber ist
- Realismus des Hiring-Plans gegenüber der finanzierten Roadmap
Warnsignale, sortiert nach tatsächlichen Kosten
| Befund | Schweregrad | Warum |
|---|---|---|
| Veränderbare Salden / kein Ledger in einem Fintech | Deal-Ebene | Verluste sind unbegrenzt und können unbemerkt bereits eingetreten sein |
| Mandantenübergreifender Datenzugriff | Deal-Ebene | Eine Offenlegung beendet Enterprise-Vertrieb und ruft Regulierer auf den Plan |
| Ein einzelner Entwickler hält alles kritische Wissen | Hoch | Sein Weggang setzt die Roadmap zurück |
| Keine Deployment-Automatisierung | Hoch | Begrenzt den Durchsatz unabhängig von Einstellungen |
| Unklare IP-Rechte von Contractors | Hoch | Juristisch, nicht technisch — tötet aber Exits |
| Veraltete Abhängigkeiten | Niedrig | Routinewartung, in Tagen bepreisbar |
| Uneinheitlicher Code-Stil | Rauschen | Ignorieren |
Der Zweck technischer Due Diligence ist nicht, einen Grund zum Absagen zu finden. Er ist, genau zu wissen, was man kauft, damit Preis und Plan es abbilden.
Wie Befunde zu Vertragsbedingungen werden
- Sanierungsbudget — die Korrekturen quantifizieren und explizit in der Runde finanzieren, statt sie in Monat sechs zu entdecken
- Meilensteinbedingungen — Tranchenfreigabe an konkrete Sanierung geknüpft (üblich, wenn Compliance-Lücken den Go-to-Market blockieren)
- Bewertungsanpassung — dort, wo die Sanierung im Verhältnis zur Runde groß ist
- Post-Close-Plan — eine 90-Tage-Roadmap, vor der Überweisung vereinbart, nicht danach improvisiert
Wie lange es dauert
| Tiefe | Dauer | Wann einzusetzen |
|---|---|---|
| Screening | 2–3 Tage | Frühphase, kleines Ticket, reiner Plausibilitätscheck |
| Standard | 1–2 Wochen | Die meisten Series-A-/Series-B-Runden |
| Tief | 3–4 Wochen | Fintech, Healthtech, großes Ticket oder bekanntermaßen unordentliches Target |
Länger ist nicht besser. Jenseits von zwei Wochen produzieren die meisten Mandate Details statt Entscheidungen — sofern die Domäne es nicht wirklich verlangt, wie bei Zahlungen oder regulierten Gesundheitsdaten.
Den Prüfumfang vor dem Datenraum bestimmen
Die Prüfung muss zur Investitionsthese passen. Vor der Risikobewertung Fragen, wesentliche Systeme und erforderliche Nachweise festlegen.
- Wachstumsannahmen mit Kapazitäts- und Betriebskostendaten verbinden.
- Managementaussagen, geprüfte Ergebnisse und fehlende Daten trennen.
- Bedingungen vor Abschluss vom finanzierten Maßnahmenplan danach unterscheiden.
Häufige Fragen
Was ist der Unterschied zwischen technischer Due Diligence und einem Code-Audit?
Ein Code-Audit prüft Codequalität. Technische Due Diligence prüft, ob Technologie, Team und Lieferprozess einen konkreten Geschäftsplan tragen können — und was die Lücken kosten. Code ist einer von fünf Inputs; Architektur, Sicherheit, Lieferfähigkeit und Schlüsselpersonenrisiko wiegen für die Investitionsentscheidung meist schwerer.
Wer zahlt die technische Due Diligence?
Fast immer der Investor, als Teil der Transaktionskosten. Gelegentlich beauftragt ein Gründer sie vor der Runde, um Probleme zu finden und zu beheben, bevor Investoren es tun — meist gut angelegtes Geld, denn Befunde, die die Gegenseite entdeckt, kosten in der Verhandlung weit mehr als im Engineering.
Braucht man die Kooperation des Startups?
Ja. Sinnvolle Due Diligence braucht Lesezugriff auf das Repository, einen Architektur-Walkthrough und ein Gespräch mit den Entwicklern. Ein Target, das sich dem widersetzt, ist selbst ein erwähnenswerter Befund.
Lässt sich technische Due Diligence in wenigen Tagen durchführen?
Ein Screening-Durchgang schon, und er findet zuverlässig Probleme auf Kategorieebene: kein Ledger in einem Payments-Unternehmen, keine Deployment-Automatisierung, Bus-Faktor eins. Er sagt Ihnen nicht, was die Sanierung kostet. Für eine bepreiste Runde sind ein bis zwei Wochen das realistische Minimum.
Ist eine Prüfung mit eingeschränktem Zugang möglich?
Ja, mit entsprechend begrenztem Umfang. Restunsicherheit dokumentieren und fehlende Belege anfordern, bevor die Schlussfolgerung als belastbar gilt.
Due Diligence bei einem Portfoliounternehmen?
Wir liefern Befunde nach geschäftlicher Auswirkung sortiert, mit Sanierungskosten, die Sie in die Verhandlung mitnehmen können — in ein bis zwei Wochen.
Weiterführend
Code-Audit vor der Investition: Was Sie verlangen sollten, bevor Sie überweisen
Sie kaufen gleich einen Anteil an einem Vermögenswert, den Sie nicht besichtigt haben. Ein Code-Audit ist die Besichtigung — aber nur, wenn es auf Investitionsfragen zugeschnitten ist statt auf technische.
Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen
Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.