Pre-Exit Readiness: So bereiten Sie ein Portfoliounternehmen in 90 Tagen auf die technische Due Diligence des Käufers vor

Das Wichtigste in Kürze Bei den meisten Exits erkennt das technische Due-Diligence-Team des Käufers innerhalb weniger Tage, womit der Verkäufer seit Jahren lebt: fragile Module, ungepatchte Schwachstellen, fehlende Dokumentation und einige wenige Personen, die das gesamte System im Kopf haben. Tauchen solche Befunde spät im Prozess auf, scheitert der Deal zwar selten, kostet aber fast immer Geld: in Form von Kaufpreisabschlägen, zusätzlichen Freistellungen oder Treuhandeinbehalten. Ein strukturiertes 90-Tage-Programm kehrt diese Dynamik um. Es verschafft dem Verkäufer eine ehrliche Ausgangslage, behebt die Punkte, die den Unternehmenswert tatsächlich beeinflussen, dokumentiert jene, die sich nicht rechtzeitig beheben lassen, und bereitet die Technologie-Story auf, bevor der Käufer sie schreibt. Dieser Beitrag zeigt, was Käufer prüfen, wie Sie die 90 Tage strukturieren und welche Fehler Sie vermeiden sollten.

Warum Verkäufer in der technischen Due Diligence Wert verlieren

Die technische Due Diligence auf Käuferseite ist darauf ausgelegt, Gründe für eine Anpassung des Kaufpreises zu finden. Das ist kein Zynismus, sondern ihre Aufgabe. Jedes nicht dokumentierte Risiko wird zum Verhandlungsargument, und es taucht meist im ungünstigsten Moment auf: während der Exklusivitätsphase, wenn der Verkäufer wenig Verhandlungsspielraum und kaum Zeit für eine Reaktion hat.

Der Wertverlust folgt dabei meist einem bekannten Muster:

• Späte Entdeckung. Drei Wochen vor dem Signing wird eine kritische Schwachstelle oder eine Copyleft-Lizenz in einem Kernmodul gefunden. Für eine Behebung fehlt die Zeit, also preist der Käufer das Risiko ein, oft großzügig.
• Unsicherheitsabschlag. Fehlt die Dokumentation, kann der Käufer nicht überprüfen, was gut funktioniert. Nicht überprüfbare Stärken werden wie Risiken behandelt.
• Abhängigkeit von Schlüsselpersonen. Verstehen nur ein oder zwei Entwickler kritische Teile des Systems, verlangt der Käufer Halteprämien, Earn-outs oder einen niedrigeren Preis.
• Widersprüchliche Aussagen. Der CTO sagt in der Managementpräsentation das eine, im Datenraum steht etwas anderes, und ein Entwickler sagt im Interview etwas Drittes. Widersprüche untergraben das Vertrauen schneller als jeder einzelne Befund.

Das eigentliche Problem ist eine Informationsasymmetrie in die falsche Richtung. Die Berater des Käufers haben am Ende oft ein klareres Bild der Technologie als der Beirat oder die Gesellschafter des Verkäufers. Genau hier setzt Pre-Exit Readiness an.

Was Käufer tatsächlich prüfen

Die meisten technischen Due-Diligence-Prüfungen auf Käuferseite, ob durch einen Private-Equity-Fonds, einen strategischen Investor oder deren Berater, decken ähnliche Bereiche ab. Wer sie im Voraus kennt, hat die halbe Vorbereitung bereits erledigt.

Architektur und Skalierbarkeit. Trägt die Plattform den Wachstumsplan aus dem Investment Case des Käufers, oder ist ein teurer Neubau nötig?

Codequalität und technische Schulden. Wie wartbar ist die Codebasis, wie viel davon ist durch automatisierte Tests abgedeckt und wo liegen die Brennpunkte, die die Entwicklung bremsen?

Sicherheit und Compliance. Offene Schwachstellen, Ergebnisse von Penetrationstests, Secrets Management, Zugriffskontrolle, Incident Response sowie Zertifizierungen wie ISO 27001, in der Automobilzulieferindustrie auch TISAX. Hinzu kommen die DSGVO und für viele Unternehmen die Anforderungen aus NIS2 und ihrer nationalen Umsetzung.

Geistiges Eigentum und Open Source. Lizenzrisiken in Abhängigkeiten und eine lückenlose Rechtekette für Code, den Angestellte und externe Auftragnehmer geschrieben haben.

