Software-Erstellungsvertrag Vorlage (Word & PDF)

Mit unserer kostenlosen Software-Erstellungsvertrag Vorlage kannst du die Entwicklung einer individuellen Software zwischen Auftraggeber und Auftragnehmer schriftlich regeln. Die Vorlage enthält unter anderem Regelungen zu Leistungsumfang, technischen Anforderungen, Projektphasen, Meilensteinen, Mitwirkungspflichten, Vergütung, Änderungswünschen, Tests, Abnahme, Mängeln, Quellcode und Nutzungsrechten.

Gerade bei Softwareprojekten reicht eine kurze Vereinbarung wie „Entwicklung einer App“ oder „Programmierung einer individuellen Software“ häufig nicht aus. Je genauer beschrieben wird, welches Ergebnis geschuldet ist, welche Funktionen enthalten sind und wie Änderungen während des Projekts behandelt werden, desto leichter lassen sich spätere Missverständnisse vermeiden.

Die Vorlage steht als Word- und PDF-Datei zur Verfügung. Die Word-Version lässt sich an Projekt, Software, Vergütungsmodell und Rechteübertragung anpassen. Die PDF-Version eignet sich zum Ausdrucken, Prüfen und gemeinsamen Besprechen.

Für welche Softwareprojekte eignet sich die Vorlage?

Die Vorlage kann für unterschiedliche individuelle Entwicklungsprojekte angepasst werden.

Zum Beispiel für:

• Webanwendungen
• Unternehmenssoftware
• individuelle Datenbanken
• mobile Apps
• Schnittstellen und APIs
• Automatisierungslösungen
• interne Verwaltungssoftware
• Kundenportale
• Online-Plattformen
• Plugins und Erweiterungen
• individuelle Shop-Funktionen
• Software zur Prozessdigitalisierung

Was gehört in einen Software-Erstellungsvertrag?

Ein Software-Erstellungsvertrag sollte das gewünschte Ergebnis und die Bedingungen der Entwicklung möglichst genau dokumentieren.

Typische Bestandteile sind:

• Auftraggeber und Auftragnehmer
• Projektgegenstand
• Funktionsumfang
• technische Anforderungen
• Schnittstellen
• Projektphasen und Meilensteine
• Projektverantwortliche
• Mitwirkungspflichten des Auftraggebers
• Test- und Abnahmeverfahren
• Change-Request-Verfahren
• Vergütung und Zahlungsplan
• Drittsoftware und Open-Source-Komponenten
• Dokumentation
• Quellcode
• Nutzungsrechte
• Datenschutz
• Geheimhaltung
• Mängelbeseitigung
• Haftung
• Projektabbruch und Übergabe

So verwendest du die Software-Erstellungsvertrag Vorlage

1. Datei herunterladen: Öffne die Word-Version zum Bearbeiten oder nutze die PDF-Version zum Ausdrucken.
2. Projekt beschreiben: Trage ein, welche Software entwickelt werden soll.
3. Funktionen festlegen: Definiere die geschuldeten Funktionen möglichst konkret.
4. Technische Anforderungen ergänzen: Lege Plattformen, Schnittstellen und technische Rahmenbedingungen fest.
5. Meilensteine bestimmen: Teile größere Projekte in nachvollziehbare Projektphasen auf.
6. Mitwirkung regeln: Bestimme, welche Inhalte, Zugänge und Entscheidungen der Auftraggeber liefern muss.
7. Vergütung eintragen: Vereinbare Festpreis, Teilzahlungen oder andere Vergütungsmodelle.
8. Änderungsverfahren festlegen: Bestimme, wie zusätzliche Wünsche kalkuliert und freigegeben werden.
9. Abnahme definieren: Lege Testverfahren, Fristen und Umgang mit Mängeln fest.
10. Nutzungsrechte anpassen: Regle ausdrücklich, wie und in welchem Umfang die fertige Software genutzt werden darf.

Beispiel für ein Softwareprojekt

Projektgegenstand möglichst genau beschreiben

Der Projektgegenstand ist einer der wichtigsten Teile des Vertrags.

Statt lediglich „Entwicklung einer Software zur Kundenverwaltung“ zu vereinbaren, sollte möglichst klar beschrieben werden, was das fertige System können muss.

Pflichtenheft oder Leistungsbeschreibung als Anlage

