Softwareentwicklungsvertrag: Rechte, Pflichten und Risiken

Ein Softwareentwicklungsvertrag entscheidet häufig darüber, ob ein IT-Projekt planbar bleibt oder später an unklaren Erwartungen, ungeklärten Nutzungsrechten und streitigen Änderungswünschen scheitert. Gemeint ist nicht nur ein technisches Dokument, sondern ein rechtlicher Rahmen für Leistung, Vergütung, Termine, Abnahme, Gewährleistung, Haftung und Rechte an der entwickelten Software. Gerade bei Individualsoftware, Schnittstellen, Apps, Plattformen oder KI-gestützten Anwendungen treffen technische Unsicherheiten auf verbindliche Vertragspflichten.

Grundsätzlich kann ein solcher Vertrag sehr unterschiedlich ausgestaltet sein. Je nach Projektziel kann Werkvertragsrecht, Dienstvertragsrecht, Kaufrecht, Mietrecht, Lizenzvertragsrecht oder ein gemischter Vertrag einschlägig sein. Diese Einordnung wirkt sich unmittelbar auf Abnahme, Mängelrechte, Kündigung, Vergütung und Verjährung aus. Pauschale Musterverträge reichen daher nur selten aus, wenn die Software geschäftskritisch ist oder sensible Daten verarbeitet werden.

Der folgende Beitrag erläutert die wichtigsten rechtlichen Grundlagen, typische Konfliktfelder und praktische Prüfpunkte. Er ersetzt keine Einzelfallprüfung, zeigt aber, welche Fragen Auftraggeber und Softwareentwickler vor Vertragsschluss, während des Projekts und bei Störungen strukturiert klären sollten.

Inhaltsverzeichnis

1. Was ist ein Softwareentwicklungsvertrag?
2. Gesetzliche Einordnung: Werkvertrag, Dienstvertrag oder gemischter Vertrag?
3. Abgrenzung zu Lizenzvertrag, SaaS, Wartung und IT-Projektvertrag
4. Typische Fallkonstellationen aus der Praxis
5. Leistungsbeschreibung, Abnahme und Änderungswünsche
6. Rechte an Software: Quellcode, Nutzungsrechte, Open Source und Daten
7. Risiken, Haftung und typische Fehler im Softwareentwicklungsvertrag
8. Fristen, Verjährung, Verzug und Kündigung
9. Beweise und Dokumentation im IT-Projekt
10. Handlungsschritte und Checkliste für Auftraggeber und Entwickler
11. Besondere Themen: Datenschutz, IT-Sicherheit und Geheimnisschutz
12. FAQ zum Softwareentwicklungsvertrag
13. … und 1 weitere Abschnitte

Was ist ein Softwareentwicklungsvertrag?

Ein Softwareentwicklungsvertrag ist eine Vereinbarung, nach der eine Partei Software erstellt, anpasst, erweitert oder integriert und die andere Partei hierfür eine Vergütung zahlt. Gegenstand kann eine vollständig neu entwickelte Individualsoftware sein, aber auch ein Modul, eine App, eine Schnittstelle, ein Konfigurator, ein Datenbankmodell, ein Webportal oder die Anpassung bestehender Standardsoftware. Entscheidend ist nicht die Bezeichnung des Vertrags, sondern der vereinbarte Leistungsinhalt.

In der Praxis umfasst der Vertrag meist mehr als das reine Programmieren. Häufig gehören Analyse, Konzeption, UX-Design, Architektur, Entwicklung, Test, Dokumentation, Migration, Schulung, Hostingvorbereitung, Wartungsübergabe und Support in der Startphase dazu. Wird dies nicht sauber beschrieben, entstehen später Auslegungsfragen: War die Datenmigration enthalten? Musste der Entwickler eine bestimmte Performance garantieren? Wer trägt das Risiko, wenn ein Drittanbieter seine API ändert?

Ein rechtlich belastbarer Softwareentwicklungsvertrag verbindet technische Projektbeschreibung und juristische Risikoverteilung. Er sollte daher nicht nur festlegen, was entwickelt wird, sondern auch, wann eine Leistung als vertragsgemäß gilt. Besonders wichtig sind messbare Anforderungen, Zuständigkeiten, Mitwirkungspflichten, Abnahmeprozesse und Regeln für Änderungen.

