Eine technische Due Diligence ist die Prüfung, die ein Investor, ein Käufer oder ein Beirat vor einer Finanzierungsrunde oder einem Verkauf beauftragt, um festzustellen, ob Software und Engineering-Team eines Unternehmens den Plan tragen können, für den das Geld gedacht ist: Architektur, Sicherheit und Datenschutz, Codequalität, Infrastruktur, Lieferprozess, Dokumentation, die Menschen, von denen alles abhängt, und die Lizenzen, auf denen es aufbaut. Cloudnonic arbeitet auf beiden Seiten. Gründer, die eine Runde vorbereiten, bringen wir so weit, dass die Prüfung eine Leseübung ist, mit Dokumentation, die während des Aufbaus entsteht und nicht in der Woche davor. Für Investoren und Käufer führen wir die Prüfung als unabhängige Senior-Entwickler durch und berichten, was die Plattform tragen kann und was nicht.
Die acht Bereiche, die der technische Berater eines Investors durchgeht, und was jeder davon zeigen muss. Dieselbe Liste ist unsere Checkliste, wenn wir ein Unternehmen vorbereiten, und unsere Berichtsstruktur, wenn wir eines prüfen.
Ob die Struktur des Systems zu den nächsten drei Jahren des Plans passt: Mandantenfähigkeit, Servicegrenzen, die Teile, die skalieren müssen, und die Aufzeichnung, warum es so gebaut wurde.
Zugriffskontrolle, Verschlüsselung, Audit-Trails, Datenresidenz und Einwilligungsverwaltung, als Konzepte aufgeschrieben und auf die Regulierung abgestimmt, unter der das Unternehmen arbeitet.
Lesbarer Code mit einem Review-Prozess, automatisierte Tests, die in der Pipeline laufen, und Abhängigkeiten, die aktuell sind und gescannt werden.
Wem die Cloud-Konten gehören, ob die Infrastruktur als Code definiert ist, was sie pro Monat und pro Kunde kostet, und wann die Wiederherstellung zuletzt getestet wurde und wie lange sie gedauert hat.
Wie eine Änderung vom Ticket in die Produktion kommt: Review, Staging, Freigabe, Rollback und Release-Rhythmus, mit dem Nachweis, dass es tatsächlich so läuft.
Architecture Decision Records, Runbooks, Onboarding-Notizen und ein Datenmodell, das ein neuer Entwickler oder ein Prüfer ohne Meeting lesen kann.
Was passiert, wenn der eine Entwickler geht, der das Deployment kennt, und ob dieses Wissen im Repository liegt oder in einem Kopf.
Open-Source-Lizenzen im Abhängigkeitsbaum, Eigentum an Code, den Freelancer und Agenturen geschrieben haben, und die Bedingungen der Drittanbieter, von denen das Produkt abhängt.
GoMedicus kam von einem Scoping-Workshop im Januar 2025 zu einer im August 2026 unterzeichneten Series A. Als die Runde eingeworben wurde, bestand die Plattform eine technische Due Diligence auf Basis der Dokumentation, die das Engineering-Team während des Aufbaus erstellt hatte: Architekturentscheidungen, Sicherheits- und Datenschutzkonzepte, Prozessdokumentation. Cloudnonic ist weiterhin das Engineering-Team der Plattform.
NestJS
Next.js
PostgreSQL
AWS
Terraform
Eine Vorbereitung läuft als eingebettetes Engagement: ein oder zwei Senior-Entwickler für einen begrenzten Zeitraum in Ihren Repositories, Cloud-Konten und Pipelines, zusammen mit denen, die das System heute verantworten, Ihrem eigenen Team oder der Agentur, die es gebaut hat. Wir brauchen Lesezugriff auf Code und Infrastruktur, eine Stunde mit den Menschen, die es gebaut haben, und den Plan, auf dem die Runde beruht. Eine Prüfung für einen Investor wird aus dem Datenraum heraus zugeschnitten, unter NDA durchgeführt und an den Investor berichtet; die Befunde teilen wir am Ende mit dem Team des Unternehmens. Alles, was wir sehen, bleibt unter der Vertraulichkeit, die die Parteien vereinbart haben, und wir prüfen keine Unternehmen, deren Engineering wir selbst verantworten.
Ein eingebettetes Team · Was das verhindert: Einen sechsmonatigen Einstellungsprozess für eine Fähigkeit, die Sie dieses Quartal brauchen, und einen Dienstleister, der außerhalb Ihres Prozesses arbeitet und keine Spur in Ihren Repos hinterlässt.
Die zwei Zusammenarbeitsmodelle →Pro Projekt gewählt. Wir nehmen, was Ihr Team nach uns betreiben kann, nicht was gerade in Mode ist.
OpenAPITerraform
GitHub ActionsGitHub ActionsTerraformOpenAPIDer Datenraum öffnet, nichts ist aufgeschrieben, und das Team verbringt die Wochen vor der Runde damit, Architekturdiagramme und Sicherheitsrichtlinien aus dem Gedächtnis zu produzieren, statt auszuliefern.
Eine Prüfung, die sich wie rekonstruiert liest, eine verzögerte Runde und ein Team, das im sichtbarsten Monat der Unternehmensgeschichte aufgehört hat zu liefern.
Dokumentation entsteht während des Aufbaus: Architekturentscheidungen werden festgehalten, wenn sie fallen, Sicherheitskonzepte mit dem Feature geschrieben, der Prozess von der Pipeline dokumentiert, die ihn ausführt. Das Paket ist ein Nebenprodukt, kein Projekt.
Deployment, Secrets und Wiederherstellungsverfahren liegen bei einem Entwickler, oft einem Freelancer, und der Prüfer fragt, was passiert, wenn diese Person geht.
Ein Schlüsselpersonen-Befund, der sich wie ein Risiko für das gesamte Investment liest, und ein Halteprämie, die unter Druck verhandelt wird.
Infrastruktur als Code, Runbooks im Repository, ein Wiederherstellungsverfahren, das in einer Übung durchlaufen wurde, und eine zweite Person, die es ausgeführt hat. Schlüsselpersonenrisiko ist ein Problem von Eigentum und Dokumentation, und so behandeln wir es.
Sicherheit ist ein Dokument, das für den Prüfer beantwortet wird, und keine Eigenschaft des Systems; der erste Code-Read oder Penetrationstest findet die Lücke zwischen beidem.
Befunde, die Architekturänderungen brauchen, während die Runde offen ist, und ein Glaubwürdigkeitsproblem, das die Korrektur überdauert.
Zugriffskontrolle, Audit-Logging, Verschlüsselung und Datenresidenz sind Architekturentscheidungen, dokumentiert, wenn sie fallen, und im Code und im Cloud-Konto nachweisbar statt in einer Tabelle.
Die Prüfung des Investors selbst dauert meist zwei bis vier Wochen vom Zugang zum Datenraum bis zum Bericht. Die Vorbereitung hängt vom Stand der Dokumentation ab: Ein Team, das seine Entscheidungen festgehalten hat, braucht Tage, um das Paket zusammenzustellen; eine Plattform, bei der nichts aufgeschrieben ist, braucht vier bis acht Wochen, die meiste Zeit davon zum Schließen von Lücken, nicht zum Schreiben. Eine Prüfung, die wir für einen Investor durchführen, liefern wir in der Regel innerhalb von drei Wochen.
Ja, und das ist der Normalfall. Wir prüfen Code, Infrastruktur und Dokumentation so, wie sie sind, arbeiten mit der Agentur oder den Entwicklern, die es gebaut haben, soweit sie noch erreichbar sind, und halten fest, was wir finden, ohne etwas um seiner selbst willen neu zu schreiben. Die Lückenliste sagt, was sich vor der Runde zu beheben lohnt und was warten kann.
Ja, als unabhängige Senior-Entwickler unter NDA, mit einem schriftlichen Bericht zu Architektur, Sicherheit, Infrastruktur, Lieferprozess und Teamrisiko, gemessen an dem Plan, auf dem die Runde beruht. Wir prüfen keine Unternehmen, deren Engineering wir selbst verantworten; dort stehen wir auf der Seite der Gründer und sagen das auch.
Lesezugriff auf die Repositories und die Cloud-Konten, die vorhandene Dokumentation, so unvollständig sie ist, den Plan oder das Deck, auf dem die Runde beruht, und eine Stunde mit den Menschen, die das System gebaut haben. Vor alledem unterschreiben wir ein NDA.
Nein. Eine technische Due Diligence ist breiter: Sie beurteilt, ob die gesamte Plattform und das Team den Investitionsplan tragen können, und Sicherheit ist einer ihrer acht Bereiche. Wenn der Prüfer oder der Plan einen Penetrationstest verlangt, scopen wir ihn mit einem spezialisierten Partner und nehmen das Ergebnis ins Paket auf.
Jede Leistung auf dieser Seite wird mit unserem AI-Native-Prozess geliefert: Spezifikationen als Quelle der Wahrheit, Agenten in der Pipeline und ein namentlich verantwortlicher Entwickler, der auf Staging freigibt.
Wie wir mit KI entwickeln →