Technische Due Diligence: Worauf Käufer und Investoren in einer SaaS-Codebasis wirklich achten

Wenn dein SaaS-Unternehmen auf eine Übernahme, ein Private-Equity-Investment oder auch nur eine Series A zusteuert, wird jemand deinen Code lesen. Nicht überfliegen. Lesen. Eine Checkliste zur technischen Due Diligence war früher eine Formalie, die Anwälte zwischen Term Sheet und Überweisung abhakten. Diese Zeit ist vorbei. Heute beauftragen Private-Equity-Firmen, strategische Käufer und zunehmend auch Frühphasen-Investoren ernsthafte technische Prüfungen, und die Ergebnisse holen regelmäßig Bewertung zurück, strukturieren Earn-outs um oder kippen Deals ganz.

Dieser Beitrag ist von der Verkäuferseite des Tisches geschrieben. Nicht "wie führe ich eine Due Diligence durch", sondern "wie überstehe ich sie", und idealerweise: wie gehst du in den Datenraum und weißt genau, was die Prüfer finden werden, weil du es zuerst gefunden hast.

Warum die technische Due Diligence zum Deal-Blocker wurde

Zwei Dinge haben sich verändert. Erstens ist Software bei den meisten SaaS-Übernahmen inzwischen das eigentliche Asset. Der Käufer erwirbt nicht deine Kundenliste oder deine Marke; er erwirbt eine Codebasis, die er über Jahre betreiben, erweitern und integrieren will. Eine Codebasis, die ein Rewrite braucht, ist kein Asset, sondern eine Verbindlichkeit mit angehängtem Abogeschäft.

Zweitens haben sich Käufer die Finger verbrannt. Jede mittelgroße PE-Firma kennt die Geschichte vom Portfoliounternehmen, dessen "moderne Plattform" sich als unwartbares Geflecht entpuppte, das zwei Jahre Engineering-Budget verschlang. Aus diesen Geschichten wurde Prozess: standardisierte Prüfrahmen, spezialisierte Due-Diligence-Firmen und Vertragsklauseln, die technisches Risiko über Escrows, Holdbacks und Kaufpreisanpassungen zurück auf den Verkäufer schieben.

Die praktische Konsequenz für dich: Technische Befunde haben heute ein Preisschild. Eine schwache Sicherheitslage oder ein einzelner unersetzlicher Entwickler macht den Käufer nicht nur nervös. Es taucht als Zahl im überarbeiteten Angebot auf.

Die Checkliste zur technischen Due Diligence: fünf Bereiche, die Prüfer immer wieder markieren

Nachdem ich in Code-Quality-Consulting-Projekten auf beiden Seiten solcher Prüfungen saß, kann ich sagen: Die Befunde clustern sich. Prüfer der etablierten Due-Diligence-Firmen arbeiten mit ähnlichen Rahmenwerken, und dieselben fünf Bereiche erzeugen den Großteil der roten Flaggen.

1. Architektur-Schulden

Prüfer suchen keine modische Architektur. Sie prüfen, ob die Architektur den Wachstumsplan des Käufers verkraftet. Die Fragen hinter den Fragen:

• Kann dieses System auf die fünffache Last skalieren, ohne neu geschrieben zu werden?
• Wie stark sind die Module gekoppelt? Kann ein neues Team ein Feature liefern, ohne das ganze System zu verstehen?
• Gibt es Komponenten, die niemand anzufassen wagt?

Wie ein Befund in der Praxis aussieht: eine "Microservices-Architektur", die tatsächlich ein verteilter Monolith ist, in dem jeder Service dieselben Datenbanktabellen liest. Oder ein zentrales Billing-Modul, das zuletzt vor vier Jahren nennenswert geändert wurde und in Schichten von Workarounds eingewickelt ist, weil sich niemand herantraut. Prüfer finden das schnell, weil sie Entwickler interviewen und fragen: "Welchen Teil des Systems würdest du am ungernsten ändern?" Entwickler antworten ehrlich. Immer.

2. Sicherheitslage

Das ist der Bereich, der am ehesten einen dealgefährdenden Befund produziert, weil Sicherheitsprobleme rechtliche Risiken schaffen, die der Käufer erbt. Prüfer kontrollieren:

• Muster für Authentifizierung und Autorisierung, besonders die Mandantentrennung in Multi-Tenant-Systemen
• Secrets-Management: Zugangsdaten in der Repository-Historie sind ein Klassiker und bedrückend häufig
• Abhängigkeiten mit bekannten CVEs, die ungepatcht herumliegen
• Ob es je einen Penetrationstest gab und was mit dessen Befunden geschah

Die Befunde, die wehtun, sind selten exotisch. Es sind Dinge wie ein Admin-Endpunkt, der nur durch eine unbekannte URL geschützt ist, API-Keys, die 2021 committet und nie rotiert wurden, oder mandantenübergreifender Datenzugriff durch Ändern einer ID im Request. Jedes einzelne davon kann einen Holdback auslösen, bis die Behebung verifiziert ist.

3. Qualität der Testabdeckung