Grundsätzlich gilt: Je individueller, komplexer und geschäftskritischer die Software ist, desto stärker sollte der Vertrag auf das konkrete Projekt zugeschnitten sein. Bei kleinen Erweiterungen kann eine schlanke Vereinbarung genügen. Bei Plattformprojekten, regulierten Geschäftsmodellen, personenbezogenen Daten oder hohem Investitionsvolumen sind detaillierte Regelungen regelmäßig sinnvoller.

Gesetzliche Einordnung: Werkvertrag, Dienstvertrag oder gemischter Vertrag?

Das Bürgerliche Gesetzbuch enthält keinen eigenen Vertragstyp mit der Überschrift Softwareentwicklungsvertrag. Die rechtliche Einordnung erfolgt deshalb anhand des vereinbarten Schwerpunkts. Wird ein bestimmter Erfolg geschuldet, spricht vieles für einen Werkvertrag nach §§ 631 ff. BGB. Der Erfolg kann etwa darin bestehen, dass eine funktionsfähige Anwendung mit bestimmten Features erstellt und abgenommen wird.

Wird dagegen nur eine Tätigkeit geschuldet, ohne dass ein konkreter Erfolg versprochen ist, kann Dienstvertragsrecht nach §§ 611 ff. BGB näherliegen. Das betrifft etwa laufende Beratung, Unterstützung eines internen Entwicklungsteams, Projektmanagement auf Stundenbasis oder agile Entwicklungsleistungen, bei denen der endgültige Funktionsumfang erst schrittweise bestimmt wird. Auch hier kommt es jedoch auf die konkrete Vertragsgestaltung an. Eine agile Methodik schließt einen werkvertraglichen Erfolg nicht automatisch aus.

Viele IT-Verträge sind gemischte Verträge. Entwicklung, Lizenzierung, Pflege, Hosting, Beratung und Schulung können in einem Vertragswerk zusammenfallen. Dann ist zu prüfen, welche Regelungen für welchen Vertragsteil gelten oder welcher Teil den Schwerpunkt bildet. Diese Prüfung ist rechtlich relevant, weil etwa Mängelrechte, Abnahme, Kündigung und Vergütungsansprüche unterschiedlich ausgestaltet sind.

Bei Verträgen über digitale Produkte können zudem besondere verbraucherschützende Vorschriften eine Rolle spielen, wenn Verbraucher beteiligt sind. Im B2B-Bereich stehen dagegen regelmäßig Vertragsfreiheit, AGB-Kontrolle, handelsrechtliche Untersuchungs- und Rügefragen sowie branchenspezifische Compliance-Anforderungen im Vordergrund.

Eine unklare Einordnung führt häufig zu Streit. Auftraggeber gehen dann von einem geschuldeten Ergebnis aus, während Entwickler nur die Erbringung von Entwicklungsstunden schulden wollen. Um dies zu vermeiden, sollte der Vertrag ausdrücklich regeln, ob ein bestimmtes Ergebnis, einzelne Meilensteine, Sprint-Ergebnisse, ein Mindestfunktionsumfang oder lediglich Dienstleistungen geschuldet sind.

Abgrenzung zu Lizenzvertrag, SaaS, Wartung und IT-Projektvertrag

Ein Softwareentwicklungsvertrag wird häufig mit anderen IT-Verträgen vermischt. Das ist rechtlich nicht ungewöhnlich, kann aber problematisch werden, wenn die einzelnen Vertragsteile nicht getrennt geregelt sind. Die Entwicklung einer Software beantwortet beispielsweise noch nicht die Frage, ob der Auftraggeber den Quellcode erhält, ob er die Software bearbeiten darf oder ob nur ein Nutzungsrecht für den internen Betrieb eingeräumt wird.

Die folgende Übersicht zeigt typische Abgrenzungen. Sie ersetzt keine Vertragsauslegung, verdeutlicht aber, welche Fragen im jeweiligen Vertragsteil im Vordergrund stehen.

In vielen Projekten sollten diese Bereiche bewusst kombiniert werden. Ein Entwicklungsvertrag ohne Nutzungsrechtsregelung kann für den Auftraggeber wirtschaftlich unzureichend sein, selbst wenn die Software technisch funktioniert. Umgekehrt kann ein Entwickler erhebliche Risiken eingehen, wenn er umfassende Rechte überträgt, ohne Vergütung, Vorleistungen, Drittsoftware und Open-Source-Komponenten zu berücksichtigen.

