Was Investoren in deinem Tech Stack wirklich sehen (Startup Tech DD)

Founder bereiten sich auf Investorengespräche vor, indem sie den Pitch schärfen, die Roadmap polieren und die KPIs erklären. Der Tech Stack bekommt einen einzigen Satz — „wir nutzen moderne Technologien" — und der Founder geht weiter, ein wenig erleichtert. Investoren nicken und schauen dann woanders hin. Denn erfahrene Investoren bewerten einen Stack nicht nach seinen Marken-Namen. Sie lesen ihn als Risikokarte. Die konkreten Frameworks registrieren sie kaum; was zählt, ist das, was diese Entscheidungen darüber verraten, wie sich das Unternehmen unter Wachstum, Druck und Prüfung verhalten wird. In diesem Artikel geht es darum, was sie wirklich lesen — und wie du dafür sorgst, dass dein Stack die Geschichte erzählt, die du willst, bevor du ein Wort gesagt hast.

Die wichtigsten Erkenntnisse

Die zentrale Realität: dein Stack wird als Risikokarte gelesen

Es hilft, zuerst die Mechanik zu verstehen, denn sie prägt alles. Wenn ein Deal ernst wird — eine bepreiste Runde, eine Growth-Runde oder eine Übernahme — wird die Technologie wirklich geprüft. Eine echte technische Due Diligence ist kein kurzer Blick auf dein GitHub. Sie ist typischerweise ein zwei- bis vierwöchiger, Engineer-geführter Review, in dem Menschen, die tatsächlich Code lesen können, deine Architektur, Code-Qualität, Security, Skalierbarkeit, Team-Praktiken, Dokumentation und Infrastruktur bewerten — und all das in eine Sache übersetzen: eine Risikobewertung im Kontext der Transaktion. Das Ergebnis ist keine Liste von Bugs. Es ist ein Urteil darüber, wie sehr der Käufer oder Investor dem System vertrauen sollte — und dieses Urteil fließt direkt in die Konditionen ein.

Für einen Investor beantwortet dein Stack also Fragen, von denen du vielleicht nicht weißt, dass sie gestellt werden: Wie schnell kann dieses Unternehmen nächstes Jahr liefern? Wie fragil ist die Execution unter Druck? Wie teuer wird Skalierung — in Infrastruktur und Engineering-Zeit? Wie abhängig ist das Ganze von zwei oder drei bestimmten Personen? Und wie schwer wäre Integration, Übernahme oder Austausch? Frameworks sind Details. Diese Signale sind alles. Die sieben, die folgen, sind aus meiner Erfahrung beim Durchführen und Vorbereiten solcher Reviews die, die den Ausschlag geben.

Signal #1 — Architektur-Disziplin (oder ihr Fehlen)

Das Erste, was ein Reviewer ableitet, ist nicht was du nutzt, sondern wie du es nutzt. Gesucht werden klare Trennung von Verantwortlichkeiten, Systemgrenzen, die ein Neuling versteht, und das Fehlen des gefürchteten „alles spricht mit allem". Eine saubere Architektur sagt: Das Team kann das System durchdenken — und das heißt, es kann es sicher verändern.

Die Red Flags sind genauso lesbar: Business-Logik ins Frontend geschmiert, ad-hoc-Integrationen überall dort verdrahtet, wo es gerade bequem war, kein erkennbarer Core Domain. Keins davon ist für sich genommen ein Verbrechen. Zusammen signalisieren sie Rewrite-Risiko — der teuerste Satz in jedem Diligence-Bericht, denn ein Rewrite bedeutet Monate an Geschwindigkeit, in denen man auf der Stelle tritt. Ein Monolith, das sei klar gesagt, ist keine Red Flag; ein gut strukturierter modularer Monolith ist für ein frühes Team oft die klügste Wahl. Bestraft wird nicht die Form, sondern die Verflechtung. Die Frage, die der Reviewer eigentlich beantwortet, lautet: Wenn wir eine Sache ändern müssen, wie viel vom System müssen wir vorher verstehen?

Signal #2 — Deployment- und Release-Reife