Bei größeren Projekten kann es sinnvoll sein, den detaillierten Funktionsumfang nicht vollständig in den Vertragstext aufzunehmen.

Stattdessen kann eine separate Leistungsbeschreibung als Anlage verwendet werden.

Darin können beispielsweise dokumentiert werden:

• Funktionen
• Benutzerrollen
• Workflows
• Masken und Ansichten
• Schnittstellen
• Berichte
• Datenimporte
• Exporte
• Berechtigungen
• technische Voraussetzungen

Die Anlage sollte im Vertrag eindeutig bezeichnet und als Vertragsbestandteil einbezogen werden.

Erfolg oder bloße Tätigkeit?

Bei der Erstellung individueller Software wird häufig ein bestimmtes funktionsfähiges Ergebnis geschuldet. Solche Projekte können deshalb werkvertragliche Elemente aufweisen.

§ 631 BGB beschreibt den Werkvertrag als Vertrag, bei dem der Unternehmer zur Herstellung des versprochenen Werkes und der Besteller zur Zahlung der vereinbarten Vergütung verpflichtet wird.

Den aktuellen Gesetzestext findest du unter § 631 BGB.

Softwareentwicklung klar von laufenden Dienstleistungen trennen

Nicht jede Tätigkeit eines Programmierers ist automatisch die Herstellung eines bestimmten fertigen Werkes.

Beratung, laufende Unterstützung, Administration oder die Bereitstellung von Entwicklerkapazitäten können anders ausgestaltet sein.

Wenn hauptsächlich laufende Leistungen und keine konkret definierte fertige Software geschuldet werden, kann unsere Dienstleistungsvertrag Vorlage besser passen.

Funktionen als Muss- und Wunschleistungen einteilen

Bei umfangreichen Projekten kann zwischen zwingenden und optionalen Funktionen unterschieden werden.

Dadurch ist klarer, welche Funktionen zum vereinbarten Projektpreis gehören.

Technische Anforderungen festhalten

Neben der eigentlichen Funktion kann auch die technische Umgebung entscheidend sein.

Typische Angaben sind:

• Betriebssystem
• Programmiersprache
• Framework
• Datenbank
• Serverumgebung
• Cloud-Plattform
• Browserunterstützung
• mobile Betriebssysteme
• Schnittstellen
• Authentifizierungssysteme

Technik nicht unnötig festschreiben

Andererseits sollte ein Vertrag technische Details nur dann zwingend vorgeben, wenn dies tatsächlich erforderlich ist.

Wird beispielsweise eine bestimmte Programmiersprache vorgeschrieben, obwohl für den Auftraggeber nur die Funktion entscheidend ist, kann dies die technische Umsetzung unnötig einschränken.

Schnittstellen eindeutig beschreiben

Muss die neue Software mit bestehenden Systemen kommunizieren, sollten die betroffenen Schnittstellen bezeichnet werden.

Beispiele:

• ERP-System
• CRM
• Zahlungsanbieter
• Buchhaltungssoftware
• Versanddienstleister
• Newsletter-System
• Identity Provider
• Drittanbieter-API

Abhängigkeit von Fremdsystemen berücksichtigen

Funktionieren externe Schnittstellen später nicht mehr oder werden sie vom Anbieter verändert, kann der Entwickler darauf möglicherweise keinen Einfluss haben.

Der Vertrag sollte deshalb unterscheiden zwischen Fehlern der eigenen Software und Problemen, die ausschließlich durch externe Dienste verursacht werden.

Projektphasen und Meilensteine

Ein großes Softwareprojekt lässt sich häufig besser steuern, wenn einzelne Phasen definiert werden.

Beispielsweise:

• Analyse
• Konzeption
• technischer Entwurf
• Entwicklung
• interner Test
• Test durch Auftraggeber
• Fehlerkorrektur
• Abnahme
• Produktivsetzung

Beispiel für einen Meilensteinplan

Projekttermine realistisch vereinbaren

Softwareprojekte sind häufig von Entscheidungen und Zulieferungen des Auftraggebers abhängig.

Ein Fertigstellungstermin sollte deshalb nicht isoliert betrachtet werden.

Benötigt der Entwickler beispielsweise:

• Zugangsdaten,
• Testdaten,
• Designs,
• Schnittstellendokumentationen,
• Freigaben oder
• fachliche Entscheidungen,

sollte geregelt werden, welche Auswirkungen verspätete Mitwirkung auf den Zeitplan hat.

