Software entwickeln lassen: was die Vertragsform über das Ergebnis entscheidet

In Vergabegesprächen über Softwareprojekte wird über Tagessätze, Termine und Funktionslisten verhandelt. Welchem Vertragstyp das Ganze unterliegt, wandert an die Rechtsabteilung und kommt als Anlage zurück. Diese Reihenfolge erzeugt später die meisten Konflikte: Der Vertragstyp entscheidet, wann Geld fällig wird, wer im Streitfall was beweisen muss, ob es einen definierten Endzustand gibt — und ob der Auftraggeber am Ende mit dem Code machen darf, was er will.

Das Bürgerliche Gesetzbuch kennt für Auftragsentwicklung keinen eigenen Vertragstyp. Es kennt den Werkvertrag nach §§ 631 ff. BGB und den Dienstvertrag nach §§ 611 ff. BGB. Welche Ordnung greift, hängt nicht vom Titel des Dokuments ab, sondern davon, was inhaltlich geschuldet ist.

Zwei Grundtypen, drei praktische Folgen

Nach § 631 Abs. 1 BGB verpflichtet der Werkvertrag den Unternehmer „zur Herstellung des versprochenen Werkes”. Absatz 2 stellt klar, dass auch „ein anderer durch Arbeit oder Dienstleistung herbeizuführender Erfolg” Gegenstand sein kann — Software fällt darunter, obwohl sie keine Sache im klassischen Sinn ist. Der Dienstvertrag verpflichtet nach § 611 Abs. 1 BGB dagegen nur „zur Leistung der versprochenen Dienste”.

Aus diesem einen Unterschied — Erfolg statt Dienste — folgen drei Konsequenzen. Beim Werkvertrag trägt der Auftragnehmer das Risiko, dass das Ergebnis funktioniert; beim Dienstvertrag trägt es der Auftraggeber. Nur der Werkvertrag kennt eine Abnahme, an die Fälligkeit, Gefahrübergang, Beweislast und Verjährung geknüpft sind. Und Mängelrechte existieren ausschließlich im Werkvertragsrecht: Der Dienstvertrag kenne keine Mängelrechte, weshalb bei mangelhafter Leistung die Vergütung nicht gekürzt werden könne, fasst die IHK für München und Oberbayern zusammen.

Der Werkvertrag: Erfolg, Abnahme, Gewährleistung

Erstellung, Einführung und Veränderung von Software zählen zu den typischen Anwendungsfällen des Werkvertrags. Der Auftragnehmer entscheidet selbst über Zeitaufwand und Personaleinsatz, schuldet aber ein bestimmtes Arbeitsergebnis. Vergütet wird nach § 641 Abs. 1 BGB „bei der Abnahme des Werkes” — die Vorleistung liegt also beim Entwickler, soweit keine Abschlagszahlungen nach § 632a BGB vereinbart sind. Auch dort verbleibt die Beweislast für vertragsgemäße Leistung bis zur Abnahme beim Unternehmer.

Ist das Werk mangelhaft, greifen die Rechte aus § 634 BGB: Nacherfüllung, Selbstvornahme mit Aufwendungsersatz, Rücktritt oder Minderung sowie Schadensersatz. Sie verjähren nach § 634a Abs. 1 BGB in zwei Jahren, wenn der Erfolg in der Herstellung oder Veränderung einer Sache besteht, sonst in der regelmäßigen Frist von drei Jahren; die Einordnung unkörperlicher Software ist umstritten und gehört deshalb in den Vertrag. Die Frist beginnt nach § 634a Abs. 2 BGB mit der Abnahme — nicht mit der Inbetriebnahme.

Der Dienstvertrag: Tätigkeit statt Ergebnis

Beim Dienstvertrag wird die geschuldete Leistung erbracht, indem gearbeitet wird. Ob am Ende eine benutzbare Anwendung steht, ist rechtlich nicht die Frage. Vergütet wird nach Zeitabschnitten und nachträglich; eine Abnahme findet nicht statt. Das ist keine schlechtere Position, sondern eine andere Verteilung derselben Unsicherheit: Wer den Umfang nicht kennt, kann ihn auch nicht zum Festpreis einkaufen, ohne einen Risikoaufschlag mitzubezahlen.

