Wir lesen Softwareentwicklungsverträge von der anderen Seite des Tisches. Jedes Angebot, das wir schicken, kommt markiert zurück, und jeder Kundenvertrag, den wir unterschreiben, zeigt uns, welche Klauseln ein halbes Jahr später Ärger machen. Nach genug dieser Zyklen tritt ein Muster auf: Die Streits drehen sich nie um den Preis auf Seite eins. Sie drehen sich um die sechs Klauseln, die die meisten Käufer überfliegen.
Zwei Hinweise vor der Liste. Erstens: Wir sind keine Anwälte, und das hier ist kaufmännische Orientierung, keine Rechtsberatung. Für jeden Build, von dem Ihr Geschäft abhängt, zahlen Sie einem Anwalt eine Stunde. Diese Checkliste existiert, damit diese Stunde in die Formulierung geht und nicht in die Entdeckung, dass niemand geklärt hat, wem der Code gehört. Zweitens kommt alles unten von der Anbieterseite. Wir wissen, welche Klauseln Agenturen gerne vage lassen, weil wir diese Agentur waren. Wo unsere eigene Präferenz gegen Ihre läuft, sagen wir das.
Wem gehört der Code, und ab welchem Tag
Das ist die Klausel, die den meisten Wert zerstört, wenn sie schiefgeht, deshalb steht sie zuerst.
Die übliche Formulierung überträgt alle IP "bei vollständiger und endgültiger Zahlung". Wörtlich gelesen heißt das: Die Agentur besitzt alles, bis die letzte Rechnung klar ist. Das klingt am Unterschriftstag harmlos. Dann stockt das Projekt in Monat drei über einen strittigen Change Request, die Zahlungen stoppen, und der Kunde darf das halbfertige Repository rechtlich niemandem übergeben. Wir haben genau diese Lage einmal geerbt: Ein Gründer kam mit einem halbfertigen Produkt, einem eingefrorenen Codebestand und einem Voranbieter, der den Vertrag korrekt zitierte. Das Entwirren hat in Anwaltsstunden mehr gekostet als der fehlende Meilenstein wert war.
Die Lösung ist die Übertragung pro Meilenstein. IP an Arbeit, die abgenommen und bezahlt ist, geht auf Sie über, wenn dieser Meilenstein schließt, nicht wenn das ganze Projekt endet. Jeder akzeptierte Meilenstein sollte Ihnen eine funktionierende Scheibe des Produkts lassen. Endet die Beziehung früh, behalten Sie, wofür Sie gezahlt haben, und der Anbieter behält, wofür Sie nicht gezahlt haben.
Eine Deutschland-spezifische Falle verdient Aufmerksamkeit. Nach deutschem Urheberrecht ist das Urheberrecht selbst nicht übertragbar; übertragbar sind nur Nutzungsrechte (Paragrafen 31 ff. UrhG). Ein Vertrag, der von einem deutschen Entwickler die volle "Übertragung des Urheberrechts" verspricht, verspricht etwas, das das Gesetz nicht erlaubt. Was Sie tatsächlich ausformuliert haben wollen, sind ausschließliche, unwiderrufliche, übertragbare Nutzungsrechte für alle bekannten Nutzungsarten, einschließlich des Rechts, den Code zu ändern und ihn einem anderen Anbieter zu übergeben. Der UrhG-Text ist frei lesbar; der relevante Teil ist kurz.
Klären Sie Wiederverwendung in derselben Klausel. Agenturen recyceln generische Utilities über Kunden hinweg, und das ist in Ordnung, solange es deklariert ist. Die tragfähige Trennung in unserer Erfahrung: Ihre Geschäftslogik und alles Kundenfacing ist ausschließlich Ihres, benannte generische Bibliotheken bleiben bei der Agentur unter einer unbefristeten Lizenz an Sie. Beide Listen gehören in eine Anlage. "Der gesamte Code ausschließlich Ihrer, keine Ausnahmen" klingt sicherer und stirbt meist in der Verhandlung, weil keine Agentur ihren Werkzeugkasten weggibt. Die Anlage ist der Kompromiss, der hält.
Was als fertig gilt
Abnahme ist der Ort, an dem Festpreisprojekte leben oder sterben, und sie braucht drei Teile: Kriterien, Verfahren und eine Frist.
Zuerst die Kriterien. "Die App funktioniert wie spezifiziert" hat mehr Freundschaften beendet als jeder Bug. Funktionierende Kriterien benennen den Test: welche User-Flows auf welcher Umgebung mit welchen Daten laufen müssen, und welche Antwortzeiten akzeptabel sind. Für einen typischen Web-App-Meilenstein akzeptieren wir Kriterien wie "ein neuer Nutzer kann sich registrieren, den Checkout mit einer Testkarte abschließen und die Bestätigungsmail auf der Staging-URL empfangen, wobei die zehn benannten Testfälle in Anlage B bestehen." Ein Käufer, der Fertig nicht in dieser Schärfe beschreiben kann, ist nicht reif für einen Festpreis. Dieser Satz wird einige Leser ärgern. Er hält trotzdem.
Zweitens das Verfahren. Wer testet, wo, und wie lange: Der Kunde testet auf Staging innerhalb von zehn Arbeitstagen nach Lieferung und meldet Mängel als reproduzierbare Abweichungen von den vereinbarten Kriterien. Dieser letzte Satz zählt. Ein Mangel ist eine Abweichung von den Kriterien, nicht alles, was dem Kunden nicht gefällt. Alles andere ist ein Change Request, bepreist unter der nächsten Klausel.
Drittens die Frist. Reagiert der Kunde nicht innerhalb des Fensters, gilt der Meilenstein als abgenommen. Juristen nennen das fiktive Abnahme. Ohne sie kann ein beschäftigter Product Owner die Abrechnung ein Quartal lang aufhalten. Mit ihr bedeutet Schweigen Zustimmung, und das schärft den Blick wunderbar.
Wir haben einmal ein Projekt vier Monate auf einem Daumen-hoch in einem Video-Call laufen sehen. Keine schriftliche Abnahme, keine Testliste. Als der fehlende Export-Button auftauchte, nannte die Agentur das ein neues Feature und der Kunde einen Bug, und beide hatten nach dem Vertrag, den sie unterschrieben hatten, recht. Will heißen: Unter einem Vertrag, der nichts definierte, lagen beide falsch.
Wie Änderungen bepreist werden
Jedes Projekt ändert sich. Der Vertrag entscheidet nur, ob Änderungen als ruhiges Amendment oder als rechnungsförmige Überraschung ankommen.
Eine tragfähige Change-Order-Klausel hat vier Schritte und keine Abkürzungen: Der Kunde fordert die Änderung schriftlich an, der Anbieter antwortet innerhalb einer festgelegten Zahl von Tagen mit Kosten- und Terminwirkung, beide Seiten unterschreiben, und erst dann startet die Arbeit. Unsere interne Regel ist strenger als die meisten Verträge, die wir unterschreiben: kein Ticket, keine Änderung, keine Rechnung. Mündliche "könnten Sie noch kurz"-Bitten in Status-Calls existieren nicht, bis jemand sie aufschreibt. Wir setzen das bei uns selbst durch, weil die Alternative ein Streit über Erinnerung ist, und Erinnerung rechnet immer zu unseren Gunsten. Genau deshalb sollten Sie sich nicht auf unsere verlassen.
Ziehen Sie die Grenze Bug gegen Änderung in dieser Klausel, nicht später im Gewährleistungskampf. Unsere Arbeitsdefinition: Alles, was von den akzeptierten Kriterien abweicht, ist ein Mangel und wird im Gewährleistungsfenster kostenlos behoben; alles, was Verhalten hinzufügt, das die Kriterien nie beschrieben haben, ist eine Änderung und wird bepreist. Schreiben Sie diesen Satz in den Vertrag. Er wirkt am Unterschriftstag pedantisch und spart in Monat fünf einen fünfstelligen Streit.
Ein ehrliches Geständnis: Change Orders sind für Agenturen profitabel, uns eingeschlossen. Festpreisanbieter verdienen ihre Marge an der Differenz zwischen Schätzung und Change-Log. Das macht Change Orders nicht zum Betrug; es macht die Preisformel zum Verhandlungsgegenstand. Bestehen Sie darauf, dass die Klausel Tagessätze für Änderungsarbeit im Voraus nennt. Ein Anbieter, der den Satz für künftige Änderungen nicht nennen will, plant, ihn später zu nennen, wenn Sie nicht mehr wegkönnen.
Wie jede Seite aussteigen kann
Niemand verhandelt den Ausstieg, wenn die Beziehung gut ist, und genau dann ist der Ausstieg billig zu vereinbaren.
Sie wollen eine ordentliche Kündigung mit Frist, dreißig Tage sind die übliche Zahl. Ein Ausstieg ohne Verschulden klingt nach Planung aufs Scheitern. Tatsächlich ist es das, was beide Seiten mitten im Projekt ehrlich sein lässt: Wenn Gehen wenig kostet, bedeutet Bleiben etwas.
Die Klausel, die mehr zählt als die Frist, ist das Übergabepaket. Beim Ausstieg, aus jedem Grund, liefert der Anbieter Repository-Zugang mit voller Historie, Zugangsdaten und Infrastruktur-Inventar, Deployment-Dokumentation und einen aufgezeichneten Handover-Call mit dem übernehmenden Team. Die meisten Verträge, die wir prüfen, sagen "der Anbieter wirkt bei der Transition mit" und hören auf. Mitwirkung ist kein Deliverable. Eine Repository-URL, ein Credentials-Tresor und ein Runbook sind Deliverables. Benennen Sie sie.
Wenn Sie auf ein langfristiges Setup zulaufen, verdient dieser Abschnitt doppelte Aufmerksamkeit. Ausstiegsklauseln bei einem Vier-Wochen-Build sind Formalie; Ausstiegsklauseln bei einem Team, das zwei Jahre Produktwissen hält, sind das ganze Spiel. Unsere Seite zu dedizierten Delivery-Teams beschreibt, wie wir die Transferseite dieser Beziehung strukturieren, und der Vertrag sollte das spiegeln.
Wo der Code liegt, wenn der Anbieter verschwindet
Source-Code-Escrow heißt: Eine neutrale Drittpartei hält eine aktuelle Kopie des Codes und gibt sie Ihnen bei definierten Auslösern frei: Insolvenz, Support-Ausfall, Übernahme. Anbieter wie NCC Group betreiben dieses Geschäft seit Jahrzehnten. Bei einer mehrjährigen Abhängigkeit von einem einzelnen Vendor ist Escrow günstige Versicherung, und wir empfehlen sie ohne Vorbehalt.
Bei einem kurzen Build ist Escrow meist der falsche Kauf. Unsere Position: Wenn Sie ab Tag eins vollen Repository-Zugang haben und der Code aus Infrastruktur deployt, die Sie kontrollieren, haben Sie bereits, was Escrow Ihnen gäbe. Escrow schützt vor Verlust des Zugangs; durchgehender Zugang nimmt das Risiko weg, statt es zu versichern. Der Trade-off ist trotzdem real. Escrow prüft außerdem, dass der hinterlegte Code tatsächlich baut, was Ihr Repo-Zugang nicht garantiert. Bei allem über sechs Monaten Vendor-Abhängigkeit zahlen Sie beides.
Welchen Weg Sie auch nehmen: Prüfen Sie die Auslöser schriftlich. Ein Escrow-Vertrag, der den Code nur bei formeller Insolvenz freigibt, hilft nichts, wenn der Anbieter einfach aufhört, Mails zu beantworten, und das ist der weit häufigere Ausfall. Support-Default mit Nachfrist ist der Auslöser, der die Realität abdeckt.
Wie lange Nachbesserungen kostenlos bleiben
Gewährleistungsfenster in Agenturverträgen laufen dreißig bis neunzig Tage ab Abnahme. Diese Spanne ist üblich, nicht zwingend, und zwei Dinge in der Klausel zählen mehr als die Zahl: was sie abdeckt, und wie schnell der Anbieter reagieren muss.
Abgedeckt sind Mängel wie oben definiert, nicht neue Anforderungen, nicht Drittparteien-Brüche, nicht "die neue iOS-Version hat unsere Buttons verschoben." Reaktionszeiten sollten nach Schwere benannt sein: Kritische Mängel an einem Arbeitstag bestätigt ist eine Klausel, die wir gerne unterschreiben, weil jedes Team, das die Einstellung wert ist, das sowieso einhält. Ein Anbieter, der um die Bestätigung kritischer Bugs innerhalb eines Tages feilscht, sagt Ihnen etwas über seine Support-Bank. Hören Sie zu.
Deutsche Käufer bekommen hier eine gesetzliche Überraschung. Individualsoftware nach Bestellung gilt in der Regel als Werkvertrag nach dem BGB, das heißt: Es wird ein Erfolg geschuldet, und die regelmäßige Verjährung für Mängelansprüche läuft zwei Jahre, sofern der Vertrag sie nicht verkürzt. Die meisten Agenturverträge verkürzen sie auf die üblichen dreißig bis neunzig Tage. Diese Verkürzung ist normal und meist akzeptabel. Unterschreiben Sie sie wissend, statt zwei Jahre vermeintlichen Schutz zu entdecken, die nie existierten. Stunden unter Staff Augmentation sind dagegen meist ein Dienstvertrag: Geschuldet ist die Mühe, keine Abnahme greift, und Gewährleistung läuft anders. Welcher Vertragstyp Ihrer ist, entscheidet, welche der Klauseln oben überhaupt greifen.
Der Unterschriften-Test
Lesen Sie den Entwurf einmal und suchen Sie sechs Antworten. Wann wird abgenommene Arbeit meine. Welcher Test beweist, dass ein Meilenstein fertig ist, und was passiert, wenn ihn niemand ausführt. Was eine Änderung kostet, bevor die Arbeit startet. Was ich erhalte, wenn wir uns trennen. Wo der Code sitzt, wenn der Anbieter still wird. Wie lange Mängel kostenlos behoben werden, und wie schnell.
Ein Vertrag, der alle sechs in klarer Sprache beantwortet, ist unterschreibbar, egal was Seite eins kostet. Ein Vertrag, der zwei davon umgeht, kostet Sie den ungedeckten Betrag später, mit Zinsen. Wenn Sie gerade Angebote vergleichen, zeigt unser Leitfaden zur Auswahl einer Softwareentwicklungsagentur, wie Sie den Anbieter hinter dem Papier prüfen, Individualsoftware vs Standardsoftware sagt, ob der Build überhaupt die richtige Zeile ist, und unsere Leistungen listen, wofür wir tatsächlich unterschreiben. Bringen Sie uns über Kontakt einen Vertrag mit allen sechs Antworten, und das erste Gespräch gilt Ihrem Produkt statt Ihrem Papier. Zu Preisen und Leistungen 2026 siehe unseren Leitfaden zur Individualsoftware in Deutschland.
Häufige Fragen
Brauche ich einen Anwalt für den Softwareentwicklungsvertrag?
Für jeden Build, von dem das Geschäft abhängt: ja. Eine Checkliste wie diese ersetzt keine Rechtsberatung; sie macht den Anwalt schneller und günstiger. Sie kommen mit den kaufmännischen Antworten, und der Anwalt prüft, ob die Formulierung in Ihrer Rechtsordnung hält.
Wem gehört der Code, bevor die letzte Rechnung bezahlt ist?
Wem der Vertrag das Eigentum zuweist, und genau das ist das Problem, wenn der Vertrag dazu schweigt. Ohne Klausel ist die Inhaberschaft in grenzüberschreitenden Projekten unklar. Bestehen Sie auf IP-Übergabe an jeden akzeptierten Meilenstein, damit ein Streit in Monat vier nicht den Code aus Monat eins einfriert.
Ist ein Festpreisvertrag sicherer als Time and Materials?
Keines von beiden ist für sich sicherer. Festpreis ist nur mit dichten Abnahmekriterien sicher, weil jede Unschärfe zum Change Request wird. Time and Materials ist nur mit starken Kündigungsrechten und vollem Repo-Zugang ab Tag eins sicher, weil Sie das Scope-Risiko tragen. Wählen Sie das Modell, dessen Fehlermodus Sie aushalten.
Darf die Agentur Code, den sie für mich geschrieben hat, in anderen Kundenprojekten wiederverwenden?
Nur wenn der Vertrag das erlaubt, also entscheiden Sie das vor der Unterschrift. Die tragfähige Trennung ist meist: Ihre Geschäftslogik und alles Kundenfacing ist ausschließlich Ihres, generische Utilities und Bibliotheken bleiben bei der Agentur unter einer Lizenz an Sie. Beide Listen gehören in eine Anlage, sonst kommt der Streit später zum zehnfachen Preis.