Mitwirkungspflichten des Auftraggebers

Der Auftraggeber muss bei Individualsoftware häufig aktiv mitwirken.

Die Vorlage enthält deshalb einen eigenen Abschnitt für solche Pflichten.

Typische Mitwirkungen sind:

• Benennung eines Projektverantwortlichen
• Bereitstellung von Informationen
• fachliche Entscheidungen
• Testdaten
• Systemzugänge
• Prüfung von Zwischenständen
• rechtzeitige Freigaben
• Durchführung von Abnahmetests

Ansprechpartner auf beiden Seiten festlegen

Gerade wenn mehrere Personen am Projekt beteiligt sind, sollten feste Ansprechpartner benannt werden.

Was ist im vereinbarten Preis enthalten?

Der Vertrag sollte möglichst klar festlegen, welche Leistungen vom vereinbarten Projektpreis umfasst sind.

Beispielsweise:

• Konzeption
• Programmierung
• interne Tests
• Einrichtung eines Testsystems
• Dokumentation
• Installation
• Datenmigration
• Schulung
• Produktivsetzung

Nicht enthaltene Leistungen ausdrücklich nennen

Ebenso hilfreich ist eine Liste von Leistungen, die nicht Teil des Projekts sind.

Festpreis oder Abrechnung nach Aufwand?

Softwareprojekte können unterschiedlich vergütet werden.

Typische Modelle sind:

• Festpreis
• Stundenhonorar
• Tagessatz
• Festpreis pro Projektphase
• Kombination aus Festpreis und zusätzlichem Aufwand

Bei einem Festpreis ist eine klare Leistungsbeschreibung besonders wichtig.

Zahlungsplan an Meilensteine koppeln

Bei größeren Projekten muss nicht zwingend die gesamte Vergütung erst am Projektende bezahlt werden.

Teilzahlungen können beispielsweise an Meilensteine gekoppelt werden.

Change Requests: Was passiert bei Änderungswünschen?

Während einer Softwareentwicklung entstehen fast immer neue Wünsche.

Ohne klare Regelung kann später unklar sein, ob ein Wunsch bereits im ursprünglichen Preis enthalten war oder zusätzlich bezahlt werden muss.

Deshalb enthält die Vorlage ein Verfahren für sogenannte Change Requests.

Änderungen schriftlich dokumentieren

Ein Änderungswunsch sollte mindestens enthalten:

• Beschreibung der gewünschten Änderung
• technische Auswirkungen
• zusätzlichen Aufwand
• Preisänderung
• Auswirkungen auf Termine
• Freigabe durch den Auftraggeber

Beispiel für einen Change Request

Keine Zusatzleistung ohne Freigabe

In der Praxis kann vereinbart werden, dass kostenpflichtige Änderungen erst nach Freigabe durch den Auftraggeber umgesetzt werden.

Das verhindert Überraschungen bei der späteren Abrechnung.

Testphase vor der Abnahme

Vor der Abnahme sollte der Auftraggeber Gelegenheit haben, die Software anhand der vereinbarten Anforderungen zu prüfen.

Ein Testplan kann beispielsweise enthalten:

• zu prüfende Funktionen
• Testsystem
• Testdaten
• Testzeitraum
• verantwortliche Personen
• Dokumentation gefundener Fehler

Abnahme als wichtiger Projektpunkt

Bei werkvertraglich ausgestalteten Softwareprojekten ist die Abnahme ein zentraler Schritt.

§ 640 BGB sieht vor, dass der Besteller das vertragsmäßig hergestellte Werk grundsätzlich abzunehmen hat, sofern die Abnahme nicht nach der Beschaffenheit ausgeschlossen ist. Wegen unwesentlicher Mängel kann die Abnahme grundsätzlich nicht verweigert werden.

Den aktuellen Gesetzestext findest du unter § 640 BGB.

Abnahme nicht mit „Software funktioniert irgendwie“ verwechseln

Eine sinnvolle Abnahme orientiert sich an den vertraglich vereinbarten Anforderungen.

Die Frage ist also nicht nur, ob die Anwendung startet, sondern beispielsweise:

• sind alle vereinbarten Funktionen vorhanden?
• funktionieren die Schnittstellen?
• werden Daten korrekt gespeichert?
• sind Benutzerrechte umgesetzt?
• funktionieren vereinbarte Exporte?

Abnahmeprotokoll verwenden