Besondere Aufmerksamkeit verdient die Abgrenzung zwischen Mängelbeseitigung und Weiterentwicklung. Ein Fehler liegt vor, wenn die Software die vereinbarte Beschaffenheit nicht erreicht. Ein Änderungswunsch liegt dagegen vor, wenn der Auftraggeber nachträglich zusätzliche oder andere Funktionen verlangt. Diese Grenze ist in IT-Projekten oft fließend. Je genauer Anforderungen, Akzeptanzkriterien und Änderungsprozesse formuliert sind, desto leichter lassen sich spätere Diskussionen einordnen.

Typische Fallkonstellationen aus der Praxis

Softwareentwicklungsverträge werden in sehr unterschiedlichen Situationen geschlossen. Die rechtlichen Schwerpunkte hängen stark davon ab, ob ein Startup eine Plattform entwickeln lässt, ein Mittelständler ein ERP-System erweitert oder ein Konzern Schnittstellen zwischen mehreren Systemen beauftragt. Dennoch zeigen sich wiederkehrende Konfliktmuster.

Ein häufiges Beispiel ist die Entwicklung einer App. Der Auftraggeber beschreibt die Grundidee, nennt einige Kernfunktionen und erwartet eine marktreife Anwendung. Der Entwickler kalkuliert nach Aufwand und geht davon aus, dass Detailentscheidungen im Projekt getroffen werden. Wenn später Funktionen fehlen, Performanceprobleme auftreten oder Stores die App nicht freigeben, stellt sich die Frage, ob diese Punkte zum geschuldeten Leistungsumfang gehörten.

Ein weiteres Praxisfeld betrifft Schnittstellenprojekte. Hier hängt der Erfolg oft von Drittsystemen, API-Dokumentationen, Zugängen, Testdaten und Mitwirkung des Auftraggebers ab. Wird nicht geregelt, wer welche Informationen wann bereitstellt, können Verzögerungen entstehen, die keiner Seite eindeutig zugeordnet werden können. Gerade bei ERP-, CRM- oder Shop-Systemen ist eine technische Abhängigkeit von vorhandenen Datenstrukturen regelmäßig ein rechtliches Risiko.

Auch bei Relaunches und Webplattformen entstehen typische Streitigkeiten. Auftraggeber erwarten Gestaltung, Frontend, Backend, SEO-Grundlagen, Datenschutzfunktionen, Cookie-Management, Tracking-Einbindung und Sicherheit aus einer Hand. Entwickler sehen einzelne Punkte möglicherweise als separate Leistungen. Ohne klare Leistungsbeschreibung kann ein scheinbar überschaubares Projekt erheblich anwachsen.

Bei agilen Projekten liegt der Schwerpunkt häufig weniger auf einem festen Pflichtenheft, sondern auf Backlog, Sprints, Priorisierung und laufender Abstimmung. Das kann sinnvoll sein, wenn Anforderungen noch nicht vollständig feststehen. Rechtlich sollte aber geklärt werden, welche Ergebnisse je Sprint erwartet werden, wie Abnahmen erfolgen, wer priorisiert und wann Budgetgrenzen erreicht sind. Agilität bedeutet nicht Vertragslosigkeit.

Leistungsbeschreibung, Abnahme und Änderungswünsche

Die Leistungsbeschreibung ist der Kern des Softwareentwicklungsvertrags. Sie bestimmt, welche Funktionen, Schnittstellen, Sicherheitsanforderungen, Performancewerte, Dokumentationen und Rahmenbedingungen geschuldet sind. Eine zu grobe Beschreibung führt häufig dazu, dass beide Parteien später unterschiedliche Vorstellungen für berechtigt halten. Eine zu starre Beschreibung kann dagegen Innovation und notwendige Anpassungen behindern.