Investoren stellen trügerisch einfache Fragen: Wie deployt ihr? Wie oft released ihr? Wie macht ihr Rollback, wenn etwas kaputtgeht? Sie plaudern nicht. Sie prüfen Execution-Zuverlässigkeit und operatives Risiko — und es gibt eine etablierte Art, das zu messen. Das DORA-Forschungsprogramm — der meistzitierte Wissensstand zu Software-Delivery-Performance — reduziert das auf vier Kennzahlen: Deployment-Frequenz, Lead Time für Änderungen, Change Failure Rate und Time to Restore Service. Du musst diese Zahlen nicht aufsagen, aber ein Team, das on demand deployt, kleine Änderungen schnell ausliefert, selten Produktion kaputt macht und schnell wiederherstellt, ist nachweislich ein risikoarmes Team.

Das gegenteilige Profil — manuelle Deploys, Releases, für die ein bestimmter Engineer lange bleiben muss, kein sauberer Rollback-Pfad — sendet eine präzise Botschaft: Wachstum wird das Team verlangsamen. Jeder neue Kunde, jeder neue Engineer, jeder Incident fügt einem ohnehin heroischen Prozess Reibung hinzu. Heldentum skaliert nicht, und Investoren wissen das. Das ist eins der wenigen Signale, das sich fast mechanisch in die Bewertung übersetzt, denn es ist ein direkter Proxy dafür, wie zuverlässig das Team liefern kann, was die Roadmap verspricht.

Pro-Tipp: Schreib dir vor jedem Investorengespräch deine vier DORA-Zahlen auf — Deployment-Frequenz, Lead Time, Change Failure Rate, Time to Restore. Selbst grobe Werte signalisieren, dass du Delivery misst; ein leerer Blick signalisiert das Gegenteil.

Signal #3 — Observability und operatives Bewusstsein

Die nächste Frage ist, ob das Team mit offenen Augen arbeitet. Wie schnell werden Probleme erkannt? Wie werden Incidents diagnostiziert? Überraschen Probleme das Team, oder sieht das Team sie kommen? Ein Reviewer achtet auf Metriken entlang echter Business-Flows, Error Tracking, das über das Lesen von Konsolen-Logs hinausgeht, und mindestens grundlegendes Alerting. Die reife Variante davon sind die SRE „Golden Signals" — Latenz, Traffic, Errors und Saturation — so instrumentiert, dass das Team von einer Verschlechterung erfährt, bevor die Kunden es tun.

Das Fehlen von Observability ist keine neutrale Lücke; es ist verstecktes Downside-Risiko. Ein Team im Blindflug kann dir nicht sagen, wie nah es an einer Kapazitätsgrenze ist, kann Zuverlässigkeit nicht quantifizieren und kann keine ehrliche Antwort geben, wenn die Engineers eines Käufers fragen: „Wie ist eure p95-Latenz unter Last?" Blindflug bedeutet, dass die schlechten Nachrichten alle auf einmal kommen, meist zum schlechtesten Zeitpunkt — und Investoren bepreisen das, was sie nicht sehen können.

Signal #4 — Abhängigkeiten und Vendor-Risiko

Jeder Stack ruht auf Abhängigkeiten — Open-Source-Libraries, Managed Services, Third-Party-APIs. Reviewer bewerten, wie kritisch jede einzelne ist, ob es brauchbare Alternativen gibt und wie schmerzhaft ein Austausch wäre. Die Red Flags sind Single-Vendor-Lock-in im Kern des Produkts, undokumentierte Third-Party-Logik, die niemand im Team vollständig versteht, und das leise „wir hängen für alles an X".

Das zählt mehr, als Founder erwarten, und es zählt am meisten in genau den Momenten, die das Upside eines Unternehmens bestimmen: M&A (ein Käufer, der eine kritische Abhängigkeit von der API eines Wettbewerbers oder einem Vendor mit Preismacht erbt, wird entsprechend abwerten), Enterprise Sales (Einkaufsabteilungen fragen nach Sub-Prozessoren und Kontinuität) und regulierte Umgebungen (wo eine undokumentierte Abhängigkeit in einem Datenpfad ein Compliance-Problem ist, nicht nur ein Engineering-Problem). Die tiefere Frage ist Kontrolle: Wie viel deines Schicksals liegt in fremden Händen, und weißt du wo? Reife Teams können das zunehmend konkret beantworten — sie kennen ihren Dependency-Tree, halten ihn aktuell und haben eine Geschichte für die wenigen Abhängigkeiten, deren Austausch wirklich wehtäte.

Pro-Tipp: Halte eine einseitige Dependency-Karte der wenigen Dienste bereit, deren Austausch wirklich schmerzhaft wäre, mit einem Satz zum Fallback für jeden. Das einem Reviewer in die Hand zu geben, verwandelt eine vage Sorge in ein kontrolliertes, dokumentiertes Risiko.