Das Ergebnis des Abnahmetests sollte schriftlich dokumentiert werden.

Mögliche Ergebnisse sind:

• Abnahme ohne Vorbehalt
• Abnahme mit dokumentierten Restmängeln
• Verweigerung der Abnahme wegen konkret benannter wesentlicher Mängel

Mängel nach Priorität einteilen

Bei Software kann eine Einteilung nach Schweregrad hilfreich sein.

Unwesentliche Mängel und Abnahme

§ 640 BGB stellt ausdrücklich klar, dass die Abnahme wegen unwesentlicher Mängel grundsätzlich nicht verweigert werden kann.

Das bedeutet jedoch nicht, dass solche Mängel ignoriert werden müssen. Sie können im Abnahmeprotokoll dokumentiert und anschließend behoben werden.

Abnahmefrist vereinbaren

Der Vertrag kann festlegen, innerhalb welchen Zeitraums der Auftraggeber nach Bereitstellung einer abnahmefähigen Version testen soll.

Die Frist sollte realistisch zur Komplexität der Software passen.

Dokumentation gehört zum Projekt

Je nach Software können unterschiedliche Dokumentationen erforderlich sein.

Zum Beispiel:

• Benutzerhandbuch
• Administrator-Dokumentation
• Installationsanleitung
• API-Dokumentation
• Datenbankbeschreibung
• Deployment-Anleitung
• Quellcode-Kommentare

Im Vertrag sollte stehen, welche Dokumentation tatsächlich geliefert wird.

Quellcode ausdrücklich regeln

Der Auftraggeber sollte nicht automatisch davon ausgehen, dass mit der fertigen Software in jedem Fall sämtliche Entwicklungsdateien und der vollständige Quellcode in jeder gewünschten Form übergeben werden.

Der Vertrag sollte deshalb ausdrücklich regeln:

• ob Quellcode herausgegeben wird,
• wann die Übergabe erfolgt,
• in welchem Repository oder Format,
• ob Build- und Deployment-Dateien dazugehören und
• welche fremden Bestandteile ausgenommen sind.

Repository-Zugriff festlegen

Bei längeren Projekten kann vereinbart werden, ob der Auftraggeber bereits während der Entwicklung Zugriff auf ein Git-Repository erhält.

Dabei sollte geklärt werden, ob dieser Zugriff nur der Transparenz dient oder ob der Auftraggeber bereits während des Projekts Änderungen vornehmen darf.

Nutzungsrechte an der Software

Software kann urheberrechtlich geschützt sein. § 69a UrhG enthält besondere Vorschriften für Computerprogramme.

Computerprogramme sind danach in jeder Gestalt einschließlich ihres Entwurfsmaterials erfasst, sofern die gesetzlichen Schutzvoraussetzungen vorliegen.

Den aktuellen Gesetzestext findest du unter § 69a UrhG.

Einfache oder ausschließliche Nutzungsrechte?

§ 31 UrhG unterscheidet unter anderem zwischen einfachen und ausschließlichen Nutzungsrechten.

Beim einfachen Nutzungsrecht kann der Rechteinhaber grundsätzlich auch anderen Personen entsprechende Nutzungsrechte einräumen. Ein ausschließliches Nutzungsrecht kann dem Vertragspartner eine deutlich weitergehende Stellung vermitteln.

Den Gesetzestext findest du unter § 31 UrhG.

Nutzungsrechte konkret beschreiben

Statt pauschal nur „alle Rechte gehen auf den Auftraggeber über“ zu schreiben, sollte möglichst genau geregelt werden, welche Nutzung erlaubt ist.

Dazu können gehören:

• dauerhafte Nutzung
• räumlich unbeschränkte Nutzung
• Nutzung durch verbundene Unternehmen
• Vervielfältigung
• Bearbeitung
• Weiterentwicklung
• Integration in andere Systeme
• Nutzung durch externe IT-Dienstleister
• Weitergabe oder Unterlizenzierung

Rechteübertragung an Zahlung koppeln

In Softwareverträgen kann vereinbart werden, dass die vorgesehenen Nutzungsrechte erst mit vollständiger Zahlung der geschuldeten Vergütung eingeräumt werden.

Wenn dies gewünscht ist, sollte die Regelung klar im Vertrag stehen.

Vorbestehende Softwarebestandteile

Entwickler verwenden häufig bereits vorhandene Bibliotheken, Frameworks, Module oder eigene Basiskomponenten.