Beachte das Wort Qualität. Prüfer trauen Coverage-Prozenten schon seit Jahren nicht mehr, und mit dem Aufkommen KI-generierter Testsuiten sind rohe Coverage-Zahlen nahezu bedeutungslos geworden. Eine Codebasis kann 85 Prozent Line Coverage zeigen, bei der die Hälfte der Tests nichts weiter behauptet als "die Funktion hat nicht geworfen".

Was Prüfer tatsächlich tun: Sie lesen eine Stichprobe von Tests für die geschäftskritischen Pfade, also Billing, Berechtigungen, Datenexport, und prüfen, ob die Assertions eine echte Regression fangen würden. Sie schauen, ob Tests bei jeder Änderung in der CI laufen, wie lange die Suite braucht und wie oft sie übersprungen wird. Sie bitten unter Umständen einen Entwickler, absichtlich etwas kaputt zu machen, und schauen, ob die Suite es bemerkt.

Ein Befund hier kippt selten allein einen Deal, aber er verstärkt jeden anderen Befund. Schwache Tests bedeuten, dass der Käufer den Code, den er kauft, nicht sicher ändern kann, und damit wird jede geplante Integration zur Risikoposition.

4. Abhängigkeitsrisiko

Jede externe Abhängigkeit ist ein kleiner Vertrag mit einem Fremden, und Prüfer auditieren diese Verträge:

• Frameworks und Runtimes nach dem End-of-Life (eine EOL-PHP- oder Node-Version ist ein automatischer Befund)
• Kritische Bibliotheken, die verwaist sind oder von einer einzigen Person gepflegt werden
• Lizenz-Compliance: eine GPL-Abhängigkeit in einem proprietären SaaS-Produkt ist ein juristischer Befund, kein technischer, und Anwälte mischen sich ein
• Drittanbieter-Dienste, ohne die das Produkt nicht funktioniert, und wie die Verträge dazu aussehen

Veraltete Plattformversionen verdienen besondere Erwähnung, weil sie sich aufaddieren. Drei Major-Versionen hinter deinem Framework zu liegen heißt: Sicherheitspatches sind nicht verfügbar, Recruiting wird schwerer, und jede Modernisierungsschätzung des Käufers bekommt einen Aufschlag. Wenn das deine Situation ist, ist eine strukturierte Legacy-Code-Modernisierung vor dem Gang an den Markt einer der Schritte mit dem höchsten ROI.

5. Bus-Faktor des Teams

Der am meisten unterschätzte Bereich und derjenige, den Gründer am wenigsten kurzfristig reparieren können. Prüfer fragen: Wenn eine bestimmte Person am Tag nach dem Closing das Unternehmen verließe, könnte das verbleibende Team das System betreiben und weiterentwickeln? In viel zu vielen SaaS-Unternehmen lautet die ehrliche Antwort nein. Ein Entwickler hält den Deployment-Prozess, das Erfahrungswissen über die Billing-Sonderfälle und das einzige echte Verständnis des Kern-Domänenmodells, alles im Kopf.

Prüfer erkennen das über Interviews und über die Commit-Historie, die nicht lügt. Wenn 70 Prozent der Commits am Kernsystem von einer Person kommen, ist diese Person ein Single Point of Failure, und der Käufer bepreist das Risiko, sie zu verlieren. Dokumentation, Onboarding-Runbooks und bewusst gestreutes Wissen in den Monaten vor einem Deal verändern diesen Befund messbar.

Bewerte deine Codebasis, bevor es ein Käufer tut

Das Wertvollste, was du vor dem Start eines Prozesses tun kannst, ist eine ehrliche interne Bewertung nach denselben Kriterien. Keine Motivationsrede. Eine bewertete Prüfung mit Belegen, so wie wir es in unserem Ansatz zur Codebase Health Scorecard beschreiben.

Stelle für jeden der fünf Bereiche drei Fragen:

1. Was würde ein skeptischer externer Prüfer in den ersten zwei Tagen finden?
2. Was würden Entwickler im Interview sagen, wenn man sie fragt, was ihnen Sorgen macht?
3. Welche Belege existieren, um die Sorge zu entkräften: Tests, Dokumentation, Monitoring, Audit-Trails?

Bewerte jeden Bereich rot, gelb oder grün, und sei dabei schonungslos. Eine Selbstbewertung, die durchgehend grün zurückkommt, war nicht ehrlich. Jede echte Codebasis trägt Schulden; Käufer wissen das, und Prüfer werden misstrauisch, wenn ein Verkäufer etwas anderes behauptet. Ziel ist nicht Perfektion. Ziel ist, dass dich nichts im späteren Bericht überrascht.

Wenn du eine externe Kalibrierung willst: Ein fokussiertes Pre-Diligence-Audit durch Dritte ist dramatisch günstiger als der Bewertungsabschlag durch einen unerwarteten Befund. Es erzeugt außerdem etwas Wertvolles: einen schriftlichen Nachweis, dass Probleme erkannt und Behebungen bereits angestoßen waren, bevor der Käufer auftauchte.

Der Behebungszeitplan, den Käufer glaubwürdig finden