Signal #5 — Security-Haltung (ohne Enterprise-Theater)

Investoren sind hier realistisch. In der Seed- oder selbst Series-A-Phase erwartet niemand perfekte Security oder eine Wand aus ISO-Zertifikaten — das wäre tatsächlich eine gelbe Flagge, ein Zeichen, dass Aufwand in Optik statt ins Produkt geflossen ist. Erwartet wird grundlegende Hygiene, die zeigt, dass das Team Haftung ernst nimmt: echtes Secrets Management (keine API-Keys im Repo), Disziplin bei Zugriffsrechten und echtes Bewusstsein dafür, wo personenbezogene und sensible Daten fließen.

Die Red Flags sind die, die eine Kultur offenlegen, nicht nur eine Lücke: geteilte Credentials, Produktionszugriff für alle und der Satz „Security machen wir später". Jedes signalisiert latentes Haftungsrisiko — ein Breach, der nur darauf wartet zu passieren, und gerade in europäischen Deals ein DSGVO-Risiko, das ein Diligence-Team fett markiert. Die Messlatte ist nicht Raffinesse. Es ist Ernsthaftigkeit. Ein kleines Team, das erkennbar über Secrets, Zugriff und Datenflüsse nachgedacht hat, wirkt deutlich risikoärmer als ein größeres, das das nicht getan hat.

Signal #6 — Team–Stack-Fit

Das ist eines der stärksten und leisesten Signale, und hier verlieren viele technisch beeindruckende Unternehmen Punkte. Der Reviewer fragt: Kann dieses Team diesen Stack realistisch warten? Ist das System über den Kopf einer einzelnen Person hinaus verständlich? Wie schwer ist es, Leute einzustellen, die in diesem Setup arbeiten können? Eine clevere, exotische Architektur, die genau ein Founder versteht, ist kein Asset — sie ist eine Risikokonzentration.

Der Fachbegriff, der hier über allem schwebt, ist Key-Person-Risk, manchmal unverblümt „Bus-Faktor" genannt: Wie viele Personen müssten verschwinden, bevor das System unwartbar wird? Ist die Antwort eins, wird jede andere Stärke auf der Liste untergraben, denn die Fähigkeit des Unternehmens zu liefern ist Geisel der fortgesetzten Anwesenheit und des Wohlwollens einer einzelnen Person. Exotik um ihrer selbst willen, dünne Dokumentation und eine eng an die Eigenheiten eines Founders gekoppelte Architektur drücken den Bus-Faktor allesamt Richtung eins. Langweilige, gut dokumentierte, weit verbreitete Technologie, in die das Team einstellen kann, ist paradoxerweise das, was anspruchsvolle Investoren spannend finden — denn sie bedeutet, dass Headcount tatsächlich zu Kapazität werden kann.

Pro-Tipp: Mach einen schnellen Bus-Faktor-Test an deinem eigenen System: Benenne für jeden kritischen Bereich die zweite Person, die ihn warten könnte. Jeder Bereich, der nur einen Namen zurückgibt, ist ein Risiko, das du beheben kannst, bevor ein Reviewer es findet.

Signal #7 — Skalierung bedeutet „können wir Menschen hinzufügen?"

Founder hören „Skalierbarkeit" und denken an Traffic. Investoren meinen meist etwas ganz anderes: Kann dieses Unternehmen Engineers einstellen, ohne langsamer zu werden? Die zehnfache Last zu bewältigen ist ein lösbares Infrastrukturproblem. Das dreifache Team zu bewältigen, ohne im Koordinationschaos zu versinken, ist ein Architektur- und Organisationsproblem — und es entscheidet, ob eine Finanzierungsrunde tatsächlich Geschwindigkeit kauft.

Reviewer suchen nach klaren Ownership-Bereichen, vorhersehbarem Onboarding (wie lange, bis eine neue Person etwas Echtes ausliefert?) und der Fähigkeit, lokale Änderungen vorzunehmen, ohne das gesamte System zu verstehen. Der Failure-Mode ist die Codebase, in der jede Änderung globales Verständnis erfordert — dort fügt jeder neue Engineer schneller Kommunikations-Overhead als Output hinzu, und Headcount übersetzt sich nicht mehr in Fortschritt. Das ist dieselbe Separation-of-Concerns-Disziplin aus Signal #1, durch eine organisatorische Brille betrachtet: gut abgegrenzte Systeme lassen Teams parallel arbeiten; verflochtene zwingen alle durch denselben Flaschenhals.