Diese sollten von der speziell für den Auftraggeber erstellten Individualsoftware unterschieden werden.

Open-Source-Software berücksichtigen

Viele moderne Softwareprojekte verwenden Open-Source-Komponenten.

Diese stehen unter eigenen Lizenzbedingungen und können deshalb nicht einfach so behandelt werden, als hätte der Auftragnehmer sämtliche Rechte daran selbst geschaffen.

Im Vertrag kann festgehalten werden, dass eingesetzte Open-Source-Komponenten dokumentiert und deren Lizenzbedingungen eingehalten werden.

Drittsoftware und Lizenzkosten

Neben Open Source können kostenpflichtige Produkte oder Dienste erforderlich sein.

Zum Beispiel:

• Cloud-Dienste
• Karten-APIs
• SMS-Dienste
• Zahlungsanbieter
• kommerzielle Bibliotheken
• Schriftarten
• Stock-Medien

Der Vertrag sollte klären, ob solche Kosten im Projektpreis enthalten sind oder separat vom Auftraggeber getragen werden.

Zugangsdaten und Konten

Für produktive Systeme sollte möglichst klar sein, wem Accounts und Zugänge gehören.

Besonders wichtig kann das bei folgenden Diensten sein:

• Hosting
• Cloud-Plattform
• Domain
• App Store
• Google Play
• Zahlungsanbieter
• E-Mail-Dienste
• Git-Repositories

Geschäftskritische Konten sollten nach Möglichkeit nicht ausschließlich auf private Accounts eines einzelnen Entwicklers laufen.

Deployment und Produktivsetzung

Der Vertrag sollte unterscheiden, ob nur eine fertige Software geliefert oder zusätzlich die Produktivsetzung übernommen wird.

Dazu können gehören:

• Serverkonfiguration
• Datenbankeinrichtung
• Datenmigration
• DNS-Anpassungen
• SSL-Konfiguration
• Deployment
• Funktionsprüfung nach Livegang

Datenmigration gesondert planen

Die Übernahme bestehender Daten kann ein erheblicher eigener Projektteil sein.

Zu regeln sind beispielsweise:

• Datenquelle
• Datenformat
• Datenqualität
• Mapping
• Testmigration
• Verantwortung für fehlerhafte Altdaten

Datenschutz beim Softwareprojekt

Werden im Rahmen der Entwicklung personenbezogene Daten verarbeitet, können zusätzliche datenschutzrechtliche Anforderungen entstehen.

Das betrifft beispielsweise:

• Produktivdaten
• Kundendaten
• Mitarbeiterdaten
• Testdaten mit Personenbezug
• Zugriff auf bestehende Systeme

Ob zusätzlich eine Vereinbarung zur Auftragsverarbeitung erforderlich ist, hängt von der konkreten Rollenverteilung und Datenverarbeitung ab.

Testdaten möglichst bewusst auswählen

Für Entwicklungs- und Testsysteme sollten nach Möglichkeit keine unnötigen realen personenbezogenen Daten verwendet werden.

Wo möglich können anonymisierte oder künstliche Testdaten geeigneter sein.

Geheimhaltung bei Softwareprojekten

Entwickler erhalten häufig Einblick in sensible Informationen des Auftraggebers.

Zum Beispiel:

• Geschäftsprozesse
• Produktideen
• Kundendaten
• interne Systeme
• Passwörter und Zugänge
• Preis- und Kalkulationsmodelle
• noch unveröffentlichte Produkte

Bei besonders sensiblen Projekten kann ergänzend unsere Geheimhaltungsvereinbarung / NDA Vorlage verwendet werden.

Backups während der Entwicklung

Bei geschäftskritischer Software sollte geklärt sein, wer für Sicherungskopien verantwortlich ist.

Das gilt insbesondere, wenn:

• bestehende Systeme verändert werden,
• Daten migriert werden oder
• Entwicklung direkt auf produktiven Systemen stattfindet.

Testsystem und Produktivsystem trennen

Wo technisch sinnvoll, kann eine getrennte Testumgebung Risiken reduzieren.

Neue Versionen können dort geprüft werden, bevor Änderungen im laufenden Produktivsystem vorgenommen werden.

Schulung und Einweisung

Bei komplexerer Software kann eine Einweisung der späteren Benutzer oder Administratoren Bestandteil des Projekts sein.