Infrastruktur und Kosten. Cloud-Architektur, Verfügbarkeit, Notfallwiederherstellung und die Frage, ob die Hosting-Kosten sinnvoll mit dem Umsatz skalieren.

Team und Delivery. Abhängigkeiten von Schlüsselpersonen, Fluktuationsrisiken, Engineering-Praktiken und Delivery-Kennzahlen wie Deployment-Frequenz und Change Failure Rate.

KI-Reife. Zunehmend fragen Käufer auch, ob das Team KI kontrolliert einsetzt und ob das Produkt eine glaubwürdige KI-Roadmap hat.

Ein Verkäufer, der jeden dieser Bereiche bereits mit derselben Sorgfalt geprüft hat wie der Käufer, wird kaum noch überrascht.

Der 90-Tage-Plan

Neunzig Tage reichen aus, um das Ergebnis einer Käufer-Due-Diligence spürbar zu verändern, vorausgesetzt, die Zeit wird in der richtigen Reihenfolge genutzt: erst verstehen, dann beheben, dann aufbereiten.

Tag 1–30: Eine ehrliche Ausgangslage schaffen

Im ersten Monat geht es darum, das Unternehmen so zu sehen, wie ein Käufer es sehen wird. Das wirksamste Instrument ist eine simulierte technische Due Diligence (Mock-DD), durchgeführt von einem unabhängigen Team nach derselben Methodik, die auch die Berater eines Käufers anwenden würden. Interne Selbstbewertungen funktionieren hier selten, denn wer ein System gebaut hat, erkennt seine Schwächen am wenigsten.

Die Bestandsaufnahme sollte Folgendes liefern:

• ein Verzeichnis aller Systeme, Repositories, Umgebungen und Drittanbieter-Abhängigkeiten,
• ein Befundregister für alle Bereiche, die Käufer prüfen,
• eine Bewertung der Schwere jedes Befunds und eine Schätzung des Behebungsaufwands,
• eine erste Einschätzung, wie sich die Befunde auf die Bewertung auswirken könnten.

Ergebnis dieser Phase ist kein Bericht, sondern eine Entscheidungsliste. Jeder Befund erhält einen von drei Wegen: vor dem Verkauf beheben, mit Maßnahmenplan dokumentieren oder als bekannte Einschränkung offenlegen.

Tag 31–60: Beheben, was den Preis beeinflusst

Der zweite Monat dient der Behebung, allerdings nur dort, wo sie sich auszahlt. Ziel ist kein perfektes System, sondern die Beseitigung jener Befunde, mit denen ein Käufer den Preis drücken würde. Typische Prioritäten sind:

• Kritische und hohe Sicherheitsschwachstellen, gefolgt von einem neuen Penetrationstest, damit der Datenraum einen aktuellen, sauberen Bericht enthält.
• Secrets Management und Zugriffskontrolle, einschließlich der Entfernung fest codierter Zugangsdaten und einer Einschränkung privilegierter Zugriffe.
• Open-Source-Lizenzthemen und fehlende Rechteeinräumungen, die sich früh meist günstig lösen lassen, spät aber teuer zu erklären sind.
• Kritische technische Schulden in risikoreichen Modulen, insbesondere dort, wo der Wachstumsplan des Käufers von ihnen abhängt.
• Automatisierte Tests für geschäftskritische Abläufe, die belegen, dass sich das System sicher verändern lässt.
• Schnell realisierbare Einsparungen bei den Cloud-Kosten, denn ineffiziente Infrastrukturausgaben wirken sich direkt auf das Margenprofil aus, für das der Käufer bezahlt.

Die Behebung muss parallel zur Produkt-Roadmap laufen und darf sie nicht ersetzen. Eine sichtbar verlangsamte Feature-Entwicklung in den Monaten vor einem Exit sendet ein eigenes negatives Signal. Externe Kapazitäten für die Behebung, etwa über Unterstützung in der Produkt- und Anwendungsentwicklung oder gezielte Leistungen in den Bereichen DevOps, Cloud-Sicherheit und Managed Services, ermöglichen es dem Kernteam, weiter zu liefern.

Tag 61–90: Die Technologie-Story aufbereiten

Im letzten Monat wird die geleistete Arbeit in Material übersetzt, das ein Käufer schnell überprüfen kann. Genau hier investieren viele Verkäufer zu wenig, obwohl gut strukturierte Nachweise die Due Diligence des Käufers verkürzen und den Raum für spekulative Befunde verkleinern.

