Code-Audit vor der Investition: Was geprüft wird und wie Sie sich vorbereiten

Ein Code-Audit vor der Investition ist eine unabhängige Prüfung der Software eines Unternehmens, bevor Geld fliesst. Geprüft wird, ob der Code funktioniert, ob er sicher und wartbar ist und ob das Unternehmen wirklich besitzt und nutzen darf, was es gebaut hat. Investor:innen und Käufer:innen lassen ein Audit durchführen, um das Risiko zu bewerten. Gründer:innen lassen es vorher selbst machen, damit sie im Bericht keine Überraschung erleben.

Dieser Leitfaden deckt beide Seiten ab. Er erklärt, worauf eine prüfende Person schaut, wie die Arbeit abläuft, was Gründer:innen vorbereiten sollten, wie lange es dauert und was mit den Befunden geschieht. Er behandelt auch die juristische Seite in der Schweiz, wo Eigentum und Lizenzen ebenso wichtig sind wie die Codequalität.

Kurz zusammengefasst

• Ein Code-Audit vor der Investition prüft vier Dinge: Architektur, Codequalität, Sicherheit und das rechtliche Nutzungsrecht an der Software (Eigentum und Open-Source-Lizenzen).
• In der Schweiz legal due diligence on software focuses on ownership and licences, während die tiefere Analyse des Codes typischerweise Teil der technischen Prüfung ist.
• Wer sich zuerst selbst prüfen lässt, behält die Deutungshoheit: Günstige Probleme werden behoben, teure erklärt, bevor Investor:innen sie finden.
• Bereiten Sie Zugriff auf die Repositories, eine Architekturübersicht, eine Liste aller Abhängigkeiten und Lizenzen sowie Nachweise vor, dass alle Mitwirkenden ihre Rechte abgetreten haben.
• Sortieren Sie die Befunde in drei Gruppen: jetzt beheben, mit dem Investorengeld beheben, bewusst akzeptieren mit einem Plan.

Warum Investor:innen ein Code-Audit verlangen

Software ist selten nur Code. Ihr Wert hängt an Rechten: Wem sie gehört, wer sie kopieren darf und welche Dritten Ansprüche darauf erheben könnten. Die Schweizer Anwaltskanzlei Walder Wyss beschreibt diesen Zusammenhang in ihrem legal due diligence on software focuses on ownership and licences. Wer die Technologie versteht, weiss, welche Rechte vorhanden sein sollten. Die Prüfung von Lizenzen, Eigentum, Rechtsstreitigkeiten und Regulierung zeigt dann, ob diese Rechte nutzbar und belastbar sind.

Deshalb ist ein Audit mehr als eine Qualitätskontrolle. Investor:innen wollen drei Dinge wissen:

1. Funktioniert es so, wie behauptet? Eine Demo kann vieles verbergen. Die Codebasis zeigt, was wirklich da ist.
2. Hält es Wachstum aus? Ein Produkt für 200 Nutzer:innen kann bei 20'000 zusammenbrechen, und der Neubau kostet Geld, das die Investor:innen aufbringen müssen.
3. Gehört es dem Unternehmen wirklich? Code, den eine freiberufliche Person ohne Rechteabtretung geschrieben hat, oder eine Bibliothek mit einschränkender Lizenz kann den Besitz des Unternehmens schmälern.

Für Gründer:innen beantwortet dasselbe Audit eine leisere Frage: Wie viel der Finanzierung fliesst in die Reparatur der Vergangenheit statt in den Bau der Zukunft?

Was ein Code-Audit untersucht

Ein gutes Audit ist eine Standortbestimmung, keine Fehlerjagd. Die prüfende Person betrachtet das System aus mehreren Blickwinkeln, und jeder davon entspricht einem Risiko, das Investor:innen interessiert.

Architektur und Skalierbarkeit

Die prüfende Person liest, wie das System aufgebaut ist: Services, Datenbanken, Hosting, Warteschlangen, APIs von Dritten. Sie fragt, ob der Entwurf zur Reife des Produkts passt. Ein Produkt in der Seed-Phase braucht keine Microservices, und ein Monolith ist kein Mangel. Die Warnzeichen sind andere: ein einzelner Server, den niemand neu aufsetzen kann, eine Datenbank ohne getestete Sicherung oder Logik, die so verstreut ist, dass jede Änderung zehn Stellen betrifft.

Codequalität und Wartbarkeit