Die Steuerung verschiebt sich damit vom Vertrag in die Projektführung. An die Stelle der Abnahme treten kurze Zyklen mit prüfbaren Zwischenständen, Transparenz über den Verbrauch und ein kurzfristiges Kündigungsrecht. Fehlen sie, entsteht die Aufwandsfalle: laufende Rechnungen ohne belastbaren Bezug zu einem Fortschritt, den jemand außerhalb des Entwicklungsteams beurteilen kann.

Die Abnahme nach § 640 BGB ist der Dreh- und Angelpunkt

§ 640 Abs. 1 Satz 1 BGB verpflichtet den Besteller, „das vertragsmäßig hergestellte Werk abzunehmen”. Mit der Abnahme wird die Vergütung fällig, geht die Leistungsgefahr über, beginnt die Verjährung — und die Beweislast kehrt sich um: Bis zur Abnahme muss der Auftragnehmer darlegen, dass seine Leistung vertragsgemäß ist, danach muss der Auftraggeber den Mangel beweisen.

Verweigern lässt sich die Abnahme nur bei wesentlichen Mängeln; § 640 Abs. 1 Satz 2 BGB schließt die Verweigerung wegen unwesentlicher Mängel aus. Hinzu kommt die Abnahmefiktion des § 640 Abs. 2 BGB: Setzt der Unternehmer nach Fertigstellung eine angemessene Frist und verweigert der Besteller die Abnahme nicht unter Angabe mindestens eines Mangels, gilt das Werk als abgenommen.

Der Maßstab dieser Mechanik steckt im Wort „vertragsmäßig”. Was vertragsmäßig ist, ergibt sich aus der Leistungsbeschreibung. Ohne belastbare Spezifikation gibt es keinen Maßstab — und der Streit verlagert sich vom Ergebnis auf die Auslegung des Vertragstexts.

Warum der Festpreis eine vollständige Spezifikation erzwingt

Ein Festpreis ist eine Kalkulation über einen feststehenden Leistungsumfang. Steht der Umfang nicht fest, ist der Preis entweder geraten oder er enthält einen Risikoaufschlag. Beides führt zur selben Anforderung: Der Funktionsumfang muss vor der ersten Zeile Code beschrieben sein, und zwar auf einem Detailgrad, der später eine Abnahme trägt. Eine Liste von Schlagworten reicht dafür nicht.

Damit verlangt der Festpreis die schwierigste Arbeit des Vorhabens genau dort, wo am wenigsten bekannt ist. Bei Individualsoftware ist das der Regelfall: Sie entsteht meist dort, wo ein Ablauf nie vollständig aufgeschrieben wurde, wo Sonderfälle nur in einzelnen Köpfen existieren und wo sich erst beim Bauen zeigt, welche Daten die angebundenen Systeme tatsächlich hergeben. Was in der Angebotsphase als Anforderung notiert wird, ist in dieser Lage eine Hypothese.

Anforderungen ändern sich messbar — während der Entwicklung

Die Vorstellung, Anforderungen ließen sich einmal erheben und dann einfrieren, ist empirisch widerlegt. Capers Jones wertete bei Software Productivity Research Daten aus rund 12.000 Projekten der Jahre 1984 bis 2003 aus und berichtete 2003 in der IEEE Software, die gemessene Änderungsrate der Anforderungen könne zwei Prozent pro Kalendermonat während der Entwicklung überschreiten. Bei zwölf Monaten Laufzeit summiert sich das auf eine Größenordnung von rund einem Viertel des ursprünglichen Umfangs — nicht durch Nachlässigkeit, sondern weil Erkenntnis Zeit braucht.

Die Fachliteratur führt das seit Jahrzehnten auf dieselbe Ursache zurück. Fred Brooks beschrieb sie 1987 in „No Silver Bullet” als den harten Kern der Softwareentwicklung, an dem bessere Werkzeuge nichts ändern.

Brooks’ Befund und die Konstruktion des Festpreises widersprechen einander direkt. Der Vertrag verlangt die präzise Entscheidung darüber, was gebaut werden soll, zum frühestmöglichen Zeitpunkt — die Empirie sagt, dass genau diese Entscheidung der schwierigste Teil der Arbeit ist und sich erst im Bauen klärt.

Die Nachtragsökonomie: was daraus praktisch folgt

