Technical Due Diligence · Maturity Assessment
Was der Code kann — und was nur im Slide-Deck steht.
Kauf, Beteiligung oder große Modernisierung: Ich prüfe Code, Pipelines und Infrastruktur direkt in den Repositories, spreche mit den Entwicklern — und sage Ihnen, was trägt und was nicht. Jeder Befund mit Fundstelle.
2 Wochen
5 Leitfragen
12+
ISO 25010
Was geprüft wird
45 Capabilities entlang der Delivery-Phasen, je Capability meets, deviates, delegated oder n/a. Delegiert bedeutet nicht außerhalb des Scopes: Dann prüfe ich die Schnittstelle zum Betreiber. Die Prüfkriterien dahinter bleiben mein Arbeitsmittel.
Der Werkzeuglauf
Wo das Target es erlaubt, laufen meine Werkzeuge in dessen Pipeline und liefern die Nachweise für die Bewertung. Ein Auszug, Werte fiktiv:
Was Sie bekommen
Vier Seiten aus der Report-Vorlage: Inhalt, Executive Summary und Roadmap aus dem High-Level-Report, ein Befund aus dem Deep-Dive-Report. Werte fiktiv — durchklicken oder laufen lassen.
Jeder Befund hat eine Fundstelle: Pfad und Zeile, Commit, Tool-Ausgabe, Dokument oder Interview mit Datum. Wer einen Befund bestreitet, kann ihn nachprüfen.
Vier Anlässe, ein Vorgehen
Zwei Beispiele: eine Banking-as-a-Service-Plattform vor der Finanzierungsrunde und die 6R-Analyse mit Make-vs-Buy-Business-Case für einen Energie-Software-Anbieter.
Vor dem Kauf wissen, was Sie übernehmen
Architektur, Code, Team und Roadmap des Targets. Was ist belastbar, was ist Risiko, was kostet die Modernisierung? Report in zwei bis vier Wochen.
Pitch gegen Realität
Skaliert die Basis, trägt das Team die Vision? Auf Wunsch mit Begleitung nach dem Investment.
Befunde vor dem Käufer finden
Dieselbe Prüfung im Auftrag des Targets: Was ein Käufer finden würde, finden Sie zuerst und beheben es, bevor der Datenraum geöffnet wird.
Wo steht Ihre Plattform?
Vor Modernisierung, Migration oder Wachstumsschub. Ergebnis: 6R-Klassifikation und Make-vs-Buy-Business-Case.
Engagement-Modelle
Klarer Umfang, fester Zeitrahmen
Red-Flag-Review
Gibt es einen Grund, abzubrechen oder nachzuverhandeln?
- ✓Nur Deal-Breaker-Kategorien, keine Reifegrade
- ✓Key-Person-Risiko aus der Git-Historie
- ✓Lizenzen, Secrets, Runtimes am Supportende
- ✓Ergebnis: Full DD ja oder nein, und mit welchem Schwerpunkt
Für: Käufer und Investoren, bevor die Full DD beginnt
Full Tech DD
Die vollständige Prüfung entlang der fünf Leitfragen.
- ✓Team, Security, IP und die Regulatorik Ihrer Branche
- ✓Alle Repositories gesichtet, Deep Dive an den kritischen Stellen
- ✓Interviews mit Team und Schlüsselpersonen
- ✓Befunde in Deal-Sprache für Vorstand und Deal-Team
- ✓Umsetzungs-Roadmap mit Aufwandsspanne
Für: M&A, PE-Beteiligungen, größere Targets
Investment-Check
Die fokussierte Prüfung, bevor Kapital fließt.
- ✓Architektur-, Code- und Prozess-Review
- ✓Team-Bewertung — kann es die Vision umsetzen?
- ✓AI-Behauptungen gegen Realität geprüft
- ✓Red Flags, fünf Leitfragen, grobe Roadmap
Für: VC-/Angel-Investments und kleinere Targets
Maturity Assessment
Reifegrad je Dimension, mit Roadmap statt Befundliste.
- ✓Code- und Architekturqualität nach ISO 25010
- ✓6R-Klassifikation der Landschaft
- ✓Make-vs-Buy-Business-Case
- ✓Roadmap mit Aufwandsspannen, Pilot zuerst
Für: die eigene Plattform vor großen Entscheidungen
NDA auf Wunsch vor dem ersten Gespräch. Für Prüfungen über Technologie hinaus und für Vendor DD mit Reliance arbeite ich mit Beratungshäusern zusammen und liefere den technischen Teil.
So läuft ein Assessment
Drei Phasen, zwei Dokumente
Am Ende stehen der High-Level-Report für Board und Deal-Team und der Deep-Dive-Report für CTO und Engineering, mit denselben Befunden in unterschiedlicher Tiefe.
Zugang & Überblick
Mit dabei: Auftraggeber, Management des Targets
Wir klären, was geprüft wird und worauf es Ihnen ankommt. In den ersten Interviews zeigt mir das Team, wo Code, Pipelines und Infrastruktur liegen.
- ▸Scope, Prüffragen und Ausschlüsse festlegen
- ▸Anforderungsliste für den Datenraum
- ▸Überblick über Repositories, Pipelines und Infrastruktur
- ▸Zugänge und Werkzeugeinsatz klären
Ergebnis: Geklärter Prüfumfang, geklärte Zugänge.
Deep-Dive
Mit dabei: Team und Schlüsselpersonen des Targets
Dokumente beschreiben den Soll-Zustand, der Code den Ist-Zustand. Interviews klären die Abweichungen.
- ▸Code-Analyse bis in die Architektur, toolgestützt, wo erlaubt
- ▸Git-Historie: Wer kennt welchen Code?
- ▸Pipelines, Infrastruktur-Code und Betrieb
- ▸Interviews zu Befunden und Widersprüchen
Ergebnis: Befunde mit Fundstelle und Evidenzstufe.
Bewertung & Report
Mit dabei: Deal-Team bzw. Management
Befunde werden gewichtet: Was ist deal-relevant, was normale technische Schuld, was kostet eine mögliche Behebung?
- ▸Red Flags vorangestellt, nie in einen Mittelwert verrechnet
- ▸Fünf Leitfragen für das Board, Detailteil für das Engineering
- ▸Roadmap mit Aufwandsspanne je Paket, Pilot zuerst
- ▸Durchsprache mit Deal-Team oder Management
Ergebnis: Der fertige Report, durchgesprochen statt nur zugeschickt.
Warum meine Prüfung anders ausfällt
Von jemandem, der selbst baut
12+ Jahre Plattform- und Architekturarbeit in Banken, Energie und Industrie. Ich weiß, wie technische Schulden entstehen und was eine Behebung kosten würde. Deshalb endet jeder Report mit einer Roadmap samt Aufwandsspannen.
Deep Code Review
Ich analysiere selbst. Wo das Target es erlaubt, zusätzlich toolgestützt in dessen Pipeline, nur lesend. Interviews bestätigen, sie ersetzen keinen Befund.
AI-Substanz als Prüfdimension
Wie belastbar sind die AI-Behauptungen? Modell-Abhängigkeiten, Datenflüsse, laufende Kosten, DSGVO- und EU-AI-Act-Risiken. Geprüft von jemandem, der AI-Systeme selbst produktiv baut.
Befunde in Deal-Sprache
Jeder Befund trägt eine Schwere, vom Deal-Breaker über Preis und Closing-Bedingung bis zur Beobachtung, und eine Evidenzstufe. Was ich nur aus Interviews weiß, steht als Indiz im Report, nicht als Tatsache.
Aus der Praxis
Notizen aus Startup-Journeys
- Veröffentlicht am
A Smart Start for Startups
Vorab gefragt
Bevor es losgeht
Brauchen Sie Zugriff auf den Code?+
Lesenden Zugriff, so weit möglich: Repositories, Pipeline-Definitionen, Infrastruktur-Code. Der Zugriff bestimmt die Belastbarkeit des Urteils: Ein Befund aus dem Code steht als belegt im Report, einer aus dem Interview als Indiz.
Was läuft in unserer Pipeline?+
Nur auf Ihren Wunsch. Dann kommen meine Prüfwerkzeuge als signiertes Container-Image mit SBOM, laufen in der CI/CD-Pipeline des Targets, nur lesend über ein Access Token mit Scope read_api, ohne Schreibrechte, und legen die Befunde als Pipeline-Artefakt ab. Das Security-Team kann das Image vorab prüfen. Ohne diese Freigabe prüfe ich manuell, nach denselben Prüfpunkten.
Und ohne Code-Zugriff?+
Dann tragen Interviews, am Bildschirm gezeigter Code und angeforderte Exporte wie Pipeline-Definitionen und Scan-Berichte die Prüfung. Die betroffenen Befunde stehen als Indiz im Report, der fehlende Zugriff steht vorne als Grenze des Scopes.
Setzen Sie AI ein?+
Meine Werkzeuge nutzen keine AI. Ob ich danach AI beim Auswerten, beim Code-Review und beim Schreiben einsetze, legt Ihr Vertrag fest, in Stufen. Ohne Freigabe entsteht der Report ohne AI.
Prüfen Sie auch Compliance?+
Die Regulatorik, die Ihr Auftrag oder Ihre Branche verlangt, prüfe ich voll, etwa DORA bei Zulieferern von Banken. Geprüft werden technische Umsetzung und Nachweise. Rechtsauslegung und Verträge bleiben bei der Legal-DD, im Report steht die Schnittstelle.
Bekommt das Target Ihren Prüfkatalog?+
Vorab bekommt es eine Anforderungsliste für den Datenraum und die Agenda der Interviews. Den vollständigen Katalog gebe ich bei Käufer- und Investorenprüfungen nicht heraus. Wer den Katalog vorab kennt, bereitet genau diese Stellen vor.
Nächster Schritt
Sprechen wir über Ihr Target
30 Minuten: Sie skizzieren den Fall — Target, Anlass, Zeitrahmen. Ich sage Ihnen, was eine Prüfung leisten kann, wie lange sie dauert und was sie kostet.