Wie du über die Behebung bekannter Probleme sprichst, zählt genauso viel wie die Probleme selbst. Käufer haben feine Sensoren für zwei Fehlermuster.

Das erste ist der Wunderzeitplan. "Wir migrieren in sechs Wochen weg vom EOL-Framework" liest sich entweder als Unehrlichkeit oder als Naivität, und beides beschädigt das Vertrauen in alles andere, was du gesagt hast. Framework-Migrationen, nachträgliche Mandantentrennung und der Neuaufbau von Testsuiten sind Aufgaben im Quartalsmaßstab, und erfahrene Prüfer kennen die realen Zahlen.

Das zweite ist das ewige Backlog. Themen, die seit zwei Jahren "auf der Roadmap" stehen, ohne dass ein einziger Commit dazu existiert, sind keine geplante Arbeit, sondern akzeptierter Verfall. Ein Backlog-Ticket ist keine Behebung.

Was gut ankommt, ist konkret und bereits in Bewegung: ein schriftlicher Plan pro Befund, ein Verantwortlicher, ein realistischer Zeitrahmen auf Quartalsebene und Belege, dass die Arbeit begonnen hat, etwa gemergte Pull Requests, ein Migrationsleitfaden, ein abgeschlossener Proof of Concept. "Wir haben das in unserer internen Prüfung in Q1 erkannt, hier ist der Plan, hier sind die ersten drei gemergten Änderungen" ist der stärkste Satz, den ein Verkäufer in einem Due-Diligence-Interview sagen kann.

Lege bekannte Probleme proaktiv offen

Der Instinkt von Gründern ist zu hoffen, dass Prüfer Dinge übersehen. Werden sie nicht. Ein kompetentes Team findet mit zwei Wochen und Datenraumzugang praktisch alles Wesentliche. Was du steuerst, ist, ob jedes Problem von dir eingeordnet oder von ihnen entdeckt wird.

Offengelegte Probleme lesen sich als Engineering-Reife. Entdeckte Probleme lesen sich als Unwissenheit oder Vertuschung, und beides ist schlimmer als das Problem selbst. Der praktische Schritt ist ein kurzes Dokument "bekannte technische Schulden" im Datenraum: jedes wesentliche Problem, seine geschäftliche Auswirkung und der Stand der Behebung. Dieses Dokument tut mehr für das Vertrauen des Käufers als jede Politur, weil es signalisiert, dass das Team sein eigenes System klar sieht. Es hängt auch daran, wie du intern über Schulden sprichst: Wenn du bereits technische Schulden an nicht-technische Stakeholder vermitteln kannst, schreibst du dieses Dokument an einem Nachmittag.

Eine Selbstbewertungs-Checkliste für dieses Quartal

Verdichtet auf die Prüfungen, die dem entsprechen, was Due-Diligence-Firmen im EU-Markt tatsächlich bewerten:

• Architektur: Kannst du das System in zehn Minuten auf ein Whiteboard zeichnen? Passen Modulgrenzen zu Teamgrenzen? Gibt es eine Komponente, die niemand anfasst?
• Sicherheit: Secrets aus dem Repo entfernt und rotiert? Mandantentrennung getestet, nicht angenommen? Dependency-Scanning in der CI? Ein Pentest in den letzten 18 Monaten mit geschlossenen Befunden?
• Tests: Prüfen Tests zu Billing und Berechtigungen echtes Verhalten? Blockiert die CI Merges bei Fehlschlägen? Würde ein absichtlich eingebauter Bug gefangen?
• Abhängigkeiten: Alle Runtimes und Frameworks innerhalb der Supportfenster? Lizenzinventar gegen dein Geschäftsmodell geprüft? Keine kritischen Ein-Personen-Bibliotheken ohne Ausweichplan?
• Team: Würde jedes kritische System eine bestimmte Kündigung überstehen? Existieren Runbooks und stimmen sie mit der Realität überein? Ist Wissen über die Kerndomäne auf mindestens zwei Personen verteilt?

Alles, was du nicht souverän beantworten kannst, wird ein Prüfer finden. Besser jetzt wissen, solange es ein Arbeitspaket ist und kein Verhandlungspunkt.

Komm der Prüfung zuvor

Technische Due Diligence belohnt Vorbereitung stärker als fast jeder andere Teil eines Deal-Prozesses. Die Befunde sind vorhersehbar, die Rahmenwerke sind konsistent, und nahezu jede bewertungsschädigende Entdeckung hätte Monate früher gefunden und behoben oder zumindest ehrlich offengelegt werden können.

Wenn eine Transaktion an deinem Horizont steht, führe die Selbstbewertung oben in diesem Quartal durch. Und wenn du eine externe, belegbasierte Prüfung willst, bevor ein Käufer seine beauftragt: Genau das ist unsere Arbeit bei Wolf-Tech. Unabhängige Codebasis-Audits, kalibriert auf das, was Käufer und Investoren wirklich prüfen. Melde dich unter hello@wolf-tech.io oder besuche wolf-tech.io, um darüber zu sprechen.