Hier nimmt die prüfende Person Stichproben im Code. Ist er lesbar? Gibt es automatisierte Tests, und laufen sie durch? Wie lange braucht eine neu dazugestossene Entwicklerin, um das Projekt lokal zum Laufen zu bringen? Code, den nur die Autorin oder der Autor versteht, ist ein geschäftliches Risiko, weil er das Unternehmen an eine einzelne Person bindet.

Sicherheit

Die Sicherheitsprüfung umfasst Anmeldung, Zugriffsrechte, Umgang mit Geheimnissen, Prüfung von Eingaben sowie veraltete Komponenten mit bekannten Schwachstellen. Sie schaut auch, wie Personendaten gespeichert werden. Wenn Sie in der Schweiz Kundendaten bearbeiten, will die prüfende Person sehen, dass Sie das Datenschutzgesetz mitgedacht haben, auch wenn das Audit selbst kein Rechtsgutachten ist. Ein Sicherheitsbefund bringt selten einen Deal zu Fall. Verborgene Befunde, die spät auftauchen, hingegen oft.

Abhängigkeiten und Open-Source-Lizenzen

Moderne Produkte bestehen grösstenteils aus fremdem Code. Jede Bibliothek bringt eine Lizenz mit, und manche Lizenzen, sogenannte Copyleft-Lizenzen, können Sie verpflichten, Ihren eigenen Code zu veröffentlichen, wenn Sie ihn auf bestimmte Weise kombinieren. Laut Walder Wyss stellen Schweizer Zielunternehmen üblicherweise eine genaue Liste der Open-Source-Software und der geltenden Lizenzen bereit, damit legal due diligence on software focuses on ownership and licences. Diese Liste bereitzuhalten, ist eine der einfachsten Arten, vorbereitet zu wirken.

Eigentum und geistiges Eigentum

Die prüfende Person oder die Jurist:innen an ihrer Seite kontrollieren, ob dem Unternehmen gehört, was es behauptet. Derselbe Leitfaden von Walder Wyss hält fest: Die Software-Due-Diligence erfasst, welche Software das Zielunternehmen besitzt und nutzt, bestätigt das Eigentum, prüft die Lizenzen und beurteilt, ob sie rechtlich vermarktet werden darf. In der Praxis müssen Sie zeigen, wer den Code geschrieben hat: Angestellte, Auftragnehmer:innen, Agenturen oder eine Mitgründerin, die gegangen ist. Für jede dieser Personen braucht es eine schriftliche Vereinbarung, die die Rechte an das Unternehmen überträgt oder lizenziert.

Team und Abhängigkeit von Schlüsselpersonen

Zu einem Code-Audit gehört oft ein kurzes Gespräch mit der leitenden Entwicklerin oder dem leitenden Entwickler. Die Frage dahinter ist einfach: Wenn diese Person morgen geht, kann jemand anders weitermachen? Dokumentation, Deployment-Skripte und eine zweite Person, die ein Release ausliefern kann, beantworten sie gut.

KI-generierter Code

Immer mehr Teams nutzen Programmierassistenten. Das ist in Ordnung, doch Prüfende fragen zunehmend, wie viel des Codes generiert wurde, ob ein Mensch ihn geprüft hat und ob Tests ihn abdecken. Ungeprüfter generierter Code wirkt meist aufgeräumt und verbirgt doppelte Logik oder schwache Fehlerbehandlung. Seien Sie bereit zu erklären, wie Ihr Team diese Werkzeuge einsetzt.

Was das Audit nicht abdeckt

Klären Sie die Erwartungen früh, denn Gründer:innen halten das Audit manchmal für ein Urteil über das Geschäft.

• Es ist kein Rechtsgutachten. Walder Wyss hält fest, dass Schweizer Zielunternehmen für die rechtliche Due Diligence üblicherweise keine Code-Scans bereitstellen, obwohl die technische Due Diligence eine legal due diligence on software focuses on ownership and licences umfassen kann. Jurist:innen lesen Verträge und Lizenzen, Entwickler:innen lesen Code. Ein sorgfältiger Deal nutzt beides.
• Es ist kein Penetrationstest. Eine Code-Prüfung liest den Quellcode. Ein Penetrationstest greift das laufende System an. Manche Investor:innen verlangen beides, und das Zweite ist eine eigene Arbeit.
• Es ist keine Markteinschätzung. Hinter einer makellosen Codebasis kann ein Produkt stehen, das niemand will.
• Es kann nicht beweisen, dass es keine Probleme gibt. Geprüft wird stichprobenartig. Der Bericht hält fest, was gesehen wurde, wie tief geschaut wurde und was nicht erreicht wurde.