In klassischen Projekten werden Lastenheft und Pflichtenheft unterschieden. Das Lastenheft beschreibt aus Sicht des Auftraggebers, was erreicht werden soll. Das Pflichtenheft konkretisiert aus Sicht des Auftragnehmers, wie die Anforderungen umgesetzt werden. In kleineren Projekten werden diese Dokumente oft zusammengefasst. Entscheidend ist, dass die Anforderungen überprüfbar bleiben. Formulierungen wie benutzerfreundlich, performant oder modern sind ohne weitere Kriterien auslegungsbedürftig.

Die Abnahme ist bei werkvertraglich geprägten Softwareentwicklungen besonders wichtig. Mit ihr bestätigt der Auftraggeber grundsätzlich, dass die Leistung im Wesentlichen vertragsgemäß erbracht wurde. Die Abnahme kann ausdrücklich, konkludent oder unter Umständen nach Fristsetzung erfolgen. Ihre Folgen sind erheblich: Vergütung wird häufig fällig, die Beweislast kann sich verschieben, und Mängelrechte knüpfen an den abgenommenen Zustand an.

Für Änderungswünsche sollte ein Change-Request-Verfahren vereinbart werden. Dieses Verfahren regelt, wie neue Anforderungen eingereicht, bewertet, kalkuliert und freigegeben werden. Ohne ein solches Verfahren besteht das Risiko, dass Änderungen informell per E-Mail, Chat oder Meeting beschlossen werden, später aber über Vergütung und Termine gestritten wird.

Praxisnah empfiehlt sich eine Unterscheidung zwischen Mängelmeldung, Optimierungswunsch und Erweiterung. Nicht jeder Wunsch nach anderer Bedienlogik ist ein Mangel. Umgekehrt kann der Entwickler nicht jeden Fehler als kostenpflichtige Zusatzleistung behandeln. Maßstab bleibt vorrangig die vereinbarte Beschaffenheit, ergänzt durch anerkannte fachliche Standards und den vertraglichen Zweck, soweit dieser erkennbar vereinbart wurde.

Rechte an Software: Quellcode, Nutzungsrechte, Open Source und Daten

Bei Softwareprojekten ist die Frage der Rechte oft wirtschaftlich wichtiger als der reine Programmieraufwand. Nach deutschem Urheberrecht sind Computerprogramme als Sprachwerke geschützt, insbesondere nach §§ 69a ff. UrhG. Der Auftraggeber erhält nicht automatisch alle Rechte, nur weil er die Entwicklung bezahlt. Er benötigt Nutzungsrechte, deren Umfang vertraglich geregelt werden sollte.

Zu klären ist insbesondere, ob die Nutzungsrechte einfach oder ausschließlich, zeitlich befristet oder unbefristet, räumlich beschränkt oder weltweit, übertragbar oder nicht übertragbar eingeräumt werden. Ebenso wichtig ist, ob der Auftraggeber die Software bearbeiten, dekompilieren, weiterentwickeln, mit anderer Software verbinden, Dritten zugänglich machen oder als SaaS-Angebot betreiben darf. Fehlen solche Regelungen, muss der Vertrag ausgelegt werden. Das kann zu Unsicherheit führen.

Der Quellcode ist gesondert zu betrachten. Ein Nutzungsrecht an der Software bedeutet nicht zwingend, dass der Auftraggeber den Quellcode herausverlangen oder verändern darf. Für Auftraggeber kann der Quellcode wichtig sein, um Anbieterabhängigkeit zu vermeiden, Sicherheitsprüfungen durchzuführen oder spätere Weiterentwicklung zu ermöglichen. Für Entwickler kann die Herausgabe dagegen problematisch sein, wenn Frameworks, Bibliotheken, eigene Basiskomponenten oder Know-how betroffen sind.

Open-Source-Komponenten sollten ausdrücklich adressiert werden. Viele Lizenzen erlauben Nutzung und Veränderung, enthalten aber Bedingungen zu Copyright-Hinweisen, Weitergabe, Quellcodeoffenlegung oder Lizenzkompatibilität. Wird Open Source unkontrolliert eingesetzt, kann dies Geschäftsmodelle beeinträchtigen oder Compliance-Risiken auslösen. Eine Software Bill of Materials, also eine Liste verwendeter Komponenten, kann hier sinnvoll sein.

