Die meisten Founder glauben, Due Diligence drehe sich um das Pitch Deck, die Wachstumskurve und die Marktgröße. Wenn die technische Due Diligence beginnt, sind diese Fragen längst beantwortet — der Investor ist interessiert. Was jetzt passiert, entscheidet leise über die Qualität des Deals: den Bewertungsabschlag, den Earn-out, die Retention-Klausel oder ein höfliches „wir melden uns". Technische Due Diligence ist dabei kein Nischen-Check mehr: Schätzungen zufolge verlangen rund 70 % der privaten Investoren sie vor dem Abschluss bei digitalen Startups. Die meisten Startups scheitern nicht offen an Due Diligence. Sie verlieren still Wert in ihr. Dieser Leitfaden zeigt, was Investoren wirklich bewerten, welche Red Flags Verhandlungsmacht kosten und wie du so arbeitest, dass das Audit nur bestätigt, was du ohnehin weißt.
Die wichtigsten Punkte
| Punkt | Details |
|---|---|
| Es misst Risiko, nicht Tools | Investoren bepreisen Execution-, Scaling-, Dependency-, Security- und Team-Risk — nicht deine Framework-Wahl. |
| Rewrite-Risiko ist der große Hebel | Braucht Skalierung einen Rewrite, sinkt die Bewertung. Klare Grenzen und geringe Kopplung schützen sie. |
| Key-Person-Risk ist echtes Geld | „Nur der Founder versteht das" ist ein expliziter Abschlag, keine Fußnote. |
| Vorbereitung lässt sich nicht spät faken | Last-Minute-Doku übersteht kein Code-Review. Ein DD-ready Zustand schon. |
| Transparenz schlägt Perfektion | Bekannte, dokumentierte Schwächen sind verhandelbar; intransparente Fragilität nicht. |
Der Kernfehler: Tech-DD als Dokumentationsproblem zu sehen
Founder bereiten sich auf Due Diligence oft vor wie auf eine Klausur — Doku auf den letzten Drücker, Repositories „aufräumen", oberflächliche Fixes in der Woche, bevor der Datenraum öffnet. Das ist nicht, was Investoren bewerten, und erfahrene Prüfer durchschauen es sofort.
Technische Due Diligence beantwortet eine einzige Grundfrage: Kann dieses System wachsen, ohne Heldentum oder einen Rewrite? Alles andere — Diagramme, Wiki, README — ist nur Beleg für dieses eine Urteil. Ein poliertes Dokument über ein fragiles System hebt die Bewertung nicht. Ein klares, ehrlich dokumentiertes System mit bekannten Grenzen schon.
Deshalb ist Technical Debt ein Business-Problem, kein Dev-Problem: Im DD-Kontext wird Schuld zur Zahl im Term Sheet.
Was technische Due Diligence wirklich bewertet
Nicht Tools. Nicht Frameworks. Risiko — und zwar in fünf Kategorien: Execution Risk (könnt ihr weiter liefern?), Scaling Risk (bricht Wachstum das System?), Dependency Risk (was passiert, wenn ein Vendor die Konditionen ändert?), Security Risk (gibt es ein verstecktes Haftungsrisiko?) und Team Risk (steckt das Wissen in Köpfen oder im System?).
Alle fünf stecken bereits in Codebase, Infrastruktur und Release-Prozess — egal, ob du sie dokumentierst. Das Review macht sie nur sichtbar. Der Rest dieses Leitfadens zeigt, wo jedes davon auftaucht.
1. Architektur: Skaliert das ohne Rewrite?
Investoren ist es egal, ob ihr Monolith, Microservices oder Serverless fahrt. Sie achten auf klare Grenzen, saubere Trennung von Verantwortlichkeiten und das Fehlen versteckter Kopplungen. Ein sauber strukturierter modularer Monolith reviewt deutlich besser als ein Geflecht aus Microservices mit geteilten Datenbanken.
Die Red Flags sind über Reviews hinweg konstant: „alles spricht mit allem", kritische Business-Logik im Frontend, Regeln über Layer verteilt ohne klaren Owner, und Kern-Domains, auf die niemand klar zeigen kann. Jede signalisiert, dass Skalierung strukturelle Chirurgie braucht — und genau der Rewrite, der daraus folgt, killt Momentum und Bewertung.
Pro-Tipp: Bevor der Datenraum öffnet, zeichne dein echtes System auf eine Seite — Services, Datenspeicher, die tatsächlichen Call-Pfade. Ist das Diagramm peinlich, ist das der Befund, zu dem der Prüfer ohnehin kommt. Besser, du behebst die schlimmste Kopplung jetzt, als dass sie entdeckt wird.
2. Codebase-Gesundheit: Können neue Engineers liefern?
Das wird implizit geprüft. Der Prüfer fragt: Wie lange dauert Onboarding? Versteht jemand das System ohne den Founder im Raum? Sind Änderungen lokal — oder zieht eine Änderung Wellen durch die Codebase? Viele Prüfer verlangen ein stichprobenartiges Code-Review und lesen auf Struktur, Testabdeckung und Konsistenz, nicht auf Cleverness.
Die Red Flags sind hier so menschlich wie technisch: Tribal Knowledge, keine Tests für kritische Logik, die Angst, bestimmte Files anzufassen, und das gefürchtete „nur X kennt diesen Teil". Das ist Key-Person-Risk, und Investoren preisen ihn direkt ein — einer der häufigsten Gründe, warum ein sauber wirkender Deal Retention-Klauseln einsammelt.
3. Deployment & Releases: Kann sicher geliefert werden?
Erschreckend viele Startups deployen noch manuell, vom Laptop oder ganz ohne Rollback-Pfad. Investoren achten auf reproduzierbare CI/CD, ein Staging, das Production spiegelt, und Releases, die im Nachhinein nachvollziehbar sind.
Der Grund blickt nach vorn: Die Liefergeschwindigkeit nach dem Investment ist das, was das Geld kauft. Ist jedes Release riskant, bremst Wachstum genau dann, wenn das Team wächst. Deshalb sollten Startups früher in DevOps investieren, als sie denken — reproduzierbares Liefern ist operativer Gewinn und DD-Asset zugleich.
4. Observability: Wisst ihr wirklich, was passiert?
Logs und Dashboards sind nicht nur für Engineers. Sie beantworten Investor-Fragen direkt: Wie schnell erkennt ihr einen Incident? Könnt ihr ein Problem diagnostizieren, ohne das System abzuschalten? Ist Systemgesundheit messbar — oder anekdotisch?
Die Red Flags sind eine Abwesenheit: keine Metriken entlang von Business-Flows, kein Alerting, das Verlassen darauf, dass Nutzer melden, wenn etwas kaputt ist. Fehlende Observability liest sich als operative Blindheit — und ein Team, das sein eigenes System nicht sieht, kann nicht glaubwürdig versprechen, es zu skalieren.
5. Daten & Analytics: Fundierte Entscheidungen oder Bauchgefühl?
Investoren wollen konsistente Kennzahlen, klare Definitionen und reproduzierbare Reports. Vertrauen untergräbt: „die Zahl hängt davon ab, welches Dashboard du öffnest", unerklärte Abweichungen zwischen Quellen und Analytics, die still brechen, wenn sich Consent-Einstellungen ändern. Schlechte Analytics bremst nicht nur Wachstum — sie macht jede Management-Aussage verdächtig, weil der Prüfer nicht mehr weiß, welchen Zahlen er glauben soll.
6. Security & Compliance: Verstecktes Haftungsrisiko?
Das heißt nicht Enterprise-Security in allem. Aber geprüft werden Secrets Management, Zugriffskontrolle, Datenverarbeitung und — gerade in Europa — ein Grundverständnis von DSGVO. Hardcodete Credentials, geteilte Logins, kein Access Logging und unklare Datenflüsse sind die üblichen Befunde. DSGVO-konforme Produkte zu bauen, ohne die UX zu zerstören, ist der Maßstab; es sichtbar falsch zu machen, ist ein Haftungsrisiko, das der Käufer abgesichert haben will. Security-Probleme killen Deals selten sofort, aber sie senken deine Verhandlungsmacht und vervielfachen die daran geknüpften Bedingungen.
7. Abhängigkeiten & Vendor Risk
Jedes Startup hängt von Dritten ab. Investoren bewerten, wie kritisch jede Abhängigkeit ist, ob sie ersetzbar ist und was passiert, wenn ein Anbieter Preise oder Policy ändert. Die Red Flags sind Single-Vendor-Lock-in, undokumentierte Integrationen und keine Abstraktionsschicht um Kernservices. Dependency Risk ist zukünftiges Verhandlungsrisiko: Ein System, das die Preiserhöhung eines Vendors nicht übersteht, ist ein System, dessen Roadmap ein Dritter teilweise kontrolliert.
Der größte stille Killer: „Founder = System"
Wenn der Founder alles deployt, jeden Incident fixt und der Einzige ist, der die Architektur vollständig versteht, sehen Investoren keine Hingabe — sie sehen Execution Risk, Burnout Risk und einen Skalierungsbottleneck. Das ist kein Argument dafür, dass Founder zurücktreten. Es ist eines dafür, dass das System den Einzelnen überwachsen muss: Das Wissen gehört in Dokumentation, Tests und reproduzierbare Prozesse, nicht in einen Kopf. Dieser Übergang ist derselbe, den jedes Startup auf dem Weg vom MVP zu 100k Usern trifft.
Wie gute Vorbereitung wirklich aussieht
Starke Startups „bereiten sich" nicht im Sprint vor. Sie arbeiten in einem DD-ready Zustand: Architekturentscheidungen sind bewusst und erklärbar, Infrastruktur ist reproduzierbar, Metriken sind vertrauenswürdig, Risiken sind bekannt und aufgeschrieben. Nicht perfekt — transparent und kontrolliert.
Bevor der Prozess startet, solltest du fünf Fragen ruhig beantworten können:
- Was bricht zuerst, wenn sich der Traffic verdoppelt?
- Welche Teile des Systems sind am schwersten zu ändern?
- Wo liegen die größten operativen Risiken?
- Was würdest du in drei ungestörten Monaten refactoren?
- Welchen Metriken vertraust du voll — und welchen nicht?
Kommen diese Antworten leicht, seid ihr bereit. Kommen sie nicht, ist diese Lücke eure Vorbereitungsliste.
Meine Sicht: Due Diligence belohnt Ehrlichkeit, nicht Politur
Über die Jahre habe ich auf beiden Seiten gesessen. Was Founder am meisten überrascht, ist, wie schnell ein erfahrener Prüfer eine saubere Geschichte von einem sauberen System trennt. Man kann sich nicht aus struktureller Kopplung herausdokumentieren, und man kann ein Repository nicht zu Tests aufräumen, die es nie hatte.
Gelernt habe ich: Die Teams, die mit intakter Bewertung durch Due Diligence kommen, sind nicht die mit der hübschesten Architektur. Es sind die, die ohne Zucken sagen können: „Das ist solide, das würden wir als Nächstes fixen, und so haben wir diesen Trade-off begründet." Diese Ehrlichkeit liest sich als Kontrolle — und Kontrolle ist das, was ein Investor tatsächlich kauft.
Das fragile, intransparente System bekommt sein Risiko aggressiv eingepreist. Das verständliche, skalierbare bekommt den Vertrauensvorschuss auf seine Unvollkommenheiten. Auf dem Papier dieselbe Code-Qualität; sehr unterschiedliche Term Sheets.
— Anna
H-Studio als Partner für deine DD-Readiness
Wenn du fundraisest, M&A vorbereitest oder eine Growth-Runde planst, wird technische Due Diligence passieren. Bei H-Studio bauen wir Systeme im Wissen, dass sie geprüft werden — Annahmen hinterfragt, Abkürzungen sichtbar — daher ist das Ziel nie „perfekt", sondern erklärbar, skalierbar und prüfungsfest.
Ein Readiness-Audit kartiert Architektur- und Scaling-Risiko, DevOps- und Release-Readiness, Observability- und Analytics-Qualität sowie Security- und Dependency-Exposure — und übergibt eine priorisierte Fix-Liste mit 90-Tage-Sicht. Ein Architecture Sprint ist ein schneller, strukturierter Weg, daraus einen konkreten Plan zu machen, bevor der Datenraum öffnet.
FAQ
Was ist technische Due Diligence?
Technische Due Diligence ist die vom Investor oder Käufer geführte Prüfung der Technik eines Startups: Architektur, Codebase-Gesundheit, Infrastruktur, Release-Prozess, Security, Datenqualität und Team-Struktur. Ziel ist zu beurteilen, ob das technische Fundament Wachstum ohne Rewrite oder Heldentum trägt.
Worauf schauen Investoren zuerst?
Auf Risiko, nicht auf Tools. Sie bewerten, ob das System ohne strukturelle Rewrites skaliert, ob neue Engineers ohne den Founder produktiv werden und ob Releases, Monitoring und Security reproduzierbar und prüfbar sind.
Wie lange dauert die Vorbereitung?
In einer Woche kann man sich nicht glaubwürdig vorbereiten — Last-Minute-Doku übersteht kein Code-Review. Was funktioniert, ist, dauerhaft DD-ready zu arbeiten: bewusste Architektur, reproduzierbare Infrastruktur und dokumentierte, bekannte Risiken.
Senkt Technical Debt die Bewertung eines Startups?
Kann sie. Schuld, die zum Skalieren einen Rewrite erzwingt oder Wissen in einer Person bündelt, zeigt sich als Bewertungsabschlag, Earn-out oder Retention-Klausel. Dokumentierte, eingegrenzte Schuld ist weit weniger schädlich als versteckte, strukturelle.
Was ist Key-Person-Risk in der Due Diligence?
Key-Person-Risk ist die Gefahr, dass kritisches Wissen oder Können in einer Person steckt — meist einem Founder. Investoren preisen ihn ein, weil er Umsetzung und Kontinuität bedroht, sollte diese Person ausfallen.
Weiterführende Artikel
- Was Investoren zuerst im Tech-Stack sehen — die Signale, die den ersten Eindruck formen
- Warum Technical Debt ein Business-Problem ist — wie Schuld zur Term-Sheet-Zahl wird
- Warum Rewrites Startups töten — der Failure-Mode, den DD aufdecken soll
- Vom MVP zu 100k Usern: was sich technisch ändern muss — „Founder = System" hinter sich lassen
Lektoriert und faktengeprüft von Anna Hartung