Technische Due Diligence: was in wenigen Tagen prüfbar ist
Für: Investoren, Käufer und Verwaltungsräte
Aktualisiert: 2026-09
Eine technische Due Diligence in knapper Zeit konzentriert sich auf sechs Fragen: Trägt die Architektur den geplanten Wachstumspfad, wie gross ist die technische Schuld, hängt das System an einzelnen Personen, wie steht es um Sicherheit und Lizenzen, und lässt sich der Betrieb übergeben.
Eine technische Due Diligence hat selten genug Zeit, um alles zu prüfen. Sie muss deshalb priorisieren: Nicht jeder Mangel ist ein Risiko für den Kaufpreis, und nicht jedes saubere Repository bedeutet ein tragfähiges System.
Diese Checkliste sortiert nach dem, was sich in wenigen Tagen belastbar feststellen lässt und was tatsächlich Einfluss auf die Bewertung hat. Der Schwerpunkt liegt auf Risiken, die nach dem Abschluss teuer werden.
Die Checkliste
- 01
Architektur gegen den Wachstumspfad prüfen
Nicht fragen, ob die Architektur gut ist, sondern ob sie den geplanten Weg trägt. Ein monolithisches System kann für den vorgesehenen Pfad völlig ausreichen — die Frage ist, wo die erste harte Grenze liegt.
Erledigt, wenn: Der Punkt, an dem die Architektur an eine Grenze stösst, ist benannt und in Nutzerzahlen oder Datenvolumen ausgedrückt.
- 02
Technische Schuld greifbar machen
Nicht die Menge zählen, sondern die Verteilung. Entscheidend ist, ob die Schuld in Bereichen liegt, die für die geplante Weiterentwicklung angefasst werden müssen, oder in stabilen Randbereichen.
Erledigt, wenn: Es liegt eine Aussage vor, welche Teile des Systems für die nächsten Vorhaben angefasst werden und in welchem Zustand genau diese Teile sind.
- 03
Personenabhängigkeit feststellen
Prüfen, ob es Bereiche gibt, die nur eine Person versteht. Bei kleinen Teams ist das die Regel; die Frage ist, ob diese Person bleibt und ob es einen Weg zur Übergabe gibt.
Erledigt, wenn: Für jeden kritischen Systemteil sind mindestens zwei Personen benannt, oder das Risiko ist ausdrücklich vermerkt.
- 04
Lizenzen der Abhängigkeiten prüfen
Copyleft-Lizenzen in einem kommerziellen Produkt können bindende Folgen haben. Die Prüfung ist automatisierbar und gehört zu den wenigen Punkten mit klarem Ja oder Nein.
Erledigt, wenn: Eine vollständige Abhängigkeitsliste mit Lizenzen liegt vor, und kritische Lizenzen sind einzeln bewertet.
- 05
Sicherheitsgrundlagen abklopfen
Zugriffsverwaltung, Verwaltung von Geheimnissen, Verschlüsselung, Aktualisierungsstand der Abhängigkeiten. Kein vollständiger Sicherheitstest, sondern die Frage, ob Grundlegendes vorhanden ist.
Erledigt, wenn: Es gibt keine Zugangsdaten im Quellcode, und der Aktualisierungsstand der Abhängigkeiten ist bekannt.
- 06
Betriebsreife und Übergabefähigkeit prüfen
Kann eine andere Mannschaft dieses System betreiben? Prüfen Sie Bereitstellungsprozess, Überwachung, Sicherungen und ob eine Wiederherstellung je getestet wurde.
Erledigt, wenn: Eine Wiederherstellung aus der Sicherung wurde nachweislich einmal durchgeführt, nicht nur eingerichtet.
- 07
Datenschutz- und Compliance-Lage erfassen
Verzeichnis, Auftragsverarbeitung, Datenresidenz und — bei KI-Funktionen im Produkt — die Einordnung nach dem AI Act. Lücken hier sind nach dem Abschluss die Verantwortung des Käufers.
Erledigt, wenn: Der Compliance-Stand ist dokumentiert, und offene Punkte sind mit einer Aufwandsschätzung versehen.
Häufige Fehler
- —Die Prüfung bewertet Codequalität statt Risiko. Eleganter Code in einem Bereich, der nie angefasst wird, ist für die Bewertung ohne Belang.
- —Die Abhängigkeit von einzelnen Personen wird nicht angesprochen, weil sie unangenehm ist. Sie ist bei kleinen Teams oft das grösste Einzelrisiko.
- —Sicherungen sind eingerichtet, aber eine Wiederherstellung wurde nie getestet. Der Unterschied zeigt sich erst im Ernstfall.
- —Compliance wird als Rechtsthema ausgeklammert, obwohl offene Punkte direkt in den Integrationsaufwand fliessen.
Was diese Checkliste nicht abdeckt
- —Eine technische Due Diligence in wenigen Tagen ist eine Risikoeinschätzung, kein Vollständigkeitsnachweis. Sie findet die grossen Themen, nicht jeden Mangel.
- —Ein vollwertiger Sicherheitstest mit Angriffssimulation ist nicht enthalten und muss bei erhöhtem Schutzbedarf separat beauftragt werden.
- —Die rechtliche Prüfung von Verträgen, Rechten am geistigen Eigentum und Arbeitsverhältnissen ist ein eigener Arbeitsstrang.
- —Aussagen zur künftigen Skalierbarkeit beruhen auf dem beschriebenen Wachstumspfad. Ändert sich dieser, ändert sich die Bewertung.
Übergeordnete Leistung: IT-Beratung
Passende Angebote
Tech Due Diligence
Eine Tech Due Diligence prüft vor einer Investition oder Übernahme, was unter der Haube steckt: Architektur, Code-Qualität, Skalierbarkeit, Sicherheit und technische Schulden. Ergebnis ist eine ehrliche Risikobewertung, die eine teure Fehlentscheidung verhindern kann — bevor sie getroffen wird.
CTO as a Service
CTO as a Service liefert technische Führung auf Zeit: fundierte Architektur- und Technologieentscheidungen, Roadmap-Planung und Team-Begleitung — ohne die Kosten einer Vollzeit-Position. Ideal für Unternehmen, die technische Substanz brauchen, aber noch keinen eigenen CTO tragen können oder wollen.
Häufige Fragen
Wie viel Zugang wird benötigt?
Lesezugriff auf das Repository, Einsicht in die Abhängigkeitsliste und Gespräche mit den technisch Verantwortlichen decken den grössten Teil ab. Produktivzugriff ist selten nötig.
Was ist der häufigste Befund?
Personenabhängigkeit und ungetestete Wiederherstellung. Beides ist behebbar, muss aber vor dem Abschluss bekannt sein, weil es direkt in die Integrationsplanung fliesst.
Ist ein Befund ein Grund, abzusagen?
Selten. Häufiger fliessen Befunde in Kaufpreis, Garantien oder einen Massnahmenplan nach dem Abschluss ein. Der Zweck der Prüfung ist ein zutreffendes Bild, keine Bewertung mit Bestehen oder Durchfallen.
Weitere Checklisten
Technical-SEO-Prüfung: die Punkte, die Indexierung tatsächlich verhindern
Die meisten technischen SEO-Probleme lassen sich auf wenige Ursachen zurückführen: Seiten sind nicht indexierbar, Canonicals zeigen falsch, die Sitemap enthält Seiten, die nicht indexiert werden sollen, hreflang ist nicht reziprok, oder Seiten sind intern kaum verlinkt.
Sichtbarkeit in KI-Antworten: die Prüfliste für Zitierfähigkeit
Zitierfähigkeit in KI-Antworten beruht auf wenigen Eigenschaften: eine kurze, eigenständige Antwort weit oben, eindeutige Aussagen statt Marketingsprache, überprüfbare Angaben mit Datum und Urheber, saubere Zugänglichkeit für KI-Crawler und eine erkennbare Autorenschaft.
MVP-Start: was vor der ersten zahlenden Kundin stehen muss
Vor dem Start eines MVP müssen fünf Dinge stehen: eine funktionierende Zahlungsstrecke, eine Datenlage, die spätere Änderungen erlaubt, ein Weg zur Löschung von Konten, eine Möglichkeit zu erfahren wenn etwas kaputt ist, und rechtliche Grunddokumente. Alles andere kann warten.