Auch Datenrechte und Datenzugriff gehören in den Vertrag. Bei Trainingsdaten, Kundendaten, Logdaten, Analyseergebnissen oder generierten Inhalten sollte geregelt werden, wer diese nutzen darf, wie Daten bei Vertragsende exportiert werden und ob sie für Produktverbesserungen oder KI-Training verwendet werden dürfen. Zusätzlich können Datenschutzrecht, Geschäftsgeheimnisschutz und vertragliche Vertraulichkeitspflichten einschlägig sein.

Risiken, Haftung und typische Fehler im Softwareentwicklungsvertrag

Die größten Risiken entstehen selten aus einer einzelnen fehlerhaften Klausel. Häufig treffen unklare Leistungserwartungen, informelle Projektsteuerung, lückenhafte Dokumentation und ungeklärte Rechte zusammen. Der Softwareentwicklungsvertrag sollte deshalb nicht nur Haftung begrenzen, sondern Konflikte möglichst früh beherrschbar machen.

Auftraggeber riskieren insbesondere, eine Software zu erhalten, die zwar teilweise nutzbar ist, aber nicht zu den eigenen Prozessen passt oder rechtlich nicht frei verwertet werden darf. Entwickler riskieren, unbegrenzt nacharbeiten zu müssen, weil der Leistungsumfang nicht klar abgegrenzt wurde. Beide Seiten können zudem in Verzug geraten, wenn Mitwirkungen, Testdaten, Freigaben oder Teilabnahmen nicht rechtzeitig erfolgen.

Haftungsregelungen sind im B2B-Bereich grundsätzlich gestaltbar, unterliegen aber Grenzen. Bei Allgemeinen Geschäftsbedingungen greifen §§ 305 ff. BGB. Eine unangemessene Benachteiligung kann zur Unwirksamkeit führen. Für Vorsatz, grobe Fahrlässigkeit, Verletzung von Leben, Körper oder Gesundheit und teilweise für Kardinalpflichten gelten besondere Anforderungen. Auch Datenschutzverstöße, Sicherheitslücken und Schutzrechtsverletzungen sollten nicht vorschnell pauschal behandelt werden.

Typische Fehler sind insbesondere:

• Leistungsbeschreibung nur auf Basis einer Präsentation oder eines Angebots ohne prüfbare Akzeptanzkriterien
• keine klare Regelung zur Abnahme, Teilabnahme und Fiktion der Abnahme
• unklare Vergütung bei Mehraufwand, Änderungswünschen und Verzögerungen
• fehlende Nutzungsrechtsklauseln für Quellcode, Weiterentwicklung, SaaS-Betrieb oder Konzernnutzung
• keine Regelung zu Open Source, Drittsoftware, Lizenzen und technischen Abhängigkeiten
• fehlende Datenschutzvereinbarung bei Zugriff auf personenbezogene Daten
• unzureichende Dokumentation von Meetings, Freigaben, Tests und Mängelmeldungen
• Haftungsbegrenzungen, die pauschal übernommen werden und im Einzelfall unwirksam oder unpassend sind

Ein weiterer Fehler liegt darin, technische Risiken rein juristisch lösen zu wollen. Ein Vertrag kann keine unklare Architektur ersetzen. Er kann aber festlegen, wie technische Annahmen geprüft werden, wer welche Vorleistungen schuldet und wie mit Abweichungen umzugehen ist. Gerade bei sicherheitskritischer Software, Zahlungsfunktionen, Gesundheitsdaten oder automatisierten Entscheidungen sollte die Haftungsverteilung eng mit technischen Prüf- und Freigabeprozessen verbunden werden.

Fristen, Verjährung, Verzug und Kündigung

Fristen spielen im Softwareentwicklungsvertrag auf mehreren Ebenen eine Rolle. Zunächst geht es um Projekttermine: Start, Meilensteine, Testphasen, Abnahmen, Go-live und Übergabe. Ob ein Termin verbindlich ist oder nur eine Planung darstellt, sollte ausdrücklich geregelt werden. Verbindliche Termine können bei Überschreitung Verzug auslösen, wenn die gesetzlichen Voraussetzungen erfüllt sind oder eine Mahnung entbehrlich ist.