Der Widerspruch verschwindet nicht, er wandert in die Änderungsverfahren. Jede Erkenntnis nach Vertragsschluss wird zu einem Änderungsantrag, der bewertet, angeboten und beauftragt werden muss — Aufwand, der auf beiden Seiten zusätzlich anfällt. Schwerer wiegt der zweite Effekt: Bei jedem Nachtrag steht die Frage im Raum, ob die Anforderung nicht schon im ursprünglichen Umfang enthalten war. Das ist eine Auslegungsfrage und damit ein wiederkehrender Konfliktanlass.

Für den Ausstieg kennt das Gesetz zwei selten genutzte Ventile. Nach § 648 BGB kann der Besteller den Werkvertrag bis zur Vollendung jederzeit kündigen; der Unternehmer behält den Vergütungsanspruch abzüglich ersparter Aufwendungen, wobei für den nicht erbrachten Teil fünf Prozent vermutet werden. Bleibt der Besteller seine Mitwirkung schuldig — verspätete Testdaten, ausbleibende Fachentscheidungen —, kann der Unternehmer nach § 642 BGB eine angemessene Entschädigung verlangen.

Was Gerichte zu agilen Projekten entschieden haben

Eine gefestigte Rechtsprechung zur Einordnung agiler Softwareprojekte gibt es bis heute nicht. Die meistzitierte Entscheidung stammt vom OLG Frankfurt a. M. vom 17. August 2017 (Az. 5 U 152/16). Der Senat ließ ausdrücklich offen, ob Dienst- oder Werkvertragsrecht galt: Im ersten Fall war die Forderung begründet, weil die Leistungen unstreitig erbracht waren; im zweiten, weil in der Beauftragung des Folgemonats eine konkludente Billigung des bislang Geleisteten liegen könne und die monatlich abgerechneten Beträge keine bloßen Abschlagszahlungen darstellten.

Daraus folgt zweierlei: Nicht die Methode entscheidet über den Vertragstyp, sondern die konkrete Ausgestaltung — wer Scrum praktiziert und dennoch einen Festpreis auf einen Endzustand vereinbart, hat einen Werkvertrag. Und bei agilen Projekten tragen Vertragstext und gelebte Praxis die Last, die sonst die gesetzliche Abnahmeregelung übernimmt.

Wem der Code gehört, wenn nichts vereinbart ist

Am häufigsten übersehen wird der Punkt, der die Rechte am Ergebnis betrifft. Computerprogramme sind nach § 69a UrhG geschützt, und zwar „in jeder Gestalt, einschließlich des Entwurfsmaterials”. Der gesetzliche Rechteübergang des § 69b UrhG, nach dem ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse berechtigt ist, gilt nur für Arbeitnehmer und Dienstverhältnisse — auf externe Auftragnehmer ist er nicht anwendbar.

Für Auftragsentwicklung gilt stattdessen der Zweckübertragungsgrundsatz des § 31 Abs. 5 UrhG: Sind die Nutzungsarten nicht ausdrücklich einzeln bezeichnet, richtet sich der Umfang nach dem Vertragszweck — im Zweifel eng und zulasten des Erwerbers. Bezahlt zu haben genügt also nicht. Ohne Regelung bleiben im Kern die Mindestbefugnisse aus § 69d Abs. 1 UrhG: bestimmungsgemäße Benutzung einschließlich Fehlerberichtigung. Weiterentwicklung durch Dritte, Weitergabe im Konzern oder spätere Vermarktung sind davon nicht gedeckt, und der Quellcode ist nach Auffassung der Industrie- und Handelskammern in der Regel nur bei ausdrücklicher Vereinbarung herauszugeben.

Für jeden Entwicklungsvertrag folgt daraus eine kurze Prüfliste: ausschließliches, unbeschränktes Nutzungsrecht mit Bearbeitungs- und Weiterübertragungsrecht, Anspruch auf Quellcode und Dokumentation, Klarheit über Fremd- und Open-Source-Komponenten sowie darüber, auf wessen Konten die Infrastruktur läuft.

Wie sich das Modell begründet wählen lässt

