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.
Gründer polieren vor der technischen Due Diligence oft das Falsche — Code aufräumen, Dokumentation schreiben, nach der niemand gefragt hat, sich über Framework-Entscheidungen sorgen. Investoren stellen eine ganz andere Frage: Was an der Technologie könnte schiefgehen und dieses Unternehmen daran hindern, die Meilensteine im Plan zu erreichen?
Die vier Dinge, die tatsächlich bewertet werden
1. Skaliert es zum Plan (nicht ins Unendliche)
Niemand erwartet von einem Series-A-Unternehmen die Architektur von Google. Die Frage ist enger: Übersteht das System das konkrete Wachstum im Modell, und wenn nicht, was kostet es, diese Decke anzuheben? Eine klare, bepreiste Antwort ist ein starkes Signal. «Sollte passen» ist keins.
2. Schlüsselpersonenrisiko
Häufig der entscheidendste Befund — und der, mit dem Gründer am wenigsten rechnen. Hält ein einzelner Entwickler alles kritische Wissen, trägt das Investment ein Risiko, das mit Codequalität nichts zu tun hat. Investoren fragen das direkt ab: Wer sonst könnte dieses System nächste Woche betreiben, wenn diese Person ginge?
3. Ob die Technologie tatsächlich Ihnen gehört
- Contractor-Arbeit ohne unterzeichnete IP-Übertragung — ein juristisches Problem, das einen Abschluss verzögern oder killen kann
- Open-Source-Lizenzkontamination in einem proprietären Produkt
- Kritische Abhängigkeit von einem Anbieter, der Preise ändern, einschränken oder verschwinden kann
- Wie viel der «proprietären Technologie» eine dünne Schicht über fremdem API ist
4. Lieferfähigkeit
Das sagt die nächsten zwei Jahre besser voraus als der aktuelle Zustand der Codebasis. Investoren schauen auf Deployment-Frequenz, wie Änderungen in Produktion gelangen, ob Vorfälle intern erkannt werden und ob das Team die im Plan angenommenen Einstellungen verkraften kann.
Wie Sie sich vorbereiten (in den vier Wochen davor)
- Schreiben Sie ein ehrliches technisches Risikoregister — was schwach ist, was es blockiert, was die Behebung kostet. Das von sich aus zu liefern wirkt kompetent; beim Verbergen erwischt zu werden, wirkt gegenteilig.
- Beheben Sie zuerst alles aus der Kategorie Geld und Daten — das sind die Befunde, die zu Vertragsbedingungen werden.
- Schließen Sie IP-Lücken: unterzeichnete Übertragungen von jedem Contractor, Lizenzprüfung der Abhängigkeiten.
- Reduzieren Sie den Bus-Faktor sichtbar — setzen Sie jemanden zusätzlich auf das kritische System, schreiben Sie den Architecture Decision Record.
- Bereiten Sie einen klaren Architektur-Walkthrough vor: was es ist, warum, wo es bricht, was der Plan ist.
Wie Befunde zu Bedingungen werden
| Befund | Typisches Ergebnis |
|---|---|
| Geld kann lautlos falsch sein (kein Ledger) | Sanierung in der Runde finanziert; manchmal tranchiert |
| Mandantenübergreifende Datenoffenlegung | Vollzugsbedingung — beheben, bevor Mittel freigegeben werden |
| Unklare IP von Contractors | Juristische Bereinigung vor dem Closing erforderlich |
| Bus-Faktor eins | Retention-Paket oder Einstellungszusage im Plan |
| Manuelles Deployment, kein Rollback | In den 90-Tage-Plan nach Closing eingepreist |
| Alternde Abhängigkeiten, dünne Doku | Vermerkt, ohne Konsequenz |
Investoren erwarten kein perfektes System. Sie erwarten einen Gründer, der genau weiß, welche Teile unvollkommen sind und was es kostet, sie zu beheben.
Jeden Befund mit einer Entscheidung verbinden
Investoren müssen verbleibende Annahmen und Planänderungen verstehen. Unsicherheit neben Behebungsaufwand zeigen, statt sie in einer Kennzahl zu verstecken.
- Geschäftsannahme und geprüfte Belege nennen.
- Folgen, Unsicherheit und Abhängigkeiten der Behebung beschreiben.
- Abschlussbedingung, Budgetposten und akzeptiertes Risiko unterscheiden.
Häufige Fragen
Wie lange dauert die technische Due Diligence eines Investors?
Typischerweise ein bis zwei Wochen bei einer Series A, länger bei Fintech, Healthtech oder ungewöhnlich großen Systemen. Sie umfasst meist Repository-Zugang, einen Architektur-Walkthrough und Gespräche mit dem Engineering-Team.
Sollten Gründer vor der Runde ein eigenes technisches Audit machen?
Oft ja. Befunde, die Sie selbst aufdecken, werden zu einem Sanierungsplan, den Sie kontrollieren; dieselben Befunde durch den Berater des Investors werden zu einer Verhandlungsposition gegen Sie. Die Kosten eines Audits vor der Runde sind klein gegenüber der Bewertungswirkung, die es verhindern kann.
Killt unsauberer Code unsere Runde?
Selten für sich allein. Deals werden von Befunden mit Konsequenz beeinflusst — Geldintegrität, Sicherheitsexponierung, unklare IP-Rechte und Schlüsselpersonenrisiko. Investoren haben die Unvollkommenheiten jeder Codebasis gesehen; Sorge bereitet ihnen ein Team, das die eigenen Risiken nicht präzise beschreiben kann.
Reicht eine technische Gesamtnote?
Nein. Eine Note kann zusammenfassen, verdeckt aber Umfang und Unsicherheit. Wesentliche Befunde, fehlende Belege und Annahmen hinter Aufwandsschätzungen ergänzen.
Bald am Finanzieren?
Wir führen die Due Diligence, bevor Ihr Investor es tut — damit die Befunde mit Ihrem Sanierungsplan im Anhang kommen.
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?
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.