Bei werkvertraglichen Projekten ist die Abnahme ein zentraler Zeitpunkt. Sie kann für Fälligkeit, Beginn der Gewährleistungsfrist und Beweislast bedeutsam sein. Der Auftraggeber sollte Mängel nicht nur mündlich melden, sondern nachvollziehbar dokumentieren und angemessene Fristen zur Nacherfüllung setzen, soweit dies erforderlich ist. Der Entwickler sollte seinerseits festhalten, wann Leistungen zur Abnahme bereitgestellt wurden und welche Reaktionen erfolgt sind.

Die Verjährung hängt von der Anspruchsgrundlage ab. Für Mängelansprüche aus Werkvertrag gilt häufig § 634a BGB. Bei Software, die kein Bauwerk betrifft, kommt regelmäßig eine zweijährige Verjährungsfrist in Betracht. Andere Ansprüche, etwa auf Zahlung, Schadensersatz außerhalb der werkvertraglichen Mängelrechte oder vertragliche Nebenpflichtverletzungen, können der regelmäßigen Verjährung nach §§ 195, 199 BGB unterliegen. Diese beträgt grundsätzlich drei Jahre und beginnt regelmäßig mit dem Schluss des Jahres, in dem Anspruch und Kenntnis oder grob fahrlässige Unkenntnis vorliegen. Im Einzelfall können Sonderregeln, Hemmungstatbestände oder vertragliche Vereinbarungen eingreifen.

Auch Kündigungsrechte sind wichtig. Beim Werkvertrag kann der Besteller nach § 648 BGB grundsätzlich bis zur Vollendung des Werks kündigen, schuldet dann aber regelmäßig die vereinbarte Vergütung abzüglich ersparter Aufwendungen. Daneben kommt eine Kündigung aus wichtigem Grund nach § 648a BGB in Betracht. Bei Dauerschuldverhältnissen kann § 314 BGB relevant sein. Vertragsklauseln sollten regeln, was bei Vertragsende mit Zwischenergebnissen, Quellcode, Dokumentation, Zugängen, Daten und bereits gezahlten Beträgen geschieht.

Fristen sollten nicht nur juristisch, sondern operativ verstanden werden. Wer Abnahmen, Tests oder Freigaben zu lange offenlässt, erschwert später die Durchsetzung eigener Rechte. Ebenso können Entwickler Nachteile erleiden, wenn sie Leistungsänderungen ausführen, ohne Mehrkosten und Terminfolgen zeitnah zu bestätigen.

Beweise und Dokumentation im IT-Projekt

Im Streit über einen Softwareentwicklungsvertrag entscheidet häufig nicht allein die Rechtslage, sondern die Nachweisbarkeit. Wer behauptet, eine Funktion sei vereinbart, ein Mangel sei gemeldet oder ein Änderungswunsch sei freigegeben worden, muss dies im Streitfall belegen können. Gerade IT-Projekte arbeiten mit Tickets, Chats, Videokonferenzen, Prototypen und laufenden Abstimmungen. Diese Kommunikation ist praktisch sinnvoll, aber beweisrechtlich nur dann hilfreich, wenn sie geordnet gesichert wird.

Eine gute Dokumentation beginnt vor Vertragsschluss. Angebote, Leistungsbeschreibungen, technische Anhänge, Architekturentscheidungen und Protokolle sollten versioniert werden. Während des Projekts sollten Meetings kurz zusammengefasst, Entscheidungen schriftlich bestätigt und Tickets mit klaren Zuständigkeiten versehen werden. Bei Tests sollten Testfälle, Testergebnisse, Screenshots, Logs und Fehlermeldungen gespeichert werden.

Wichtige Nachweise sind insbesondere:

• unterzeichneter Vertrag einschließlich Anlagen, Leistungsbeschreibung und Lizenzbedingungen
• Versionen von Lastenheft, Pflichtenheft, Backlog, User Stories und Akzeptanzkriterien
• Protokolle von Kick-off, Sprint-Reviews, Lenkungsausschüssen und Abnahmebesprechungen
• E-Mails, Tickets und Freigaben zu Änderungswünschen, Mehraufwand und Terminverschiebungen
• Testpläne, Testdaten, Fehlertickets, Screenshots, Logdateien und Reproduktionsschritte
• Abnahmeerklärungen, Vorbehalte, Mängellisten und Fristsetzungen zur Nacherfüllung
• Nachweise über Mitwirkungshandlungen, bereitgestellte Zugänge, Daten und Dokumentationen
• Listen verwendeter Drittsoftware, Open-Source-Komponenten und Lizenzhinweise

