Wer ein Softwareunternehmen kaufen, finanzieren oder strategisch bewerten will, hat selten ein Vertriebsproblem. Die kritischen Risiken liegen tiefer - im Code, in der Architektur, in Abhängigkeiten, im Team und in den Betriebsprozessen. Genau dort entscheidet sich, ob ein Deal skalierbar ist oder später teuer wird.
Bei einer technischen due diligence für Softwareunternehmen geht es deshalb nicht um eine nette Code-Review mit ein paar allgemeinen Hinweisen. Es geht um eine belastbare Antwort auf eine geschäftliche Frage: Ist dieses Unternehmen technisch in der Lage, Wachstum, Integration und Rendite zu tragen - oder kaufen Sie versteckte Sanierungskosten mit ein?
Was technische Due Diligence bei Softwareunternehmen wirklich leisten muss
Viele Prüfungen bleiben an der Oberfläche. Es wird gezählt, welche Programmiersprachen genutzt werden, ob die Cloud modern aussieht und ob Tickets im Jira existieren. Das reicht nicht. Eine saubere technische due diligence softwareunternehmen bewertet nicht nur den Ist-Zustand, sondern die wirtschaftlichen Folgen des technischen Zustands.
Ein Beispiel aus dem deutschen Mittelstand: Ein SaaS-Anbieter für die Fertigungsplanung wirkt auf den ersten Blick solide. Die Umsätze steigen, die Kundenbasis in Bayern und Baden-Württemberg ist stabil, das Produkt adressiert einen echten Bedarf. In der Prüfung zeigt sich aber, dass das Kernsystem auf einem monolithischen PHP-Altbestand läuft, ergänzt durch manuelle SQL-Eingriffe in Produktionsdatenbanken. Neue Kunden-Onboardings brauchen deshalb individuelle Hotfixes. Der Umsatz ist real, aber die Skalierung ist es nicht.
Technische Due Diligence muss genau solche Widersprüche sichtbar machen. Nicht als akademische Kritik, sondern als Entscheidungsgrundlage für Kaufpreis, Earn-out, Integrationsplan oder sogar Rückzug aus dem Prozess.
Die fünf Prüfbereiche, die wirklich zählen
1. Architektur und technische Tragfähigkeit
Die erste Frage lautet nicht, ob der Stack modern klingt. Die relevante Frage ist, ob die Architektur zum Geschäftsmodell passt. Ein internes B2B-Tool mit 50 Nutzern hat andere Anforderungen als eine Plattform mit mehreren Mandanten, SLA-Verpflichtungen und hohem Integrationsgrad.
In der Praxis sehen wir in Deutschland häufig Mischlandschaften: ein Kernsystem in .NET oder Java, dazu Web-Frontends in React oder Angular, Reporting in Power BI und daneben historisch gewachsene Excel- und CSV-Prozesse. Das ist nicht automatisch schlecht. Problematisch wird es, wenn zentrale Geschäftslogik außerhalb kontrollierter Systeme liegt - etwa in Einzelmakros, Cronjobs ohne Monitoring oder E-Mail-basierten Freigaben.
Eine gute Bewertung trennt deshalb zwischen vertretbarer Komplexität und strukturellem Risiko. Technische Schulden sind normal. Entscheidender ist, ob sie dokumentiert, priorisiert und mit vertretbarem Aufwand reduzierbar sind.
2. Codequalität und Lieferfähigkeit
Viele Käufer fokussieren zu stark auf den aktuellen Produktumfang. Für den Unternehmenswert ist aber oft wichtiger, wie verlässlich das Team Änderungen liefern kann. Schlechte Codequalität ist kein ästhetisches Problem. Sie erhöht die Kosten pro Feature, verlängert Release-Zyklen und macht Fehler wahrscheinlicher.
Hier lohnt der Blick auf konkrete Signale: Gibt es automatisierte Tests in relevanten Kernbereichen? Wie hoch ist die Abhängigkeit von einzelnen Entwicklern? Werden Releases reproduzierbar ausgerollt oder per Hand auf Server kopiert? Gibt es klare Branching- und Review-Prozesse?
Ein typischer Fall bei wachsenden Softwareunternehmen: Das Produkt wurde schnell gebaut, der Gründer oder erste Lead Developer kennt jede Ecke des Systems, aber niemand sonst. Solange diese Person verfügbar ist, wirkt das beherrschbar. In einer Transaktion ist genau das ein Risiko. Wenn Wissen an Einzelpersonen hängt, ist der Deal operativ fragil.
3. Infrastruktur, Security und Betriebsstabilität
Gerade bei B2B-Software in Deutschland wird Security oft erst dann ernsthaft geprüft, wenn Enterprise-Kunden nach ISO 27001, Zugriffsprotokollen oder Rollenmodellen fragen. Für Investoren und Käufer ist das zu spät.
Technische Due Diligence sollte deshalb klären, wie das System tatsächlich betrieben wird: in AWS, Azure, Hetzner oder auf eigener Infrastruktur. Gibt es Backups, Disaster-Recovery-Pläne, Monitoring, Alerting und nachvollziehbare Deployments? Wie werden Secrets verwaltet? Sind Entwicklungs-, Test- und Produktionsumgebungen sauber getrennt?
Für deutsche SMBs ist auch Datenschutz keine Nebensache. Wenn ein HR-Tech- oder Health-Tech-Produkt personenbezogene Daten verarbeitet, reichen allgemeine Aussagen wie "DSGVO-konform" nicht aus. Relevant sind Datenflüsse, Löschkonzepte, Berechtigungen und die Frage, ob technische Umsetzung und rechtliche Zusagen überhaupt zusammenpassen.
4. Produktteam, Prozesse und Steuerbarkeit
Ein gutes Produkt kann trotz mäßiger Prozesse existieren. Ein gutes Investment selten. Technische Due Diligence bewertet deshalb nicht nur Software, sondern auch die Fähigkeit des Unternehmens, Software planbar weiterzuentwickeln.
Dazu gehört die Frage, wie Entscheidungen getroffen werden. Gibt es einen Product Owner mit echtem Mandat? Werden Anforderungen strukturiert priorisiert? Sind Roadmap und Technik realistisch aufeinander abgestimmt? Oder arbeitet das Team reaktiv, getrieben von Vertrieb, Support und einzelnen Großkunden?
Gerade in inhabergeführten deutschen Softwareunternehmen ist diese Gemengelage häufig. Das Team ist fachlich stark, aber Steuerung läuft über Zuruf. Für ein Bootstrapped-Unternehmen kann das lange funktionieren. Nach einer Übernahme oder Wachstumsfinanzierung wird es schnell zum Engpass.
5. Integrationsfähigkeit und Post-Deal-Aufwand
Ein Punkt wird in vielen Prüfungen unterschätzt: Wie gut lässt sich das Zielunternehmen in bestehende Prozesse, Systeme und Reporting-Strukturen integrieren? Wenn Sie bereits ein Portfolio mit CRM, ERP, Data Warehouse und Identity-Management betreiben, ist die technische Anschlussfähigkeit bares Geld wert.
Ein Beispiel: Ein Softwareanbieter für Logistikdienstleister hat saubere Kundenbeziehungen und gute Margen. Technisch fehlt aber jede standardisierte API. Exporte laufen über manuell erzeugte CSV-Dateien, Mandantenlogik ist uneinheitlich und Berechtigungen sind kundenspezifisch im Code hinterlegt. Der Kauf kann trotzdem sinnvoll sein - aber nur, wenn der Integrationsaufwand sauber eingepreist wird.
Woran technische Due Diligence oft scheitert
Die häufigste Schwäche ist fehlende Übersetzung. Viele technische Berichte beschreiben Probleme korrekt, aber nicht entscheidungsreif. Ein Käufer braucht keine lose Sammlung technischer Auffälligkeiten, sondern eine Priorisierung nach Geschäftsauswirkung.
"Veraltetes Framework" ist als Aussage fast wertlos. Relevant ist, ob daraus ein Sicherheitsrisiko, ein Hiring-Problem, ein Migrationsprojekt oder eine Einschränkung der Produkt-Roadmap entsteht. Dasselbe gilt für Testabdeckung, Cloud-Architektur oder Build-Pipelines. Der technische Befund ist nur der Anfang. Der Wert liegt in der Einordnung.
Die zweite Schwäche ist falsche Tiefe. Nicht jedes Unternehmen braucht eine forensische Komplettanalyse. Bei einem kleinen SaaS-Case mit überschaubarem Stack kann eine fokussierte Prüfung der Kernrisiken reichen. Bei einer Plattform mit regulatorischem Druck, kritischer Infrastruktur oder komplexer Multi-Entity-Architektur ist deutlich mehr Tiefe nötig. Es hängt vom Deal ab.
Ein praxistauglicher Bewertungsrahmen
Für M&A-Entscheider, Gründer und operative Leiter ist ein einfacher Rahmen oft hilfreicher als ein 80-seitiger Bericht. Wir arbeiten in solchen Fällen mit vier Leitfragen.
Erstens: Ist das System heute stabil genug, um den laufenden Betrieb ohne Sonderwissen zu tragen?
Zweitens: Ist es morgen erweiterbar genug, um Roadmap, Kundenanforderungen und Integration wirtschaftlich umzusetzen?
Drittens: Ist es sicher und kontrolliert genug, um Compliance-, Datenschutz- und Enterprise-Anforderungen standzuhalten?
Viertens: Ist das Team steuerbar genug, um nach dem Deal verlässlich zu liefern?
Wenn eine oder mehrere dieser Fragen nur mit Einschränkungen beantwortet werden können, ist das nicht automatisch ein Ausschlusskriterium. Aber es verändert den Deal. Dann geht es um Kaufpreisabschläge, Übergangsphasen, Retention kritischer Mitarbeiter oder einen klaren 100-Tage-Plan nach Closing.
Was Käufer und Investoren konkret mitnehmen sollten
Eine technische due diligence softwareunternehmen ist dann gut, wenn sie drei Dinge liefert: Klarheit über reale Risiken, eine grobe Quantifizierung des Sanierungs- oder Modernisierungsaufwands und eine belastbare Sicht auf die Lieferfähigkeit nach dem Deal.
Für deutsche Käufer im SMB- und Mid-Market-Segment ist das besonders relevant, weil viele Zielunternehmen über Jahre pragmatisch gewachsen sind. Das ist nicht negativ. Oft steckt darin sogar Marktstärke. Aber pragmatisches Wachstum hinterlässt technische Narben: manuelle Workarounds, fehlende Dokumentation, kundenspezifische Sonderlogik und Release-Prozesse, die nur mit eingespielten Einzelpersonen funktionieren.
Genau deshalb braucht technische Due Diligence keine Buzzwords, sondern klare Urteile. Was ist gut genug, um weiterzuwachsen? Was ist tolerierbar, aber teuer? Und was ist kritisch genug, um den Deal neu zu verhandeln?
Wenn Sie diese Fragen früh, strukturiert und ohne technische Beschönigung beantworten, vermeiden Sie den teuersten Fehler im M&A-Prozess: ein Softwareunternehmen nach Umsatz zu bewerten, obwohl die eigentliche Wahrheit in Betrieb, Code und Teamstruktur liegt. Wer das sauber prüft, kauft nicht nur ein Produkt - sondern die reale Fähigkeit, daraus verlässlich Wert zu machen.