Code-Audit vor der Abschlusszahlung: So prüfen Sie, was Ihr Dienstleister geliefert hat

Das Projekt ist fertig, sagt zumindest die Agentur. Der letzte Meilenstein ist als abgeschlossen markiert, die Einladung zur Abnahme liegt im Postfach, und die Abschlussrechnung folgt ein paar Tage später. Das ist der einzige Punkt in der Zusammenarbeit, an dem Sie noch Verhandlungsmacht haben. Sobald Sie die Abnahme unterschreiben und zahlen, ist der größte Teil dieser Macht weg. Der vernünftige Schritt ist, den Code vor der Abschlusszahlung zu prüfen, mit ein paar Stunden eigener Zeit oder ein paar Tagen externer Hilfe, und zu kontrollieren, was Ihr Dienstleister tatsächlich geliefert hat, nicht das, was im Angebot stand.

Für die erste Runde müssen Sie keine Zeile Code lesen. Sie müssen aber wissen, wonach Sie fragen und was eine fehlende Antwort in der Regel bedeutet.

Code vor der Abschlusszahlung prüfen, ohne eine Zeile zu lesen

Vier Fragen trennen eine saubere Übergabe von einem Problem, das Sie monatelang nicht entdecken.

Lässt sich das Projekt aus dem übergebenen Repository auf einer Maschine bauen, die es noch nie gesehen hat? Lassen Sie sich das vom Dienstleister beweisen. Ein sauberer Klon, ein dokumentierter Einrichtungsschritt und eine laufende Anwendung auf einer frischen Maschine sind das Minimum. Wenn die einzige funktionierende Kopie auf einem Laptop oder einem Server liegt, auf den außer dem Dienstleister niemand Zugriff hat, haben Sie die Software nicht wirklich erhalten. Sie haben eine Demo davon erhalten.

Laufen die Accounts auf den Namen Ihres Unternehmens? Domain-Registrar, Hosting-Anbieter, die Organisation in der Versionsverwaltung, bezahlte API-Keys, das E-Mail-Konto, mit dem sie registriert wurden. Es ist üblich und für sich genommen nicht böswillig, dass ein Freelancer oder eine Agentur diese während der Entwicklung schnell unter dem eigenen Account anlegt. Zum Problem wird es an dem Tag, an dem die Zusammenarbeit endet und Sie feststellen, dass die Hosting-Rechnung, die Domain oder das Repository selbst jemandem gehört, der auf Ihre E-Mails nicht mehr antwortet.

Gibt es überhaupt Testabdeckung, und laufen die Tests durch? Es geht nicht um Perfektion. Es geht um den Nachweis, dass jemand anderes als der ursprüngliche Autor diesen Code ändern kann, ohne stillschweigend etwas zu zerstören. Ein Projekt ohne Tests ist nicht automatisch kaputt, aber es ist ein Projekt, in dem jede künftige Änderung ein Ratespiel ist.

Reicht die Dokumentation aus, damit ein anderer Entwickler nächste Woche einsteigen könnte? Eine kurze Einrichtungsanleitung, ein Hinweis darauf, wo die Hauptlogik liegt, und eine Liste der genutzten Drittanbieter-Dienste und Lizenzen. Wenn die Antwort auf "was passiert, wenn dieser Entwickler verschwindet" lautet "wir müssten die gesamte Codebasis von null an lesen", ist das ein Preis, den Sie mit Ihrer Unterschrift akzeptieren.

Keine dieser vier Prüfungen erfordert, dass Sie eine einzige Funktion verstehen. Sie erfordern, dass der Dienstleister konkrete, überprüfbare Dinge liefert, und schon daran, wie schnell und vollständig diese auftauchen, lässt sich viel ablesen.

Was ein kurzes externes Audit abdeckt, das Sie allein nicht prüfen können

Die vier Prüfungen oben fangen die offensichtlichen Lücken ab. Sie sagen Ihnen nicht, ob der Code darunter sicher ist, ob er mit wachsender Nutzung mithält, oder ob eine scheinbar funktionierende Funktion nur einen Bug von einem ernsten Ausfall entfernt ist. Dafür reicht in der Regel ein fokussiertes externes Review über drei bis fünf Tage, ohne wochenlangen Zugriff oder eine vollständige Zeile-für-Zeile-Lektüre von allem, was gebaut wurde.