Wie ein Code-Audit abläuft

Das genaue Vorgehen unterscheidet sich je nach prüfender Person, doch der Bogen ist meist derselbe.

1. Umfang festlegen. Sie einigen sich auf das Ziel (eine Seed-Runde, eine Serie A, eine Übernahme), auf die einbezogenen Repositories und auf die Prüftiefe. Ein Pre-Seed-Produkt mit einem Repository braucht einen anderen Aufwand als eine Plattform mit einem Dutzend Services.
2. Zugang und Einrichtung. Die prüfende Person erhält lesenden Zugriff auf die Repositories, das Ticketsystem, die Deployment-Konfiguration und idealerweise eine Staging-Umgebung. Unter einer Geheimhaltungsvereinbarung braucht sie nie Zugangsdaten zur Produktion.
3. Automatisierte Analyse. Werkzeuge suchen nach bekannten Schwachstellen in Abhängigkeiten, nach durchgesickerten Geheimnissen, nach Lizenztypen, Testabdeckung und Komplexität des Codes. Das ergibt schnell eine breite Ausgangslage.
4. Manuelle Prüfung. Eine erfahrene Person liest die kritischen Pfade: Anmeldung, Zahlungen, Datenzugriff, die zentrale Geschäftslogik. Werkzeuge können nicht beurteilen, ob ein Entwurf sinnvoll ist, und hier entstehen die meisten echten Befunde.
5. Gespräche. Ein Austausch mit der technischen Leitung füllt die Lücken: warum Entscheidungen so gefallen sind, was das Team bereits als kaputt kennt und was geplant ist.
6. Bericht und Besprechung. Ergebnis ist ein schriftlicher Bericht mit Befunden, geordnet nach Schweregrad und Aufwand, gefolgt von einem Gespräch, in dem Sie nachhaken und klären können.

Ein brauchbarer Bericht trennt was falsch ist von was die Behebung kostet. Ohne Aufwandschätzungen raten Investor:innen, und Schätzungen fallen dann meist pessimistisch aus.

So bereiten Sie sich auf das Audit vor

Vorbereitung verkürzt die Prüfung und verbessert Ihr Bild. Nehmen Sie sich eine Woche für Folgendes.

Technische Unterlagen

• Lesender Zugriff auf alle Repositories, jeweils mit einem klaren README.
• Ein einseitiges Architekturdiagramm: Komponenten, Hosting, Dienste von Dritten, Datenflüsse.
• Eine Liste aller Abhängigkeiten und ihrer Lizenzen, inklusive Build-Werkzeuge.
• Nachweise für Sicherungen und eine getestete Wiederherstellung.
• Aktuelle Test- und Deployment-Ergebnisse sowie eine Liste bekannter Fehler und technischer Schulden.
• Eine Liste, wer Zugriff auf Produktionssysteme hat und wie dieser Zugriff entzogen wird, wenn jemand geht.

Rechtliche Unterlagen und Eigentumsnachweise

• Anstellungs- und Auftragsverträge, die zeigen, dass die Rechte am Code dem Unternehmen gehören.
• Vereinbarungen mit jeder Agentur oder freiberuflichen Person, die einen Teil des Produkts gebaut hat.
• Belege zu Code, der aus einem anderen Projekt oder von einer früheren Anstellung stammt. Klären Sie das, bevor jemand fragt.
• Nutzungsbedingungen der Dienste von Dritten, von denen Ihr Produkt abhängt.

Personen

• Legen Sie fest, wer die technischen Fragen beantwortet, und stellen Sie sicher, dass diese Person die Schwachstellen des Systems kennt. Investor:innen verzeihen bekannte Probleme. Sie verzeihen keine abgestrittenen.

Wenn Sie einen breiteren Überblick wollen, was Käufer:innen und Investor:innen über den Code hinaus prüfen: Diese due diligence checklist for brand owners behandelt die operative und finanzielle Seite der Investitionsreife.

Was ein Audit zutage fördert: häufige Befunde

Diese Muster tauchen bei jungen Produkten immer wieder auf.