Ein käuferfertiges Technologiepaket umfasst in der Regel:

• Einen strukturierten technischen Datenraum mit Architekturdiagrammen, Systemspezifikationen, dem Verzeichnis der Abhängigkeiten, Sicherheitsberichten, Richtlinien und Zertifikaten.
• Ein Register bekannter Einschränkungen, das verbleibende Schwächen zusammen mit realistischen Maßnahmenplänen, Aufwandsschätzungen und Verantwortlichen aufführt.
• Einen technischen FAQ-Katalog, der die wahrscheinlichsten Fragen der Käufer vorab beantwortet und mit dem Datenraum übereinstimmt.
• Eine Demo-Umgebung, die zuverlässig funktioniert und das Produkt von seiner besten Seite zeigt, ohne Produktivdaten preiszugeben.
• Einen Technologieteil der Managementpräsentation, der Architektur, Roadmap und Team in der Sprache des Geschäfts erklärt.
• Vorbereitete Schlüsselpersonen. Der CTO und erfahrene Entwickler sollten wissen, welche Themen zur Sprache kommen, welche Antworten abgestimmt sind und wo die Nachweise liegen.

Beheben, dokumentieren oder offenlegen: die richtige Entscheidung treffen

Nicht jeder Befund verdient dieselbe Behandlung. Die Entscheidung hängt davon ab, wie wichtig das Thema für einen Käufer ist und ob es sich realistisch vor Prozessbeginn lösen lässt.

Bei größeren strukturellen Themen kann ein AI Refactoring Assessment Aufwand und Risiko einer Modernisierung beziffern. Ein bekanntes, bepreistes Problem ist für einen Käufer weitaus leichter zu akzeptieren als eine offene Frage.

Typische Fehler, die Verkäufer Geld kosten

Kurz vor dem Verkauf einen großen Neubau beginnen. Eine halb abgeschlossene Migration lässt sich schwerer bewerten als das alte oder das neue System. Große Modernisierungsprogramme sollten entweder deutlich vor dem Exit abgeschlossen oder als Plan präsentiert werden.

Probleme verschweigen. Erfahrene Käuferteams finden die meisten wesentlichen Themen. Ein vom Verkäufer offengelegtes Problem ist ein Verhandlungspunkt; ein vom Käufer entdecktes Problem ist ein Glaubwürdigkeitsproblem.

Nur die Oberfläche aufpolieren. Ansprechende Dokumentation, die nicht zum Code passt, fällt schnell auf. Nachweise müssen die Realität abbilden.

Den CTO allein lassen. Eine Käufer-Due-Diligence ist intensiv. Ohne Vorbereitung und Unterstützung wird die technische Leitung zum Engpass, und das Tagesgeschäft leidet.

Delivery-Kennzahlen ignorieren. Käufer verlangen zunehmend Daten statt Einschätzungen. Wer Deployment-Frequenz, Durchlaufzeit und Change Failure Rate belegen kann, idealerweise im Zeitverlauf, macht die Engineering-Story deutlich glaubwürdiger. Auch ein strukturierter KI-Einsatz entlang des gesamten Softwareentwicklungsprozesses kann dieses Bild stärken, sofern die Wirkung gemessen und nicht nur behauptet wird.

Wer die Technologie-Story nicht selbst erzählt, überlässt sie dem Käufer

Bei jedem Exit beschreibt jemand dem Investmentkomitee des Käufers die Technologie des Zielunternehmens. Die einzige Frage ist, ob der Verkäufer diese Beschreibung mitgestaltet oder ob die Berater des Käufers sie allein verfassen. Ein 90-Tage-Readiness-Programm gibt dem Management die Fakten, die Verbesserungen und die Nachweise an die Hand, um dieses Gespräch selbst zu führen.

Der Nutzen zeigt sich selten in einer einzigen spektakulären Zahl. Er liegt in einem reibungsloseren Prozess, weniger Preisabschlägen, enger gefassten Freistellungen, einer kürzeren Exklusivitätsphase und einem Managementteam, das auch schwierige Fragen souverän beantwortet. Wenn Sie einen Exit in den nächsten 6 bis 12 Monaten planen, erfahren Sie auf unserer Seite zur technischen Due Diligence, wie wir eine Mock-DD durchführen und das Unternehmen auf die echte Prüfung vorbereiten.

‍