Im Vertrag sollte dann stehen:

• Anzahl der Schulungen
• Dauer
• Teilnehmerzahl
• online oder vor Ort
• Schulungsunterlagen

Softwarepflege ist nicht automatisch dauerhaft enthalten

Die Erstellung einer Software und ihre spätere laufende Pflege sind unterschiedliche Leistungen.

Nach Projektabschluss können beispielsweise erforderlich werden:

• Updates
• Anpassungen an neue Betriebssysteme
• Sicherheitsupdates
• Fehleranalyse
• Support
• Überwachung
• Anpassungen an geänderte Schnittstellen

Solche laufenden Leistungen sollten gesondert vereinbart werden, wenn sie nicht ausdrücklich Bestandteil des Erstellungsvertrags sind.

Neue Funktionen sind nicht automatisch Mängelbeseitigung

Ein späterer Wunsch nach einer zusätzlichen Funktion ist etwas anderes als ein Fehler in einer bereits vereinbarten Funktion.

Was ist ein Softwaremangel?

Ob ein Fehler vorliegt, richtet sich wesentlich danach, was vertraglich vereinbart wurde.

Ein Softwareproblem kann beispielsweise vorliegen, wenn:

• eine zugesagte Funktion fehlt,
• eine Funktion reproduzierbar falsche Ergebnisse liefert,
• eine vereinbarte Schnittstelle nicht funktioniert oder
• die Software wesentliche vereinbarte Anforderungen nicht erfüllt.

Fehlermeldungen nachvollziehbar dokumentieren

Bei der Fehlersuche helfen möglichst konkrete Informationen.

Eine Meldung kann beispielsweise enthalten:

• betroffene Funktion
• verwendeter Benutzer
• Testschritte
• erwartetes Ergebnis
• tatsächliches Ergebnis
• Screenshot
• Fehlermeldung
• Zeitpunkt

Keine Garantie für fehlerfreie Software versprechen

Software kann sehr komplex sein. Der Vertrag sollte nicht leichtfertig absolute Zusagen wie „vollständig fehlerfrei unter allen Umständen“ enthalten.

Entscheidend sollte sein, ob die vereinbarte Beschaffenheit und Funktion erreicht wird und wie mit festgestellten Mängeln umgegangen wird.

Haftung individuell prüfen

Haftungsregelungen hängen stark von Projekt, Vertragspartnern und möglichen Schäden ab.

Besonders relevant können sein:

• Datenverlust
• Betriebsunterbrechung
• entgangener Gewinn
• Ausfall von Schnittstellen
• Datenschutzvorfälle
• Ansprüche Dritter

Pauschale Haftungsausschlüsse sollten deshalb nicht ungeprüft verwendet werden.

Unterauftragnehmer einsetzen

Softwareprojekte werden teilweise mit Freelancern oder spezialisierten Drittunternehmen umgesetzt.

Der Vertrag kann regeln:

• ob Unterauftragnehmer zulässig sind,
• ob eine Zustimmung erforderlich ist,
• welche Geheimhaltungsregeln gelten und
• wie Nutzungsrechte sichergestellt werden.

Rechtekette sicherstellen

Wenn mehrere Entwickler an der Software arbeiten, sollte der Auftragnehmer sicherstellen können, dass er die vertraglich zugesagten Nutzungsrechte tatsächlich einräumen darf.

Dies ist insbesondere relevant bei:

• freien Entwicklern
• Designern
• Agenturen
• Subunternehmern
• extern erstellten Komponenten

Arbeitsergebnisse Dritter nicht übersehen

Auch Designs, Icons, Bilder, Texte und andere Bestandteile können eigene Rechte besitzen.

Ein Softwarevertrag sollte deshalb nicht nur den reinen Programmcode betrachten.

Projektabbruch vor Fertigstellung

Nicht jedes Softwareprojekt wird vollständig abgeschlossen.

Der Vertrag sollte deshalb festlegen, was bei einem vorzeitigen Ende mit bereits erstellten Arbeitsergebnissen geschieht.

Zu klären sind beispielsweise:

• Vergütung bereits erbrachter Leistungen
• Übergabe des vorhandenen Quellcodes
• Dokumentation
• Zugangsdaten
• Zwischenstände
• Nutzungsrechte
• Rückgabe vertraulicher Daten

Projektübergabe bei Entwicklerwechsel