Bei erheblichen Mängeln kann ein technisches Gutachten oder eine unabhängige Codeanalyse erforderlich werden. Dies sollte jedoch sorgfältig vorbereitet werden, damit Untersuchungen reproduzierbar sind und keine Beweise verloren gehen. Vor allem bei produktiven Systemen ist zu beachten, dass Updates, Hotfixes oder Datenbereinigungen den ursprünglichen Fehlerzustand verändern können.

Handlungsschritte und Checkliste für Auftraggeber und Entwickler

Ein tragfähiger Softwareentwicklungsvertrag entsteht nicht erst durch juristische Klauseln. Er setzt voraus, dass technische, wirtschaftliche und organisatorische Annahmen offen gelegt werden. Die folgende Checkliste hilft, ein Projekt vor Vertragsschluss zu strukturieren und während der Durchführung belastbare Entscheidungen zu dokumentieren. Nicht jeder Punkt ist in jedem Projekt gleich wichtig; bei komplexen oder geschäftskritischen Vorhaben sollten die Punkte jedoch bewusst geprüft werden.

• Projektziel schriftlich festlegen: Beschreiben Sie, welches geschäftliche Problem die Software lösen soll und welche Kernfunktionen unverzichtbar sind.
• Leistungsumfang konkretisieren: Halten Sie Funktionen, Schnittstellen, Rollen, Datenflüsse, Sicherheitsanforderungen, Browser, Endgeräte und Performancewerte möglichst überprüfbar fest.
• Vertragstyp und Vergütungsmodell prüfen: Klären Sie, ob ein Festpreis, Time-and-Material, Meilensteinvergütung oder ein hybrides Modell wirtschaftlich und rechtlich passt.
• Mitwirkungspflichten terminieren: Legen Sie Fristen für Testdaten, Zugänge, Ansprechpartner, Freigaben und Feedback fest, damit Verzögerungen zugeordnet werden können.
• Abnahmeverfahren regeln: Vereinbaren Sie Testzeiträume, Teilabnahmen, Mängelkategorien, Abnahmeprotokolle und Folgen ausbleibender Rückmeldung.
• Change Requests dokumentieren: Neue Anforderungen sollten mit Aufwand, Preisfolge, Terminfolge und Freigabe schriftlich erfasst werden, bevor sie umgesetzt werden.
• Nutzungsrechte präzise formulieren: Regeln Sie Quellcode, Bearbeitungsrechte, Weitergabe, SaaS-Nutzung, Konzernnutzung, Drittsoftware und Open-Source-Komponenten.
• Datenschutz und Sicherheit prüfen: Bei personenbezogenen Daten sind Rollen, Auftragsverarbeitung, technische und organisatorische Maßnahmen sowie Lösch- und Exportprozesse zu klären.
• Dokumentationspflichten vereinbaren: Legen Sie fest, welche technische Dokumentation, Installationsanleitung, API-Dokumentation und Admin-Dokumentation geschuldet ist.
• Fristen und Verjährung überwachen: Notieren Sie Abnahmedatum, Mängelmeldungen, Nacherfüllungsfristen und vertragliche Ausschluss- oder Reaktionsfristen in einem Projektkalender.
• Exit-Szenario vorbereiten: Regeln Sie Datenherausgabe, Quellcodeübergabe, Übergabedokumentation, offene Vergütung und Unterstützung beim Anbieterwechsel.
• Kommunikation bündeln: Nutzen Sie ein zentrales Ticketsystem oder eine dokumentierte Projektplattform, statt wesentliche Entscheidungen nur in Chats oder Telefonaten zu treffen.

Für Auftraggeber ist besonders wichtig, die eigenen Erwartungen nicht nur fachlich, sondern auch rechtlich wirksam in den Vertrag zu überführen. Für Entwickler ist entscheidend, den geschuldeten Leistungsumfang und die Grenzen der Verantwortung realistisch abzubilden. Beide Seiten profitieren davon, wenn technische Unsicherheiten nicht verschwiegen, sondern als Annahmen, Abhängigkeiten oder Optionen dokumentiert werden.

