Eine Checkliste nützt nur, wenn an jedem Punkt eine Konsequenz hängt. Diese ist danach geordnet, was einen Deal tatsächlich verändert.
Eigentum und Abhängigkeiten
Produkt und Betrieb
Maßnahmen und Entscheidung
Nutzen Sie dies als Arbeitsdokument während der Prüfung. Jeder Abschnitt nennt, was anzufordern ist, was zu verifizieren ist und — entscheidend — was eine schlechte Antwort kommerziell bedeutet. Die Punkte sind nach Kosten des Irrtums geordnet, nicht nach Bequemlichkeit der Prüfung.
Vorab: was anzufordern ist
- Lesezugriff auf alle Repositories, einschließlich Infrastructure-as-Code
- Vollständige Commit-Historie (kein zusammengefasster Snapshot — die Historie zeigt, wer das wirklich gebaut hat und wie schnell)
- Architektur-Walkthrough mit dem Entwickler, der es gebaut hat, 1–2 Stunden
- Zugang zum Issue-Tracker und zu allen Incident-Aufzeichnungen
- Liste der Drittanbieterdienste und ihrer Vertragsbedingungen
- Contractor-Verträge und IP-Übertragungsdokumente
Abschnitt 1 — Geld- und Datenintegrität (Deal-Ebene)
| Prüfung | Eine schlechte Antwort bedeutet |
|---|---|
| Salden aus einem Append-only-Ledger abgeleitet? | Geld kann lautlos falsch und nicht wiederherstellbar sein — Sanierung finanzieren oder aussteigen |
| Idempotency Keys auf jedem Zahlungspfad? | Retries können doppelt belasten; Verluste können unentdeckt bereits bestehen |
| Geld als Ganzzahlen in Minor Units gespeichert? | Float-Arithmetik akkumuliert Fehler über jede Transaktion |
| Abstimmung gegen die Settlement-Daten des Anbieters? | Abweichungen tauchen über Kundenbeschwerden auf |
| Unveränderlicher Audit-Trail inkl. Admin-Aktionen? | Fragen von Regulierern oder in Streitfällen nicht beantwortbar |
Abschnitt 2 — Sicherheit und Mandantentrennung (Deal-Ebene)
- Autorisierung serverseitig bei jeder Anfrage durchgesetzt, nicht durch Verstecken von UI-Elementen
- Mandantenisolierung durch Test verifiziert, nicht aus dem Codelesen angenommen
- Secrets in einem Manager, nicht in der Git-Historie (Historie prüfen, nicht nur HEAD)
- Welche regulierten Daten gespeichert werden, wo, und ob das nötig ist
- Abstand zur Zertifizierung, die der Go-to-Market erfordert (SOC 2, ISO 27001, PCI DSS)
Abschnitt 3 — Eigentum und Recht (Deal-Ebene)
- Unterzeichnete IP-Übertragung von jedem Contractor und Gründer
- Open-Source-Lizenzprüfung — Copyleft-Kontamination in einem proprietären Produkt
- Von früheren Arbeitgebern kopierter Code (direkt fragen; es kommt vor)
- Vendor Lock-in: Was bricht, wenn ein zentraler Anbieter die Preise ändert oder schließt
Abschnitt 4 — Architektur und Skalierung (hoch)
- Wo das System unter dem Wachstum im Finanzmodell bricht — eine konkrete Zahl, keine Beruhigung
- Die Decke der Datenschicht: einzelner Write-Master, unbegrenzte Queries, Indexabdeckung gegen echte Query-Muster
- Fehlerisolierung: kaskadiert eine langsame Abhängigkeit in einen Totalausfall
- Infrastruktur-Kostenkurve beim Zehnfachen — überlebt die Unit Economics
- Architektur passend zur Teamgröße (verteilte Systeme mit kleinem Team sind eine Kostenposition, keine Auszeichnung)
Abschnitt 5 — Lieferfähigkeit (hoch)
| Signal | Gesund | Bedenklich |
|---|---|---|
| Deployment-Frequenz | Mehrmals pro Woche | Monatlich, terminiert, gefürchtet |
| Durchlaufzeit kleiner Änderungen | Stunden bis ein Tag | Wochen |
| Rollback | Ein Befehl, geprobt | Nie getestet |
| Incident-Erkennung | Internes Monitoring | Kundenmeldungen |
| Tests auf Geld-/Auth-Pfaden | Vorhanden | Fehlend, unabhängig von der Gesamtabdeckung |
Abschnitt 6 — Team- und Schlüsselpersonenrisiko (hoch)
- Bus-Faktor jedes kritischen Subsystems — ist einer davon 1, ist das ein Deal-Risiko, das Absicherung braucht
- Ob Wissen schriftlich existiert oder nur in Köpfen
- Retention-Exposition: wessen Verlust in den nächsten 12 Monaten katastrophal wäre
- Realismus des Hiring-Plans, den die Roadmap voraussetzt
Bewertung: Konsequenz, nicht Geschmack
Bewerten Sie jeden Befund danach, was passiert, wenn er nicht behoben wird, und lassen Sie das die Deal-Reaktion bestimmen:
- Deal-Ebene — Geldintegrität, Datenoffenlegung, unklare IP. Vollzugsbedingung oder finanzierte Sanierung.
- Hoch — Skalierungsdecke unterhalb des Plans, Einzelpersonenabhängigkeit, keine Deployment-Sicherheit. In den 90-Tage-Plan nach Closing eingepreist.
- Mittel — kumulierende Schuld, die die Lieferung verlangsamt. Vermerken und beobachten.
- Rauschen — Stil, Framework-Präferenz, Dokumentationsumfang. Vollständig aus dem Bericht ausschließen.
Lässt sich ein Befund nicht an Geld, Zeit oder rechtliche Exponierung binden, gehört er nicht in ein Investment-Memo.
Worauf Sie im Abschlussbericht bestehen sollten
- Eine einseitige Zusammenfassung, mit der ein nicht-technischer Partner handeln kann
- Jeder Befund mit Belegen, die das Team des Targets unabhängig prüfen kann
- Sanierungsschätzungen in Entwicklerwochen, damit sie in Geld umrechenbar sind
- Eine ausdrückliche Angabe, was NICHT geprüft wurde — damit niemand eine Abdeckung annimmt, die es nicht gab
Aus der Checkliste eine Entscheidungsgrundlage machen
Jede Antwort braucht Belege und einen Bezug zur Transaktion. Vereinbaren Sie Grenzen, Zugänge und Fragen vor der Dokumentensammlung. Trennen Sie geprüfte Befunde, Aussagen des Managements und fehlende Nachweise. Eine leere Zelle belegt kein geringes Risiko.
| Die Entscheidung messbar machen | Nachweise vor Beginn vereinbaren |
|---|---|
| Eigentum und Abhängigkeiten | Repository-Verlauf, Vereinbarungen mit Mitwirkenden und Abhängigkeitsliste anfordern. Rechtliche Ansprüche prüft die Rechtsberatung. |
| Produkt und Betrieb | Wesentlichen Nutzerablauf, Bereitstellung und Wiederherstellung prüfen; Architektur mit Wachstumsannahmen vergleichen. |
| Maßnahmen und Entscheidung | Befunde mit Verantwortlichen, Aufwandsspanne, Abhängigkeiten und Verifikation versehen. Bedingungen vor Abschluss von späteren Maßnahmen trennen. |
Der Bericht nennt Prüfungen, Unbekanntes und mögliche Folgen für die Investition. Dokumentenprüfung allein bestätigt keine wirksamen Produktionskontrollen; technische Prüfung ersetzt keine rechtliche Zertifizierung.
Häufige Fragen
Was gehört in eine Checkliste für die technische Due Diligence?
Sechs Bereiche, nach Konsequenz geordnet: Geld- und Datenintegrität, Sicherheit und Mandantentrennung, IP-Eigentum, Architektur und Skalierungsspielraum, Lieferfähigkeit und Schlüsselpersonenrisiko. Jeder Punkt sollte eine benannte kommerzielle Konsequenz haben — eine Checkliste ohne Konsequenzen erzeugt Berichte, nach denen niemand handelt.
Welcher Punkt wird am häufigsten übersehen?
Die IP-Übertragung von Contractors. Es ist keine technische Frage, also überspringen technische Prüfer sie, und juristische Prüfer nehmen an, das Engineering habe sie abgedeckt. Sie hat zudem die längste Vorlaufzeit zur Behebung — deshalb gehört sie in die ersten Tage, nicht in die letzten.
Können Gründer diese Checkliste selbst nutzen?
Ja, und vor einer Runde ist das eine gute Idee. Befunde, die Sie selbst entdecken, werden zu einem Sanierungsplan, den Sie kontrollieren; dieselben Befunde durch den Berater eines Investors werden zu einer Verhandlungsposition gegen Sie.
Soll das jemand durchführen, der es wöchentlich tut?
Wir liefern Due Diligence mit Befunden nach geschäftlicher Konsequenz sortiert und Sanierung in Entwicklerwochen bepreist.
Weiterführend
Technische Due Diligence für Investoren: Der vollständige Leitfaden
Technische Due Diligence ist kein Code-Review. Sie beantwortet eine Frage: Was kostet es, diese Technologie dorthin zu bringen, wo die Investmentthese sie braucht?
Worauf VCs bei der technischen Due Diligence wirklich achten
Investoren benoten nicht Ihren Code. Sie bepreisen das Risiko, dass Technologie den Plan stoppt, den sie finanzieren — und Gründer, die das verstehen, bereiten sich völlig anders vor.