Bereich	Typischer Befund	Warum es Investor:innen kümmert
Eigentum	Eine beauftragte Person baute die erste Version ohne Rechteabtretung	Das Unternehmen besitzt sein Kernprodukt womöglich nicht vollständig
Lizenzen	Eine Copyleft-Bibliothek steckt in proprietärem Code	Mögliche Pflicht, den Quellcode offenzulegen
Sicherheit	Geheimnisse im Repository eingecheckt, veraltete Pakete	Risiko eines Datenlecks und mögliche datenschutzrechtliche Folgen
Architektur	Ein Server, kein Ausfallschutz, manuelles Deployment	Ausfallzeiten und langsame Auslieferung, wenn das Team wächst
Wartbarkeit	Keine Tests, eine Autorin, keine Dokumentation	Abhängigkeit von Schlüsselpersonen und teure Einarbeitung
Anbieterbindung	Zentrale Logik an eine Agentur oder eine proprietäre Plattform gebunden	Wechselkosten und Abhängigkeitsfallen

Das meiste davon lässt sich beheben. Den Preis eines Deals verändert die Frage, ob die Gründer:innen davon wussten und einen Plan hatten.

Wie lange ein Code-Audit dauert und was die Kosten treibt

Es gibt keinen Standardpreis, und genannte Zahlen unterscheiden sich stark zwischen Anbietern und Ländern. Nehmen Sie darum keine einzelne Zahl für bare Münze. Vier Faktoren bestimmen Dauer und Kosten:

• Grösse der Codebasis. Mehr Repositories und mehr Sprachen bedeuten mehr Lesearbeit.
• Prüftiefe. Ein schneller automatisierter Scan ist günstig. Eine manuelle Prüfung der kritischen Pfade samt Gesprächen dauert länger.
• Regulierung. Wenn Sie Zahlungen, Gesundheitsdaten oder andere regulierte Informationen bearbeiten, erwarten Sie eine tiefere Sicherheits- und Compliance-Prüfung.
• Ihre Vorbereitung. Sauberer Zugang, Dokumentation und eine Liste der Abhängigkeiten sparen Tage. Die Suche nach Zugangsdaten und Erklärungen kostet welche.

Als grober Anhaltspunkt: Eine fokussierte Prüfung eines kleinen Produkts dauert Tage, eine vollständige Prüfung einer grösseren Plattform mehrere Wochen. Verlangen Sie von jedem Anbieter einen festen Umfang und eine schriftliche Schätzung, bevor die Arbeit beginnt, und fragen Sie, was der Bericht enthalten wird. Wenn der Zeitplan des Deals eng ist, sagen Sie das im ersten Gespräch, damit der Umfang entsprechend gesetzt wird.

Wer das Audit durchführen sollte

Wer das Audit macht, bestimmt mit, wie viel Gewicht es hat.

• Von den Investor:innen bestellte Prüfung. Unabhängig von Ihnen, aber Sie bestimmen weder Umfang noch Darstellung.
• Ihre eigene Vorprüfung. Durchgeführt von einer Entwicklerin oder einem Studio Ihrer Wahl, bevor das Team der Investor:innen anrückt. Das gibt Ihnen Zeit, Dinge zu beheben und Antworten vorzubereiten.
• Ihr eigenes Team. Besser als nichts, aber Investor:innen werten es ab, weil die Unabhängigkeit fehlt.

Für die meisten Gründer:innen ist eine unabhängige Vorprüfung mit anschliessender Prüfung durch die Investor:innen der stärkste Weg. Wenn die zweite Prüfung findet, was die erste bereits berichtet hat, wächst das Vertrauen.

Wählen Sie jemanden, der Software gebaut und ausgeliefert hat, nicht nur geprüft. Solche Leute wissen, welche Abkürzungen in Ihrer Phase vertretbar und welche gefährlich sind. Prüfen Sie zudem, dass kein Eigeninteresse am Ergebnis besteht, etwa eine Firma, die daran verdient, alles neu zu bauen, was sie kritisiert.

Befunde vor den Investitionsgesprächen beheben

Ein Bericht mit dreissig Befunden wirkt beängstigend. Eine Priorisierung macht daraus einen Plan.

1. Jetzt beheben: günstig und sichtbar. Durchgesickerte Geheimnisse ersetzen, verwundbare Pakete aktualisieren, fehlende Rechteabtretungen nachholen, die Liste der Abhängigkeiten und Lizenzen schreiben, ein README ergänzen. Das dauert Tage und räumt die einfachsten Einwände aus.
2. Mit der Finanzierung beheben: teuer, aber erklärbar. Eine Architektur neu aufbauen, Testabdeckung über das ganze Produkt ergänzen oder das Hosting migrieren. Versehen Sie jeden Punkt mit Kosten und Zeitplan und nehmen Sie ihn in die Mittelverwendung auf. Wer einen durchgerechneten Plan sieht, sieht Gründer:innen, die die Lage im Griff haben.
3. Bewusst akzeptieren mit Plan: geringes Risiko oder geringer Nutzen. Ein Teil der Schulden ist in Ihrer Phase vernünftig. Halten Sie schriftlich fest, warum Sie es so lassen und wann Sie es wieder anschauen.