Muss ein anderer Entwickler das Projekt übernehmen, sind vollständige technische Unterlagen besonders wertvoll.

Dazu können gehören:

• Quellcode
• Repository
• Datenbankschema
• Deployment-Dokumentation
• API-Schlüssel
• Serverzugänge
• Liste eingesetzter Komponenten

Keine geschäftskritischen Zugänge vergessen

Am Projektende sollte geprüft werden, ob der Auftraggeber alle erforderlichen Zugänge besitzt.

Abnahme und Zahlung miteinander abstimmen

Ist die Schlusszahlung an die Abnahme gekoppelt, sollte eindeutig sein, wann sie fällig wird.

Unklare Formulierungen wie „Restbetrag nach Projektabschluss“ können zu unterschiedlichen Vorstellungen führen.

Referenznennung durch Entwickler

Agenturen oder Entwickler möchten fertige Projekte teilweise als Referenz zeigen.

Der Vertrag kann festlegen, ob beispielsweise:

• Name des Auftraggebers,
• Logo,
• Screenshots oder
• Projektbeschreibung

für Referenzzwecke verwendet werden dürfen.

Quellcode und Geschäftsgeheimnisse

Der Quellcode selbst kann sowohl für Auftraggeber als auch Auftragnehmer sensible Bestandteile enthalten.

Wer Zugriff erhält und in welchem Umfang Quellcode weitergegeben werden darf, sollte deshalb mit der vereinbarten Rechteübertragung abgestimmt werden.

Software-Erstellungsvertrag oder IT-Dienstleistung?

Der Unterschied liegt häufig im Schwerpunkt.

Bei einem Software-Erstellungsvertrag steht typischerweise ein konkret beschriebenes Entwicklungsergebnis im Mittelpunkt.

Bei einer laufenden IT-Dienstleistung kann dagegen die kontinuierliche Tätigkeit im Vordergrund stehen.

Unsere allgemeine Dienstleistungsvertrag Vorlage eignet sich eher für laufende Dienstleistungen ohne ein so detailliert definiertes Software-Werk.

Softwareprojekt mit Beratung kombinieren

Manche Projekte beginnen mit einer ausführlichen Analyse oder strategischen Beratung.

Sollen Beratung und eigentliche Softwareentwicklung getrennt beauftragt werden, kann für die vorgelagerte Beratungsleistung unsere Beratungsvertrag Vorlage sinnvoll sein.

Typische Fehler bei Software-Erstellungsverträgen

• Projekt nur in einem Satz beschreiben: Der geschuldete Funktionsumfang bleibt unklar.
• keine Leistungsabgrenzung: Zusätzliche Wünsche werden später als inklusive angesehen.
• keine Change-Request-Regelung: Mehrkosten und Terminverschiebungen sind nicht geklärt.
• keine Mitwirkungspflichten: Verzögerungen durch fehlende Informationen lassen sich schlecht zuordnen.
• Abnahme nicht definieren: Es bleibt unklar, wann das Projekt als fertig gilt.
• Quellcode nicht erwähnen: Auftraggeber und Entwickler haben unterschiedliche Erwartungen.
• Nutzungsrechte zu pauschal: Umfang der erlaubten Nutzung bleibt offen.
• Open Source ignorieren: Rechte Dritter werden übersehen.
• Pflege automatisch voraussetzen: Laufender Support ist nicht eindeutig vereinbart.
• Konten beim Entwickler belassen: Geschäftskritische Zugänge fehlen nach Projektende.

Word oder PDF – welches Format ist besser?

Beide Downloads enthalten dieselbe Grundstruktur.

• Word: besonders geeignet, um Leistungsumfang, Meilensteine, Vergütung und Nutzungsrechte individuell auf ein Softwareprojekt anzupassen.
• PDF: praktisch zum Ausdrucken, Prüfen und gemeinsamen Durchgehen der Vertragsregelungen.

Software-Erstellungsvertrag individuell anpassen

Softwareprojekte unterscheiden sich erheblich hinsichtlich Technik, Umfang, Vergütung und wirtschaftlicher Bedeutung.

Die Vorlage ist deshalb ein allgemeines Muster und ersetzt keine individuelle rechtliche Beratung.

Bei größeren Entwicklungsbudgets, geschäftskritischer Software, umfangreicher Datenverarbeitung, komplexen Lizenzmodellen oder internationalen Projektpartnern kann eine individuelle Prüfung besonders sinnvoll sein.