Ein Review in dieser Phase schaut sich typischerweise an, wie die Anwendung Authentifizierung und Zugriffskontrolle handhabt, ob Nutzereingaben sicher verarbeitet werden, wie die Datenschicht aufgebaut ist und ob sie unter echter Last hält, und ob die verwendeten Abhängigkeiten aktuell und frei von bekannten Schwachstellen sind. Es prüft außerdem auf die Art von Abkürzungen, die in einer Demo unsichtbar sind: hartcodierte Zugangsdaten, fehlende Fehlerbehandlung, über mehrere Dateien kopierte statt sauber geteilte Logik, und Funktionen, die bei dem einen Testfall funktionieren, den der Dienstleister Ihnen vorgeführt hat, aber bei allem, was leicht abweicht, versagen.

Wir haben diese Art von Review ausführlicher beschrieben, einschließlich wie eine strukturierte Code-Audit-Methodik von Anfang bis Ende abläuft, und was ein professionelles Code-Review in Deutschland üblicherweise kostet und was Sie für dieses Geld bekommen. Die Kurzversion für die Abnahmephase: ein paar Tage von einem unabhängigen Code-Quality-Review kosten in der Regel weniger als die Aufräumarbeiten, die Sie sonst hinterher zahlen würden, und deutlich weniger, als das Problem erst zu entdecken, nachdem der Dienstleister die Abschlussrechnung schon kassiert hat.

Abnahme und der Mängelrüge-Hebel, einfach erklärt

Wenn Ihr Vertrag deutschem Recht unterliegt und als Werkvertrag ausgestaltet ist, hat der Moment der Abnahme nicht nur praktisch, sondern auch rechtlich Gewicht. Sobald Sie die Abnahme unterschreiben, verschiebt sich die Beweislast tendenziell: Einen Mangel nachzuweisen, der schon vor der Unterschrift bestand, wird schwerer, und die Frist, ihn per Mängelrüge, einer formellen Mängelanzeige, zu melden, beginnt zu laufen. Genau deshalb gehört das Audit vor die Unterschrift, nicht danach.

Das ist keine Rechtsberatung, und die Details Ihres konkreten Vertrags, die gefundenen Mängel und die Formulierung Ihrer Abnahmeklausel verändern, welche Optionen Sie tatsächlich haben. Wenn ein Audit etwas Ernstes zutage bringt, ist der richtige nächste Schritt ein Gespräch mit einem Anwalt, der Ihnen sagen kann, was dieser Befund für Ihre Abnahme und Ihre verbleibenden Rechte aus dem Vertrag bedeutet, bevor Sie irgendetwas unterschreiben oder die Abschlusszahlung freigeben.

Befunde ins Abnahmeprotokoll bringen

Was das Audit auch zutage bringt: informelles Feedback in einem Anruf oder einer Chat-Nachricht ist kein dokumentierter Befund. Halten Sie jedes Problem schriftlich fest, am besten direkt am Abnahmeprotokoll angehängt, falls Ihr Vertrag eines vorsieht, mit genug Details, dass später niemand behaupten kann, nichts gewusst zu haben: was gefunden wurde, wo, und wie eine Lösung aussehen müsste. Behebt der Dienstleister etwas noch vor der Unterschrift, halten Sie auch das mit Datum fest.

Diese Dokumentation ist es, die die Mängelrüge-Frist später überhaupt greifbar macht, und sie macht aus "wir waren mit der Übergabe nicht zufrieden" etwas, auf das Sie tatsächlich reagieren können. Ein vages Gespräch, an das sich beide Seiten sechs Monate später unterschiedlich erinnern, schützt niemanden. Eine schriftliche Liste, die einem unterschriebenen Dokument angehängt ist, schützt Sie.

Wann es sich lohnt, jemanden hinzuzuziehen

Wenn Ihr Projekt klein und risikoarm ist und die vier Prüfungen oben saubere Ergebnisse liefern, brauchen Sie vielleicht gar keinen externen Prüfer. Die Rechnung ändert sich, sobald echtes Geld, Kundendaten oder Ihre Fähigkeit, später einen anderen Entwickler einzustellen, auf dem Spiel stehen. Dieselbe Logik gilt auch nach der Übergabe: Wenn Sie laufend einschätzen wollen, ob die Arbeit eines Teams hält, ohne selbst Code zu lesen, sind die Signale, auf die Sie Monat für Monat achten sollten anders als die einmalige Abnahmeprüfung hier, kommen aber aus derselben Haltung: Beweisen vertrauen statt Zusicherungen.

Wenn Sie kurz davor stehen, das finale Deliverable eines Dienstleisters abzunehmen, und sich ein zweites Paar Augen wünschen, bevor das Geld fließt, melden Sie sich unter hello@wolf-tech.io oder schauen Sie sich an, was wir bei wolf-tech.io machen. Ein kurzes unabhängiges Review vor der Abschlusszahlung ist deutlich günstiger, als erst danach herauszufinden, was gefehlt hat.