Was Investoren deutlich weniger interessiert, als Founder glauben

Manches, worüber Founder grübeln, steht überraschend weit unten auf der Liste. Ob du React oder Vue nutzt. Ob du auf der allerneuesten Version von allem bist. Ob du Microservices eingeführt hast. Diese Dinge sind für sich genommen nahezu neutral — sie zählen nur, wenn sie echte Reibung bei Risiko, Kosten oder Geschwindigkeit erzeugen. Microservices, die ein Fünf-Personen-Team verfrüht einführt, sind ein Minus, kein Plus, weil sie operativen Overhead vervielfachen, den das Team noch nicht tragen kann. Ein älteres-aber-unterstütztes Framework ist in Ordnung; ein nicht mehr unterstütztes (eine Sprachversion ohne Security-Patches) ist ein echtes Problem, weil es eine baldige, teure Migration und eine Sicherheitslücke impliziert. Die Lektion: Technologieentscheidungen sind neutral, bis sie Reibung erzeugen. Der Reviewer benotet nicht deinen Geschmack. Er bepreist dein Risiko.

Die reale Investor-Heuristik (sehr verbreitet)

Bei aller Struktur eines formellen Reviews komprimieren erfahrene Investoren den gesamten Stack bemerkenswert früh auf einen einzigen Satz:

• „Sauber, gut skalierbar."
• „Funktioniert, braucht aber Refactoring."
• „Wird sie verlangsamen."
• „Rewrite-Risiko."

Dieser Satz ist nicht belanglos. Er prägt Deal-Konditionen, Bewertung, die ans Geld geknüpften Bedingungen und — oft am folgenreichsten — die Bereitschaft für die nächste Runde. Und er entsteht schneller, als die meisten Founder denken, häufig in der ersten Stunde unter der Motorhaube, bevor ein tiefer Audit ihn bestätigt oder revidiert. Ein großer Teil der Diligence-Vorbereitung besteht darin, dafür zu sorgen, dass der erste Eindruck und der tiefe Befund am selben Punkt landen.

Wie kluge Founder das Narrativ kontrollieren

Hier kommt der kontraintuitive Teil: Starke Founder verteidigen ihren Stack nicht. Sie erklären ihre Trade-offs. Das Beruhigendste, was ein Founder in einem technischen Gespräch tun kann, ist zu zeigen, dass die Architektur das Ergebnis bewusster Entscheidungen und nicht von Zufällen ist — klar zu sagen, was sie früh optimiert haben, was sie bewusst aufgeschoben haben und warum, was sie als Nächstes ändern würden und wo die echten Risiken aktuell liegen.

Das funktioniert, weil es die Dynamik umdreht. Ein Founder, der seine eigene Technical Debt benennen und die dahinterstehende Logik erklären kann, wirkt wie jemand, der das System im Griff hat. Ein Founder, der darauf besteht, dass alles in Ordnung ist, oder defensiv wird, wenn eine Entscheidung hinterfragt wird, wirkt wie jemand, der die Risiken entweder nicht sieht oder verbirgt — und ein Reviewer wird Letzteres annehmen. Transparenz schafft Vertrauen; Defensivität zerstört es. Das Ziel der Vorbereitung ist kein makelloser Stack (die gibt es nicht). Es ist ein Stack, dessen Schwächen du artikulieren kannst, bevor jemand anderes sie findet.

Was ich beim Vorbereiten von Foundern auf Due Diligence gelernt habe

Über die Jahre habe ich auf beiden Seiten dieser Reviews gesessen, und das Muster ändert sich fast nie. Die Founder, die mit intakter Bewertung aus der Diligence kommen, sind nicht die mit der cleversten Architektur — es sind die, die schon hereinkamen und wussten, wo ihre eigenen Leichen vergraben liegen. Sie konnten auf die Abkürzung im ersten Jahr zeigen, genau erklären, warum sie damals Sinn ergab, und die Zeile auf der Roadmap zeigen, in der sie geplant hatten, sie zurückzuzahlen. Nichts entspannt einen skeptischen Reviewer schneller als ein Founder, der die Schwachstelle vor ihm findet.