Zwei Gewohnheiten helfen im Gespräch. Erstens: Legen Sie die wichtigsten Befunde selbst offen, bevor die Investor:innen fragen. Zweitens: Streiten Sie im Meeting nie über die Einstufung des Schweregrads, liefern Sie danach eine schriftliche Stellungnahme nach.

Betrifft ein Befund das Eigentum, etwa eine fehlende Abtretung einer früheren Auftragnehmerin, holen Sie eine Anwältin oder einen Anwalt dazu, bevor Sie diese Person kontaktieren. Das ist eine rechtliche Angelegenheit, und die Lösung ist ein unterzeichnetes Dokument, keine Codeänderung.

Wie Ampersand unterstützen kann

Ampersand ist ein kleines Zürcher Studio, in dem erfahrene Entwickler:innen vom ersten Gespräch bis zur Übergabe dabei bleiben. Wir bieten Audits und technische Due Diligence sowie Beratung durch Senior-Köpfe für Gründer:innen, die vor einer Runde oder einem Verkauf eine unabhängige Sicht auf ihre Software brauchen. Wenn die Befunde Arbeit nach sich ziehen, helfen wir auch bei Migration, Integrationen und laufendem Support. Sehen Sie sich unsere Preise und Zusammenarbeitsmodelle an oder werfen Sie einen Blick auf unsere bisherigen Arbeiten. Zur Einordnung: Unser Guidance-Plan kostet CHF 799 pro Monat, unser Support-Plan Run & monitor CHF 750 pro Monat.

Häufige Fragen

Wann sollte ich ein Code-Audit vor der Investition durchführen?

Zwei bis drei Monate, bevor Sie mit der Finanzierungsrunde oder mit Verkaufsgesprächen beginnen. So bleibt Zeit, günstige Befunde zu beheben und für den Rest einen durchgerechneten Plan zu schreiben. Als Investor:in planen Sie es nach dem Term Sheet oder der Absichtserklärung und vor der endgültigen Zusage.

Wer bezahlt das Audit?

Das hängt davon ab, wer es in Auftrag gibt. Eine von den Gründer:innen beauftragte Vorprüfung zahlt das Unternehmen. Investor:innen oder Käufer:innen zahlen ihre eigene Prüfung meist selbst, wobei die Kosten in manchen Deals geteilt oder in die Verhandlung eingepreist werden. Klären Sie das zu Beginn, ebenso, wem der Bericht gehört.

Muss ich Investor:innen vollen Zugriff auf meinen Code geben?

Nicht zwingend. Üblich ist lesender Zugriff unter einer Geheimhaltungsvereinbarung, oft beschränkt auf eine namentlich genannte Person und manchmal in einer kontrollierten Umgebung. Walder Wyss hält fest, dass legal due diligence on software focuses on ownership and licences für die rechtliche Due Diligence, Einschränkungen beim direkten Zugriff auf den Code sind also nicht ungewöhnlich. Eine schriftliche Zusammenfassung und eine Lizenzliste sind oft der erste Schritt.

Kann ein schlechtes Auditergebnis einen Deal stoppen?

Das kann vorkommen, meist aber nur, wenn Probleme verborgen, nicht offengelegt oder nicht behebbar sind. Über bekannte Punkte mit klaren Kosten und Zeitplan wird normalerweise verhandelt: eine Preisanpassung, eine Bedingung oder zurückgestellte Mittel für die Behebung. Lücken beim Eigentum und ernsthafte Lizenzkonflikte sind die Befunde, die einen Abschluss am ehesten aufhalten.

Ist ein Code-Audit dasselbe wie technische Due Diligence?

Nein. Das Code-Audit ist ein Teil der technischen Due Diligence. Die breitere Prüfung umfasst auch Team, Prozesse, Infrastruktur, Roadmap und manchmal Verträge mit Anbietern. Das Audit liefert die Belege hinter den technischen Schlussfolgerungen.

Quellen

• legal due diligence on software focuses on ownership and licences
• due diligence checklist for brand owners