Bei einer Software‑Investition habe ich in meiner Beratungspraxis gelernt: Die erste Due Diligence entscheidet oft darüber, ob ein Projekt später reibungslos skaliert oder frühzeitig scheitert. Ich stelle Ihnen hier die acht wichtigsten Fragen vor, die ich selbst zuerst stelle — und wie ich die Antworten bewerte. Diese Fragen helfen Ihnen, technische, organisatorische und geschäftliche Risiken rasch zu erkennen und realistische Erwartungen zu setzen.
Warum diese acht Fragen?
Eine digitale Due Diligence darf nicht in technischem Detailwahn versinken, aber sie muss auch mehr als Marketingversprechen prüfen. Ich fokussiere deshalb auf Bereiche, die später entweder Kosten, Verzögerungen oder Limitierungen verursachen: Architektur, Betrieb, Sicherheit, Daten, Integrationen, Produktroadmap, Team und Lizenzmodell. Die Antworten geben schnelle Indikatoren für Reifegrad, Transparenz und Risiko.
Die acht Fragen (mit Erklärung, was ich erwarte)
- Wie ist die Software-Architektur aufgebaut und welche Skalierungsannahmen wurden getroffen?
Ich will verstehen: Monolith oder Microservices? Multitenancy oder einzelne Instanzen? Welche Komponenten sind kritisch? Gute Antworten beinhalten Diagramme (z. B. Sequenz- und Deploy‑Diagrams), Lastannahmen und konkrete Limitwerte. Achtung bei vagen Aussagen wie „skaliert horizontal“ ohne Benchmark‑Daten.
- Wie läuft der Betrieb (DevOps, CI/CD, Monitoring, SLA) und wer ist dafür verantwortlich?
Ein ausgereifter Betrieb reduziert Produktionsrisiken. Ich frage nach CI/CD‑Pipelines (z. B. GitHub Actions, GitLab, Jenkins), Infrastructure as Code (Terraform, Ansible), Monitoring (Prometheus, Grafana, Datadog) und dokumentierten SLAs. Rote Flaggen: Keine automatisierten Deploys, keine Alert‑Playbooks, Verantwortlichkeiten sind unklar.
- Welche Sicherheits‑ und Compliance‑Maßnahmen sind implementiert?
Sicherheit ist nicht nachträglich. Wichtig sind OWASP‑Scans, Penetrationstests, Verschlüsselung von Daten at rest/in transit, IAM‑Konzept (RBAC, SSO), sowie Compliance‑Nachweise (DSGVO, ISO 27001, SOC2). Wenn das Team keine Rolle für Sicherheit nennt oder Audits fehlen, ist Vorsicht angebracht.
- Wie werden Datenmodell, Datenqualität und Datenmigration gehandhabt?
Ich verlange ein Datenmodell (ERD), Regeln zur Datenvalidierung und Beispiele aus Migrationen. Fragen Sie auch nach Exportformaten, Retention‑Policies und Backup‑Strategie. Problematisch sind proprietäre Datenformate ohne klare Exportwege oder fehlende Migrationswerkzeuge.
- Welche Integrationen existieren und wie offen ist die Plattform (APIs, Webhooks, SDKs)?
In der Praxis scheitern Projekte oft an mangelnden Schnittstellen. Ich prüfe Dokumentation, API‑Versionierung, Rate Limits und Beispiele für erfolgreiche Integrationen (z. B. mit SAP, Salesforce, HubSpot). Fehlende oder schlecht dokumentierte APIs sind ein ernstes Risiko.
- Wie sieht die Produktroadmap, Release‑Cadence und technische Schuld aus?
Die Roadmap zeigt Prioritäten und Innovationsfähigkeit. Ich prüfe, wie oft Releases kommen, ob Backlog‑Items nach technischer Schuld sortiert werden und ob Refactorings geplant sind. Ein hohes Maß an technischer Schuld ohne klaren Abtrag‑Plan ist ein Wertvernichter.
- Wer sind die Schlüsselpersonen im Entwicklungsteam und wie ist die Teamstabilität?
Know‑how hängt an Personen. Ich schaue auf Teamgröße, Rollen (Architekt, DevOps, Security), Fluktuation und externe Abhängigkeiten (Fremdleister). Bei „single‑point‑of‑failure“ Profilen sollte verhandelt werden, z. B. Übergangspläne oder Wissensdokumentation.
- Wie ist das Lizenz‑/Pricing‑Modell und welche versteckten Kosten sind zu erwarten?
Neben Lizenzkosten bitte Betriebskosten, Integrationsaufwand, Migration, Trainings und Support‑Gebühren beurteilen. Manche SaaS‑Modelle klingen günstig, erfordern aber teure Customizations oder zusätzliche Module. Ich verlange Total Cost of Ownership (3–5 Jahre) als Schätzung.
Wie bewerte ich die Antworten praktisch?
Ich nutze ein einfaches Ampel‑Schema (Grün/Gelb/Rot) — aber mit konkreten Belegen. Für jede Frage fordere ich Dokumente an:
- Architekturdiagramme, Lasttests, Benchmarks
- CI/CD‑Pipelines, Deployment‑Runbooks, Monitoring‑Screenshots
- Sicherheitsberichte, Audit‑Zertifikate, Incident‑Logs (anonymisiert)
- Datenexport‑Spezifikationen, Migrationsplaybooks, Beispiel‑Backups
- API‑Docs, SDK‑Repositories, Kundenreferenzen für Integrationen
- Roadmap‑Dokument, Release‑Notes, Tech‑Debt‑Log
- Org‑Chart, CVs/LinkedIn‑Profile der Schlüsselpersonen
- Preisblätter, TCO‑Rechnung, Beispiele realer Kundenkosten
Ohne diese Artefakte stoppe ich die Due Diligence oder qualifiziere das Investment deutlich niedriger. Transparenz ist für mich der beste Indikator für Seriosität.
Rote Flags und wie ich damit umgehe
- Vage Antworten oder Verweigerung von Dokumenten: Setze eine Frist für die Lieferung oder verhandle Garantien (z. B. Escrow, Milestone‑Payments).
- Hohe technische Schuld ohne Plan: Fordere einen Refactor‑Plan mit Aufwandsschätzung oder Preisnachlass für die technische Risikoübernahme.
- Abhängigkeit von einzelnen Entwicklern: Verlange Knowledge‑Transfer, Dokumentation und ggf. Vertragsklauseln zur Personalstabilität.
- Kein Backup/Recovery Konzept: Unmittelbar Verhandlungspunkt — kein Deployment in Produktivumgebung ohne SLA für Backups.
Beispiel: Kurz‑Checkliste für ein Erstgespräch
| Bereich | Schnellfrage | Erwartetes Artefakt |
|---|---|---|
| Architektur | Monolith oder Microservices? | Deploy‑Diagramm, Lasttest |
| Betrieb | CI/CD und Monitoring vorhanden? | Pipeline‑Screenshots, Alert‑Playbook |
| Sicherheit | PenTest oder ISO/SOC2? | Sicherheitsreport, Zertifikate |
| Daten | Export möglich? | Export‑Spezifikation, Backup‑Plan |
| Integration | Offene APIs vorhanden? | API‑Docs, Integrationsfälle |
| Team | Key‑People und Fluktuation? | Org‑Chart, CVs |
| Lizenz | Welche Zusatzkosten? | TCO‑Schätzung |
Praktischer Tipp aus der Beratungspraxis
Fordern Sie jeweils eine kurze Demo, in der das Team live eine kritische Funktion zeigt — nicht nur Slides. Bei mir zahlt sich das aus: Ich erkenne oft Diskrepanzen zwischen Produktmarketing und Realität innerhalb der ersten 15 Minuten. Bei größeren Deals empfehle ich, einen kurzen technischen Proof of Concept mit definierten Akzeptanzkriterien zu vereinbaren (z. B. Datenimport mit 1 Mio. Datensätzen innerhalb X Minuten).
Wenn Sie möchten, kann ich Ihnen eine anpassbare Checkliste und ein Template für die Technische Due Diligence zur Verfügung stellen — direkt anpassbar für Ihre Branche (SaaS, On‑Prem, Embedded). Auf Hgd Team (https://www.hgd-team.de) teile ich regelmäßig solche Tools und Praxisbeispiele, damit Sie Entscheidungen schneller und sicherer treffen.