Die schmerzhaften Fälle sind das Spiegelbild: ein wirklich gutes Produkt, untergraben von einem Stack, den nur eine Person verstand, oder ein Deployment-Prozess, der vom Muskelgedächtnis eines einzelnen Engineers abhing. Nichts davon ist ein Produktproblem. Es ist ein Erzählproblem — Risiko, das real, aber unsichtbar war und sich deshalb nur als Worst Case bepreisen ließ. Investoren bestrafen keine Ehrlichkeit über Schulden; sie bestrafen das Entdecken von Schulden, von denen der Founder offenbar nichts wusste.

Mein Rat ist deshalb derselbe, den ich vor jedem Raise gebe: Der Stack, auf den du stolz bist, und der Stack, der den Deal gewinnt, sind nicht immer derselbe. Der zweite ist meist ruhiger, langweiliger und deutlich leichter zu erklären. Bau für den Moment, in dem jemand unter die Motorhaube schaut — denn irgendwann wird das jemand tun.

— Anna

Vorbereitung auf Investorenprüfung mit H-Studio

Wenn du fundraisest, dich M&A näherst oder eine Growth-Runde vorbereitest, bewerten Investoren deinen Tech Stack nach Risiko-Signalen, nicht nach Marken-Namen — und diese Vorbereitung gelingt am besten Monate, bevor der Datenraum öffnet, nicht in der Woche davor. Bei H-Studio entwerfen wir Systeme mit der Annahme, dass irgendwann jemand unter die Motorhaube schaut: erklärbare Architektur, vorhersagbare Execution und kontrolliertes, sichtbares Risiko sind die Dinge, die einen zweiwöchigen, Engineer-geführten Review überstehen und ihn von einer Bedrohung in einen Vorteil verwandeln.

Wir helfen Foundern und wachsenden Unternehmen, über den gesamten Stack diligence-fähig zu werden. Sieh dir unsere Engineering-Leistungen an, oder geh direkt zu den Bereichen, die Reviewer am härtesten prüfen: für klare Grenzen und saubere Trennung die Backend-Architektur; für Deployment, Rollback und Release-Reife das DevOps & Cloud Engineering; und für Metriken entlang echter Business-Flows das Data Engineering & Analytics. Wenn ein Finanzierungsgespräch am Horizont steht, melde dich — wir stellen deinen Stack auf die Probe, bevor ein Investor es tut.

FAQ

Was ist technische Due Diligence, und wie lange dauert sie?

Sie ist eine systematische Bewertung der technischen Gesundheit eines Unternehmens — Architektur, Code-Qualität, Security, Skalierbarkeit, Team, Dokumentation, Infrastruktur — erstellt als Risikobewertung für einen konkreten Deal. Eine gründliche Due Diligence dauert typischerweise zwei bis vier Wochen und wird von Engineers geführt, die den Code wirklich lesen und Praktiken bewerten können, nicht nur Folien sichten.

Worauf achten Investoren als größte Red Flags im Tech Stack?

Die wiederkehrenden: keine automatisierten Tests, eine verflochtene Architektur, die Rewrite-Risiko impliziert, manuelle oder heroische Deployments, keine Observability, Single-Vendor-Lock-in im Kern, schwache Security-Hygiene (geteilte Credentials, Secrets im Repo) und ein Bus-Faktor von eins. Die meisten davon drehen sich um Risiko und Wartbarkeit, nicht darum, welches Framework du gewählt hast.

Beeinflusst meine Framework-Wahl tatsächlich die Bewertung?

Selten für sich allein. React vs. Vue oder Monolith vs. Microservices ist nahezu neutral — es beeinflusst die Bewertung nur, wenn es echte Reibung bei Kosten, Geschwindigkeit oder Risiko erzeugt. Eine nicht mehr unterstützte Framework-Version ist eine Ausnahme, weil sie eine teure Migration und eine Sicherheitslücke impliziert.

Wie sollte ein Founder mit Investoren über Technical Debt sprechen?

Benenne sie, bevor sie sie finden. Erkläre, was du früh optimiert, was du bewusst aufgeschoben und was du als Nächstes beheben würdest. Ein Founder, der seine eigenen Trade-offs artikulieren kann, wirkt souverän; Defensivität wirkt entweder wie Blindheit oder wie Verschleierung.

Was ist der schnellste Weg, das wahrgenommene Risiko zu senken?

Mach das System erklärbar und senke Key-Person-Risk: Dokumentation, aus der eine neue Person onboarden kann, klare Ownership-Grenzen und mindestens eine weitere Person, die jeden kritischen Bereich versteht. Kombiniert mit grundlegender Deployment- und Observability-Disziplin bewegen sich die meisten der sieben Signale auf einmal zu deinen Gunsten.