1. Spezifizierbarkeit prüfen Lässt sich der Umfang heute so beschreiben, dass eine Abnahme daran messbar wäre? Wenn ja, passt der Werkvertrag zum Festpreis.
2. Erkenntnisanteil schätzen Wie viel des Vorhabens besteht darin, herauszufinden, was gebraucht wird? Je höher der Anteil, desto teurer der Risikoaufschlag im Festpreis.
3. Abgrenzbares herausziehen Schnittstellen, Migrationen und klar umrissene Bausteine lassen sich zum Festpreis vergeben, auch wenn das Gesamtvorhaben offen ist.
4. Steuerung verankern Bei laufender Vergütung ersetzen kurze Zyklen, prüfbare Zwischenstände, ein Verbrauchsbericht und ein kurzfristiges Kündigungsrecht die fehlende Abnahme.
5. Rechte und Betrieb mitregeln Nutzungsrechte, Quellcode, Dokumentation und Zugänge gehören in denselben Vertrag, unabhängig vom Vergütungsmodell.

Wer Software entwickeln lassen will, entscheidet mit dem Vertragsmodell zugleich darüber, wo die Anforderungsunsicherheit landet. Ein Teil der Anbieter zieht daraus die Konsequenz und gibt das Projektgeschäft auf einen festen Endzustand auf: Kaido Studios etwa, ein Hamburger Entwicklungspartner für KI-Anwendungen und Individualsoftware im Mittelstand, bietet die Zusammenarbeit mit festem Monatskontingent als Regelfall an und behält Festpreise klar abgegrenzten Einzelaufgaben vor.

Keine Vertragsform ersetzt allerdings die fachliche Klärung. Ein Dienstvertrag macht unklare Anforderungen nicht klarer, er verteilt nur die Kosten der Unklarheit anders. Und ein sauber formulierter Werkvertrag schützt nicht davor, das Falsche präzise zu bestellen.

Häufige Fragen

Ist ein Softwareentwicklungsvertrag automatisch ein Werkvertrag?

Nein. Die Erstellung von Individualsoftware ist ein typischer Anwendungsfall des Werkvertrags nach § 631 BGB, entscheidend ist aber, was inhaltlich geschuldet ist. Wird ein bestimmter Erfolg versprochen, gilt Werkvertragsrecht; wird nur Entwicklungsleistung nach Aufwand erbracht, kommt § 611 BGB in Betracht. Das OLG Frankfurt a. M. ließ diese Frage 2017 für ein agiles Projekt ausdrücklich offen.

Was bewirkt die Abnahme rechtlich?

Mit der Abnahme nach § 640 BGB wird die Vergütung fällig (§ 641 Abs. 1 BGB), geht die Gefahr über, beginnt die Verjährung der Mängelansprüche (§ 634a Abs. 2 BGB) und kehrt sich die Beweislast um: Bis dahin muss der Auftragnehmer die Vertragsmäßigkeit belegen, danach der Auftraggeber den Mangel. Wegen unwesentlicher Mängel darf die Abnahme nicht verweigert werden.

Kann ein Auftraggeber ein laufendes Softwareprojekt einfach beenden?

Beim Werkvertrag ja: § 648 Satz 1 BGB erlaubt dem Besteller, bis zur Vollendung jederzeit ohne Grund zu kündigen. Der Auftragnehmer behält den Vergütungsanspruch abzüglich ersparter Aufwendungen; für den nicht erbrachten Teil werden ihm fünf Prozent vermutet. Bei Dienst- und Pauschalverträgen gelten die vereinbarten Fristen.

Gehört dem Auftraggeber der Quellcode, wenn er die Entwicklung bezahlt hat?

Nicht automatisch. Der Rechteübergang nach § 69b UrhG gilt nur für Arbeitnehmer, nicht für externe Auftragnehmer. Für Auftragsentwicklung greift § 31 Abs. 5 UrhG, wonach Nutzungsrechte im Zweifel nur im vertraglich erforderlichen Umfang übergehen. Ohne ausdrückliche Klausel bleibt es im Kern bei den Mindestbefugnissen des § 69d Abs. 1 UrhG; die Herausgabe des Quellcodes ist gesondert zu vereinbaren.

Wann ist ein Festpreis trotz Anforderungsunsicherheit sinnvoll?

Wenn sich ein Teilbereich sauber abgrenzen lässt — etwa eine Schnittstelle mit dokumentiertem Zielsystem, eine Datenmigration mit bekanntem Quellformat oder ein klar umrissener Berichtsbaustein. Für solche Pakete ist die Spezifikation vorab leistbar, und der Festpreis bepreist ein kalkulierbares statt eines geratenen Risikos.