Kommt es bereits zu einem Konflikt, sollte zunächst der aktuelle Vertragsstand gesichert werden. Dazu gehören Vertrag, Anlagen, Tickets, Protokolle, Rechnungen, Quellcodeversionen und Mängelkommunikation. Anschließend ist zu prüfen, ob eine Nachbesserung, ein geordneter Projektabschluss, eine Vertragsänderung, eine Teilkündigung oder die Geltendmachung von Ansprüchen in Betracht kommt. Welche Option sinnvoll ist, hängt stark von Projektstand, wirtschaftlicher Bedeutung und Beweislage ab.

Besondere Themen: Datenschutz, IT-Sicherheit und Geheimnisschutz

Softwareentwicklung berührt häufig personenbezogene Daten. Greift der Entwickler auf Kundendaten, Mitarbeiterdaten, Testdaten oder Produktivsysteme zu, muss datenschutzrechtlich geprüft werden, welche Rolle die Beteiligten einnehmen. Häufig kommt eine Auftragsverarbeitung nach Art. 28 DSGVO in Betracht. Dann reicht der Softwareentwicklungsvertrag allein nicht aus; es wird zusätzlich ein Vertrag zur Auftragsverarbeitung mit Regelungen zu Gegenstand, Dauer, Weisungen, technischen und organisatorischen Maßnahmen sowie Unterauftragnehmern benötigt.

Datenschutz sollte nicht erst kurz vor Go-live behandelt werden. Anforderungen wie Privacy by Design, Löschkonzepte, Berechtigungssysteme, Protokollierung, Datenminimierung und Exportfunktionen können technische Architekturentscheidungen beeinflussen. Werden sie zu spät adressiert, entstehen Mehrkosten und Verzögerungen. Ob diese als Mangel, Zusatzleistung oder Mitwirkungsversäumnis einzuordnen sind, hängt vom Vertrag ab.

IT-Sicherheit ist ebenfalls ein rechtlich relevanter Vertragsbestandteil. Bei Webanwendungen, Zahlungsfunktionen, Gesundheitsdaten oder kritischen Geschäftsprozessen sollten Sicherheitsstandards, Penetrationstests, Patchpflichten, Schwachstellenmanagement und Meldewege festgelegt werden. Ohne konkrete Vereinbarung bleibt häufig streitig, welcher Sicherheitsstandard geschuldet war. Anerkannte Standards können zwar bei der Auslegung helfen, ersetzen aber keine projektspezifische Regelung.

Geschäftsgeheimnisse verdienen besondere Aufmerksamkeit. Entwickler erhalten oft Einblick in Prozesse, Preislogiken, Kundendaten, Produktideen oder Algorithmen. Vertraulichkeitsklauseln sollten daher klar bestimmen, welche Informationen geschützt sind, wie lange die Pflicht gilt, welche Ausnahmen bestehen und wie Unterauftragnehmer eingebunden werden. Umgekehrt können auch Entwickler eigene Frameworks, Tools und Bibliotheken schützen wollen.

FAQ zum Softwareentwicklungsvertrag

Fazit: Softwareentwicklungsvertrag sorgfältig planen und laufend dokumentieren

Ein Softwareentwicklungsvertrag sollte technische Erwartungen, rechtliche Verantwortlichkeiten und wirtschaftliche Risiken zusammenführen. Vorrangig sind eine klare Leistungsbeschreibung, nachvollziehbare Abnahmeregeln, ein funktionierendes Änderungsverfahren und präzise Nutzungsrechte. Erst danach lassen sich Haftung, Fristen, Kündigung und Vergütung sinnvoll bewerten.

Für Auftraggeber steht meist die Frage im Vordergrund, ob die entwickelte Software tatsächlich nutzbar, verwertbar und weiterentwickelbar ist. Für Entwickler geht es darum, Leistungspflichten, Mitwirkungen und Zusatzaufwand realistisch abzugrenzen. Beide Seiten sollten Entscheidungen, Tests, Freigaben und Mängel von Beginn an dokumentieren.

Ob ein bestimmter Anspruch besteht, eine Kündigung sinnvoll ist oder eine Klausel wirksam greift, hängt stets vom konkreten Vertrag, Projektverlauf und Beweisstand ab. Wer frühzeitig strukturiert prüft, kann Konflikte oft begrenzen und die eigenen Handlungsoptionen besser einschätzen.