--- title: "Technische Due Diligence für Investoren & Käufer" canonical: https://wavect.io/de/services/technical-due-diligence/ language: de description: "Unabhängige technische Due Diligence zu Code, Architektur, Security, Delivery und technischen Schulden. Ein schriftlicher Risikobericht mit Schweregrad, Belegen und Lösungswegen." image: "https://wavect.io/img/general/bak/open_graph_preview.jpg" --- Technische Due Diligence # Technische Due Diligence, die dir zeigt, was du wirklich kaufst. Bevor du investierst, übernimmst oder eine Plattform freigibst, solltest du wissen, was hinter der Demo steckt. Wir prüfen den vereinbarten Code, die Architektur, die Security-Lage und den Delivery-Prozess und übergeben dir einen schriftlichen Bericht, der die Risiken gewichtet und erklärt, was ihre Behebung bedeutet. DER AUFTRAG ## Eine Entscheidung. Eine klar begrenzte Prüfung. Ein Bericht, mit dem du arbeiten kannst. 1. **Die Frage klären** Entscheidung, Systeme im Umfang und Empfänger des Berichts. 2. **Belege prüfen** Code, Architektur, Security, Delivery, Betrieb und Team. 3. **Risiken gewichten** Schweregrad, Belege, Lösungswege und offene Fragen. KURZ ERKLÄRT Technische Due Diligence ist eine unabhängige Prüfung der Software hinter einem Unternehmen oder Produkt vor einer Investition, einer Übernahme oder einer Entscheidung des Boards. Am Ende steht ein schriftlicher Risikobericht mit Schweregrad, Belegen und Lösungswegen, keine Rechts- oder Finanzberatung. Passt für - Investoren, Käufer und Boards, die vor einer Entscheidung einen externen Blick auf ein Software-Asset brauchen - Gründer, die ihre eigene Plattform prüfen lassen wollen, bevor Investoren die Fragen stellen Eine andere Leistung passt besser - Rechtliche, steuerliche oder finanzielle Due Diligence oder eine Aussage zur Bewertung - Code nach einem Anbieterwechsel übernehmen und weiter betreiben ## Bei der Entscheidung beginnen, die der Bericht stützen soll Ein Investor vor einer Runde, ein Käufer vor dem Signing und ein Board, das die eigene Plattform prüft, brauchen unterschiedliche Tiefe. Vor dem Start vereinbaren wir die Entscheidung, die Systeme und Repositories im Umfang, den verfügbaren Zugriff und den Empfänger des Berichts. Kommerzielle, rechtliche, steuerliche und finanzielle Prüfung bleiben bei deinen Anwälten und Beratern. Berührt ein technischer Befund ihre Arbeit, etwa unklare Rechte am Code oder Pflichten aus Open-Source-Lizenzen, markiert der Bericht das für sie, ohne eine rechtliche Schlussfolgerung zu ziehen. ## Was die Prüfung abdeckt Die Abdeckung folgt dem vereinbarten Umfang. Für jeden Bereich halten wir fest, was wir geprüft haben, worauf wir keinen Zugriff hatten und wie belastbar die Schlussfolgerung ist. Code und Architektur Struktur, Testabdeckung und Testqualität, Dokumentation, Abhängigkeit von einzelnen Personen und wie schwer sich das System ändern lässt. Security-Lage Zugriffe auf Code und Infrastruktur, Umgang mit Secrets, verwundbare Abhängigkeiten und offensichtliche Angriffsflächen. Das ist eine Prüfung, kein Penetrationstest. Delivery-Prozess und Team Wie Änderungen in Produktion kommen, Release- und Rollback-Praxis, Incident-Historie und wer das Wissen trägt. Skalierung, Betrieb und Kosten Hosting, Monitoring, Wiederherstellbarkeit sowie die Infrastruktur- und Drittanbieterkosten hinter dem Produkt. KI-spezifische Nachweise Bei KI-Produkten Evaluationsdesign, Modell- und Prompt-Dokumentation, Anbieterabhängigkeit, Fehlerbehandlung und Kosten pro Aufgabe. Unsere [Due-Diligence-Checkliste für KI-MVPs](/de/blog/technical-due-diligence-ai-mvp/) listet die Nachweise, nach denen wir suchen. Abhängigkeiten und technische Schulden Veraltete Frameworks, nicht mehr unterstützte Komponenten und Schulden, die die Roadmap bremsen, mit einer groben Einschätzung, was ihre Behebung kostet. ## Ein Bericht, der Risiken gewichtet, statt alles aufzulisten Jeder Befund hat einen Schweregrad, die Belege dahinter, die wahrscheinliche Auswirkung auf den Business Case und realistische Wege zur Behebung. Wenn du Aufwände sehen willst, nennen wir Spannen, klar gekennzeichnet als Schätzungen unter den für den Auftrag vereinbarten Annahmen, nicht als Angebote. Der Bericht trennt dealrelevante Risiken von normaler Engineering-Pflege und listet die Fragen, die das Management noch beantworten muss. Er sagt weder Bewertung noch Deal-Konditionen noch den Ausgang einer Transaktion voraus. ## So läuft eine Due Diligence ab Umfang, Zeitplan und Fixpreis vereinbaren wir vor Beginn in einem unterschriebenen Leistungsvertrag. Die Dauer hängt von der Größe des Systems ab und davon, wie schnell Zugriffe und Gespräche möglich sind. 1. **Scoping und Zugriff** - Entscheidung, Systeme, Empfänger und Vertraulichkeit festlegen. Lesezugriff auf Repositories, Datenraum und relevante Dokumentation erhalten. 2. **Prüfung und Gespräche** - Code und Infrastruktur prüfen und mit den Leuten sprechen, die das System bauen und betreiben. Offene Fragen gehen schriftlich an das Management. 3. **Bericht und Besprechung** - Du erhältst den schriftlichen Bericht und gehst ihn mit uns durch. Sachliche Korrekturen des geprüften Unternehmens behandeln wir so, wie es vorab vereinbart wurde. ## Nach dem Bericht den passenden nächsten Schritt wählen Die Due Diligence endet mit dem Bericht. Übernimmst du danach den Code oder wechselst den Anbieter, gehören Zugriffsübernahme und Stabilisierung zur [Software-Übernahme](/de/services/software-takeover/). Laufende Release-Tests sind [Qualitätssicherung](/de/services/software-quality-assurance/). Angriffstests und Härtung einer KI-Funktion gehören zu [AI Security](/de/services/ai-security/), die laufende Cloud-Umgebung zu [Cloud Security](/de/services/cloud-security/). Wurde das Produkt mit Lovable, Bolt oder ähnlichen Tools gebaut und muss repariert werden, passt [Vibe Coding Rescue](/de/services/vibe-coding-rescue/). Braucht das Unternehmen während einer Finanzierungsrunde oder eines Verkaufs eine technische Führungskraft auf seiner Seite, ist das eine Rolle für einen [Fractional CTO](/de/services/fractional-cto/). Falls wir später ein Angebot für die Behebung abgeben könnten, sagen wir das vor Beginn der Prüfung. ## Das eigene Unternehmen auf eine Due Diligence vorbereiten Gründer können dieselbe Prüfung vor einer Runde für ihre eigene Plattform beauftragen. Ziel ist, Lücken zu finden, solange noch Zeit bleibt, sie zu schließen oder zu erklären. Hilfreich sind ein datiertes Architekturdiagramm, ein Abhängigkeitsinventar, Zugänge in Firmenaccounts, Release- und Incident-Aufzeichnungen und bei KI-Produkten versionierte Evaluationsergebnisse. Kommt das Produkt aus einem KI-Builder, lies zuerst [Due Diligence für Lovable-, Bolt- und Replit-Apps](/de/blog/lovable-bolt-replit-app-due-diligence/). // beweise ## Prüfarbeit in bestehenden Projekten Keiner dieser Fälle ist eine formale Due Diligence für Investoren oder M&A. Cedars dokumentiert ein technisches Assessment mit Architektur- und Anforderungsdokumentation, gezieltem Source-Review, einer abgegrenzten KI-Prüfung und priorisierten Maßnahmen mit Kriterien für die Nachprüfung. Polity dokumentiert eine nachvollziehbare Analyse, die Behebungsbedarf über sieben Services erkannt und priorisiert hat. Soundromeda dokumentiert Risiko-Triage und Härtung eines Prototyps, bevor Förderkomitees den Build begutachtet haben. Die Fälle zeigen die Prüfmethode, kein Due-Diligence-Ergebnis. ### [Cedars](/de/case-studies/cedars/) - **Status:** Live - **Ergebnis:** Prüfgrundlage - Architektur, Anforderungen, Assets und Verantwortlichkeiten für die Prüfung strukturiert. - **Zusammenfassung:** Dokumentationsstrukturen, gezielte Codeprüfungen und ein abgegrenztes KI-Assessment gaben Cedars eine priorisierte Grundlage für … - **Stack:** PHP, JavaScript, Python ### [Polity](/de/case-studies/polity/) - **Status:** Live - **Ergebnis:** 7 Services - Vereinheitlichtes Testen - **Zusammenfassung:** 1,5 Jahre QA-Eigentümerschaft über sieben Services und mehrere Vendoren. Qualität blieb durch jeden Refactor lieferbar. - **Stack:** React, Java/Kotlin, Go ### [Soundromeda](/de/case-studies/soundromeda/) - **Status:** Live - **Ergebnis:** Produktion - Vibe-Coded → gehärtet - **Zusammenfassung:** QA-geführtes Härten brachte einen Vibe-Coded-Game-Prototypen in einen Zustand, den Förderkommissionen unterstützten. Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert. ## Fragen vor dem Start ### Ist das eine rechtliche oder finanzielle Due Diligence? Nein. Wir prüfen die Software, ihre Auslieferung und ihren Betrieb. Verträge, Rechteübertragungen, Lizenzen, Steuern und Finanzzahlen bleiben bei deinen Anwälten und Finanzberatern. Berührt ein technischer Befund ihre Arbeit, markiert der Bericht das für sie, ohne rechtliche Schlussfolgerung. ### Garantiert der Bericht eine Bewertung oder einen Deal-Ausgang? Nein. Der Bericht beschreibt die technischen Risiken, die wir im vereinbarten Umfang gefunden haben, und die Belege dafür. Wie sich das auf Preis, Konditionen oder die Entscheidung auswirkt, entscheidest du mit deinen Beratern. ### Wie lange dauert es und was kostet es? Das hängt von der Größe des Systems, der gewünschten Tiefe und davon ab, wie schnell Zugriffe freigegeben werden. Nach einem kurzen Scoping-Gespräch vereinbaren wir Umfang, Zeitplan und Fixpreis in einem unterschriebenen Leistungsvertrag. ### Welche Zugriffe braucht ihr? Lesezugriff auf Repositories, Infrastruktur-Konfiguration und Datenraum sowie Zeit mit den Leuten, die das System bauen und betreiben. Fehlt ein Zugriff, nennt der Bericht, welche Schlussfolgerungen dadurch eingeschränkt sind. ### Könnt ihr das, was ihr findet, auch beheben? Ja, als eigener Auftrag nach dem Bericht und nur, wenn du das willst. Besteht die Möglichkeit, dass wir ein Angebot für die Behebung abgeben, legen wir das vor Beginn offen, damit du die Unabhängigkeit der Befunde einschätzen kannst. ## Der passende nächste Schritt - [Codebasis übernehmen und stabilisieren](/de/services/software-takeover/) - [Unabhängige Release-Tests](/de/services/software-quality-assurance/) - [Die laufende Umgebung härten](/de/services/cloud-security/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" } ] } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/de/services/technical-due-diligence/#service", "@type": "Service", "areaServed": [ { "@type": "Country", "name": "Austria" }, { "@type": "Place", "name": "Worldwide" } ], "category": "Training & Beratung", "dateModified": "2026-10-30", "description": "Unabhängige technische Due Diligence zu Code, Architektur, Security, Delivery und technischen Schulden. Ein schriftlicher Risikobericht mit Schweregrad, Belegen und Lösungswegen.", "name": "Technische Due Diligence für Investoren & Käufer", "provider": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "serviceType": "Technische Due Diligence", "url": "https://wavect.io/de/services/technical-due-diligence/" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/overview/", "name": "Leistungen", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/overview/#workshops", "name": "Training & Beratung", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/services/technical-due-diligence/", "name": "Technische Due Diligence", "position": 4 } ] }, { "@id": "https://wavect.io/de/services/technical-due-diligence/#webpage", "@type": "WebPage", "dateModified": "2026-10-30", "description": "Unabhängige technische Due Diligence zu Code, Architektur, Security, Delivery und technischen Schulden. Ein schriftlicher Risikobericht mit Schweregrad, Belegen und Lösungswegen.", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "mainEntity": { "@id": "https://wavect.io/de/services/technical-due-diligence/#service" }, "name": "Technische Due Diligence für Investoren & Käufer", "url": "https://wavect.io/de/services/technical-due-diligence/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Wir prüfen die Software, ihre Auslieferung und ihren Betrieb. Verträge, Rechteübertragungen, Lizenzen, Steuern und Finanzzahlen bleiben bei deinen Anwälten und Finanzberatern. Berührt ein technischer Befund ihre Arbeit, markiert der Bericht das für sie, ohne rechtliche Schlussfolgerung." }, "name": "Ist das eine rechtliche oder finanzielle Due Diligence?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. Der Bericht beschreibt die technischen Risiken, die wir im vereinbarten Umfang gefunden haben, und die Belege dafür. Wie sich das auf Preis, Konditionen oder die Entscheidung auswirkt, entscheidest du mit deinen Beratern." }, "name": "Garantiert der Bericht eine Bewertung oder einen Deal-Ausgang?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Das hängt von der Größe des Systems, der gewünschten Tiefe und davon ab, wie schnell Zugriffe freigegeben werden. Nach einem kurzen Scoping-Gespräch vereinbaren wir Umfang, Zeitplan und Fixpreis in einem unterschriebenen Leistungsvertrag." }, "name": "Wie lange dauert es und was kostet es?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Lesezugriff auf Repositories, Infrastruktur-Konfiguration und Datenraum sowie Zeit mit den Leuten, die das System bauen und betreiben. Fehlt ein Zugriff, nennt der Bericht, welche Schlussfolgerungen dadurch eingeschränkt sind." }, "name": "Welche Zugriffe braucht ihr?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja, als eigener Auftrag nach dem Bericht und nur, wenn du das willst. Besteht die Möglichkeit, dass wir ein Angebot für die Behebung abgeben, legen wir das vor Beginn offen, damit du die Unabhängigkeit der Befunde einschätzen kannst." }, "name": "Könnt ihr das, was ihr findet, auch beheben?" } ], "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".faq-question", ".faq-answer" ] } } ```