Softwareentwicklung-Angebot richtig lesen: 10 entscheidende Klauseln

Auf Ihrem Tisch liegen drei Angebote für dieselbe Software, zwei davon unterscheiden sich im Preis um vielleicht zehn Prozent. Die naheliegende Schlussfolgerung lautet: Dann nehmen wir das günstigere. In der Praxis ist der Preis aber der am leichtesten vergleichbare und zugleich am wenigsten aussagekräftige Teil eines Softwareangebots.

Zwei Angebote mit fast identischem Preis können völlig unterschiedliche Risiken tragen. Beim einen gehören Ihnen am Ende Quellcode und Repository, beim anderen bekommen Sie ein Nutzungsrecht, das bei Vertragsende endet. Beim einen ist beschrieben, wann eine Funktion als fertig gilt, beim anderen entscheidet das der Dienstleister. Beim einen kostet eine Änderung einen vorher vereinbarten Stundensatz, beim anderen wird sie neu verhandelt, wenn Sie längst abhängig sind.

Dieser Leitfaden geht zehn Punkte durch, die Sie in jedem Angebot für Individualsoftware prüfen sollten. Jeder Punkt ist als Frage formuliert, die Sie dem Anbieter stellen können. Juristische Vorbildung brauchen Sie dafür nicht.

1. Steht im Angebot, was genau geliefert wird, und worauf bezieht es sich?

Die Leistungsbeschreibung ist der Kern des Vertrags. Alles, was später strittig wird, wird an ihr gemessen. Ein belastbares Angebot listet nicht nur Schlagworte, sondern verweist auf ein konkretes Dokument mit Datum und Version, meist auf Ihr Lastenheft oder auf ein daraus abgeleitetes Pflichtenheft.

Gut ist eine Formulierung, die auf nummerierte Anforderungen verweist und ausdrücklich benennt, was nicht enthalten ist. Diese Abgrenzung ist wichtiger als die Aufzählung selbst: Streit entsteht fast immer an Punkten, die eine Seite für selbstverständlich hielt.

Ein rotes Tuch sind Angebote, die den Leistungsumfang in drei Zeilen zusammenfassen: „Entwicklung einer Webanwendung zur Auftragsverwaltung inklusive Datenbank und Benutzeroberfläche." Das lässt sich weder abnehmen noch vergleichen.

„Gegenstand des Auftrags ist die Umsetzung der Anforderungen A-01 bis A-38 gemäß Lastenheft vom 12.03. in der Fassung 1.2, die diesem Angebot als Anlage 1 beiliegt. Nicht enthalten sind die als Kann gekennzeichneten Anforderungen A-39 bis A-46, die Migration von Altdaten aus dem Vorsystem sowie Schulungen über den in Ziffer 4 genannten Umfang hinaus."

2. Wie und woran wird abgenommen?

Die Abnahme ist der Moment, in dem die Leistung als erbracht gilt. Von ihr hängen Zahlung, Beginn der Gewährleistung und Ihre Möglichkeit ab, Mängel geltend zu machen. Trotzdem fehlt sie in vielen KMU-Angeboten komplett oder erschöpft sich in einem Satz.

Ein gutes Angebot beschreibt drei Dinge: woran gemessen wird (Testfälle, Anforderungsliste), in welcher Umgebung geprüft wird und in welcher Frist Sie prüfen. Sinnvoll ist außerdem die Unterscheidung zwischen wesentlichen Mängeln, die die Abnahme verhindern, und unwesentlichen, die nachgearbeitet werden.

Vorsicht bei der stillschweigenden Abnahme nach sehr kurzen Fristen. „Die Leistung gilt als abgenommen, wenn der Auftraggeber nicht innerhalb von fünf Tagen widerspricht" ist in einem Betrieb mit Urlaubszeiten und Tagesgeschäft eine Abnahme ohne Prüfung.

„Der Auftragnehmer stellt die Lieferung auf einem Testsystem bereit und meldet die Abnahmebereitschaft schriftlich. Der Auftraggeber prüft innerhalb von 15 Werktagen anhand der in Anlage 2 vereinbarten Testfälle. Wesentliche Mängel berechtigen zur Verweigerung der Abnahme; unwesentliche Mängel werden protokolliert und innerhalb von 15 Werktagen behoben, ohne die Abnahme aufzuschieben."

3. Was passiert, wenn sich Anforderungen ändern?

Anforderungen ändern sich in praktisch jedem Projekt. Das ist normal und kein Zeichen schlechter Vorbereitung. Entscheidend ist, ob das Angebot einen geordneten Weg dafür vorsieht oder ob jede Änderung zur Einzelverhandlung wird.

Ein sauberer Change-Request-Prozess besteht aus vier Schritten: schriftlicher Antrag, Aufwandsschätzung durch den Dienstleister innerhalb einer Frist, Freigabe durch Sie, erst dann Umsetzung. Wichtig ist, dass der Stundensatz für Änderungen bereits im Angebot steht. Ebenfalls hilfreich: eine Bagatellgrenze, damit nicht jede Feldumbenennung Papier produziert.

Warnsignale sind fehlende Preise für Änderungen, Formulierungen wie „Zusatzaufwände werden nach Aufwand berechnet" ohne Satz und ohne Freigabepflicht, sowie ein Prozess ohne garantierte Schätzung vor der Umsetzung. Wie sich das Thema je nach Vertragsmodell unterscheidet, erläutern wir im Beitrag Festpreis oder Time and Material.

„Änderungswünsche werden schriftlich als Change Request erfasst. Der Auftragnehmer legt innerhalb von fünf Werktagen eine Schätzung des Mehraufwands in Stunden sowie die Auswirkung auf den Terminplan vor. Die Umsetzung beginnt erst nach schriftlicher Freigabe, abgerechnet wird zum vereinbarten Stundensatz von X Euro netto. Änderungen unter zwei Stunden werden ohne gesondertes Verfahren erledigt und im Statusbericht ausgewiesen."

4. Wem gehört der Quellcode nach Projektende?

Das ist die Klausel mit der größten wirtschaftlichen Wirkung und die am häufigsten überlesene. Sie bezahlen die Entwicklung, aber daraus folgt nicht automatisch, dass Sie mit dem Ergebnis machen dürfen, was Sie wollen. Das Urheberrecht am Code bleibt beim Entwickler; Sie erhalten ein Nutzungsrecht in dem Umfang, den der Vertrag beschreibt.

Eine gute Klausel räumt Ihnen ein ausschließliches, zeitlich, räumlich und inhaltlich unbeschränktes, übertragbares Nutzungsrecht ein, einschließlich des Rechts zur Bearbeitung und Weiterentwicklung durch Dritte. Genauso wichtig wie das Recht ist die praktische Verfügbarkeit: Der Quellcode muss ausgehändigt werden, samt Repository mit Historie, Build-Anleitung und Konfiguration. Ein Nutzungsrecht ohne Code ist wenig wert.

Rote Flaggen gibt es hier mehrere: ein einfaches statt ausschließliches Nutzungsrecht, eine Bindung des Nutzungsrechts an einen laufenden Wartungsvertrag, ein Verbot der Bearbeitung durch Dritte oder schlicht das Fehlen jeder Aussage zum Code. Was passiert, wenn diese Punkte ungeklärt bleiben, beschreiben wir am Beispiel Software übernehmen, wenn der Entwickler nicht mehr erreichbar ist.

„Der Auftragnehmer überträgt dem Auftraggeber mit vollständiger Bezahlung das ausschließliche, zeitlich, räumlich und inhaltlich unbeschränkte sowie übertragbare Recht zur Nutzung, Bearbeitung und Weiterentwicklung der im Auftrag erstellten Software. Der Quellcode wird laufend im Repository des Auftraggebers geführt; spätestens mit der Abnahme werden Repository-Historie, Build- und Deployment-Anleitung sowie die Konfigurationsbeschreibung übergeben."

5. Welche Open-Source-Komponenten kommen zum Einsatz?

Jede moderne Anwendung besteht zu einem erheblichen Teil aus fremden Bibliotheken. Das ist gut, weil es Zeit und Geld spart. Es bedeutet aber, dass die Lizenzen dieser Komponenten mitgeliefert werden und Bedingungen an Ihre Nutzung knüpfen können.

Ein transparentes Angebot benennt die eingesetzten Fremdkomponenten oder sagt zumindest zu, eine Liste mit Namen, Version und Lizenz zur Abnahme zu liefern. Zusätzlich sollte der Anbieter zusichern, nur Lizenzen zu verwenden, die mit Ihrer geplanten Nutzung vereinbar sind. Bei rein interner Nutzung ist der Spielraum groß; wenn Sie die Software später vertreiben oder als Software as a Service anbieten wollen, sollten Sie das vorher sagen.

Bedenklich ist, wenn der Anbieter keine Auskunft über verwendete Bibliotheken geben kann. Ebenso, wenn kommerzielle Drittlizenzen im Angebot fehlen, deren Kosten Sie nach dem Go-live jährlich tragen müssen.

„Der Auftragnehmer übergibt spätestens zur Abnahme eine Liste aller eingesetzten Fremdkomponenten mit Bezeichnung, Version und Lizenz. Er sichert zu, ausschließlich Komponenten zu verwenden, deren Lizenzbedingungen die vereinbarte Nutzung durch den Auftraggeber erlauben. Kostenpflichtige Drittlizenzen sind in Anlage 3 mit jährlicher Gebühr ausgewiesen."

6. Wie lange wird nachgebessert, und ab wann kostet es?

Gewährleistung und Wartung werden im Alltag gern verwechselt. Gewährleistung heißt: Was vertraglich geschuldet war und nicht funktioniert, wird kostenlos nachgebessert. Wartung heißt: laufende Pflege, Updates und Weiterentwicklung, gegen Bezahlung.

Ein gutes Angebot trennt beides, nennt die Dauer der Gewährleistung ab Abnahme und definiert, was als Mangel gilt: eine Abweichung von der vereinbarten Leistungsbeschreibung. Dazu gehören nach Schweregrad gestaffelte Reaktionszeiten. Die Details haben wir in Gewährleistung und Wartung im Vergleich sowie in den Musterklauseln für Softwarewartungsverträge aufbereitet.

Kritisch wird es, wenn die Gewährleistung auf wenige Wochen verkürzt wird, wenn jeder Fehler zuerst als „Änderungswunsch" eingestuft wird oder wenn Nachbesserung nur bei bestehendem Wartungsvertrag zugesagt ist.

„Die Gewährleistungsfrist beträgt 12 Monate ab Abnahme. Als Mangel gilt jede Abweichung der Software von der vereinbarten Leistungsbeschreibung. Mängel, die den Betrieb verhindern, werden innerhalb von vier Stunden ab Meldung an Werktagen bearbeitet, übrige Mängel innerhalb von zwei Werktagen. Die Beseitigung erfolgt kostenfrei und unabhängig davon, ob ein Wartungsvertrag besteht."

7. Wann wird welcher Betrag fällig?

Der Zahlungsplan verteilt das Risiko zwischen beiden Seiten. Beide Extreme sind ungesund: Vollständige Vorkasse bedeutet, dass Sie kein Druckmittel mehr haben; eine Zahlung erst nach vollständiger Fertigstellung überfordert kleinere Dienstleister.

Bewährt hat sich eine Kopplung an Meilensteine mit prüfbarem Ergebnis, nicht an Kalenderdaten. Ein Meilenstein ist erreicht, wenn etwas Vorzeigbares existiert: eine lauffähige Vorabversion, ein abgeschlossenes Modul, die erfolgreiche Schnittstellenanbindung. Eine Schlussrate von 10 bis 20 Prozent nach Abnahme ist üblich und sinnvoll.

Achten Sie auf Zahlungspläne, die an Termine statt an Fortschritt gebunden sind („30 Prozent zum 1. Juli"), und auf Meilensteine, die inhaltlich nicht überprüfbar sind, etwa „Abschluss Konzeptionsphase" ohne Angabe, welches Dokument dabei entsteht.

„Die Vergütung wird wie folgt fällig: 20 Prozent bei Auftragserteilung, 30 Prozent nach Freigabe des Pflichtenhefts, 30 Prozent nach Bereitstellung der Version 1.0 auf dem Testsystem, 20 Prozent nach Abnahme. Ein Meilenstein gilt als erreicht, wenn das jeweils benannte Ergebnis vorliegt."

8. Was müssen Sie selbst beisteuern?

Mitwirkungspflichten klingen nach einer Klausel zugunsten des Dienstleisters, und das sind sie zum Teil auch. Für Sie sind sie trotzdem wichtig, weil sie den internen Aufwand sichtbar machen, der in keinem Preis steht. Ein Projekt scheitert selten am Code, häufig aber daran, dass niemand im Betrieb Zeit für Rückfragen, Tests und Entscheidungen hat.

Eine faire Klausel benennt konkret, was Sie liefern: einen Ansprechpartner mit Entscheidungsbefugnis und Vertretung, Zugänge zu Systemen, Testdaten, Fachwissen zu Prozessen sowie Personen für die Abnahmetests. Sinnvoll ist auch eine Größenordnung in Stunden pro Woche, damit Sie intern planen können.

Kritisch sind Formulierungen, die Ihnen unbegrenzte Mitwirkung abverlangen und daraus automatisch Terminverschiebungen und Mehrkosten ableiten. Ein seriöses Angebot verlangt Mitwirkung, meldet aber auch, wenn sie ausbleibt.

„Der Auftraggeber benennt einen Ansprechpartner mit Entscheidungsbefugnis sowie eine Vertretung und stellt für Abstimmungen, Rückfragen und Tests durchschnittlich vier Stunden pro Woche zur Verfügung, dazu Zugänge zu den betroffenen Systemen und anonymisierte Testdaten. Bleibt eine Mitwirkung aus, weist der Auftragnehmer schriftlich darauf hin und benennt die Folgen für Termin und Aufwand, bevor Mehrkosten entstehen."

9. Wer verantwortet Datenschutz und Hosting?

Sobald der Dienstleister mit personenbezogenen Daten in Berührung kommt, sei es beim Test mit echten Daten oder im Betrieb, brauchen Sie eine Vereinbarung zur Auftragsverarbeitung. Das ist kein Formalismus, sondern Ihre Pflicht als Verantwortlicher.

Ein gutes Angebot regelt drei Fragen: Wird ein Auftragsverarbeitungsvertrag geschlossen und liegt er als Anlage bei? Wo läuft das System, in welchem Rechenzentrum, in welchem Land? Und wer ist für Backups, Verschlüsselung und Zugriffsrechte zuständig? Eine Übersicht der Punkte, die dabei zu klären sind, finden Sie in unserer Checkliste für DSGVO-konforme Softwareentwicklung.

Warnzeichen sind pauschale Aussagen wie „DSGVO-konform" ohne Konkretisierung, Entwicklung mit Produktivdaten ohne Anonymisierung sowie Hosting-Angaben ohne Nennung der Unterauftragnehmer.

„Die Parteien schließen vor Beginn der Arbeiten einen Vertrag zur Auftragsverarbeitung gemäß Art. 28 DSGVO (Anlage 4). Entwicklung und Test erfolgen ausschließlich mit anonymisierten Daten. Der Betrieb erfolgt in einem Rechenzentrum in Deutschland; eingesetzte Unterauftragnehmer sind in der Anlage benannt. Backups werden täglich erstellt, verschlüsselt gespeichert und quartalsweise auf Wiederherstellbarkeit geprüft."

10. Wie kommen Sie wieder aus dem Vertrag heraus?

Die Exit-Klausel prüft niemand gern, weil sie den unangenehmen Fall beschreibt. Genau deshalb ist sie so aussagekräftig. Sie brauchen sie nicht nur bei Streit, sondern auch bei Wachstum, Verkauf des Unternehmens oder einem Wechsel der IT-Strategie.

Gut ist eine Regelung, die Laufzeit und Kündigungsfrist nennt, und vor allem beschreibt, was bei Vertragsende übergeben wird: Quellcode und Repository, technische Dokumentation, Betriebs- und Deployment-Anleitung, Zugangsdaten, Datenexport in einem gängigen Format. Sinnvoll ist zusätzlich eine Übergangsunterstützung zu einem festen Stundensatz, damit ein Nachfolger eingearbeitet werden kann.

Kritisch sind lange Mindestlaufzeiten mit automatischer Verlängerung, fehlende Aussagen zur Herausgabe von Dokumentation und Zugangsdaten sowie eine Datenherausgabe „auf Anfrage und gegen Aufwand" ohne Format und Frist. Genau hier entsteht die Abhängigkeit, die viele Unternehmen erst bemerken, wenn sie wechseln wollen. Worauf Sie bei der Auswahl grundsätzlich achten sollten, haben wir im Beitrag zur Auswahl des passenden Dienstleisters zusammengefasst.

„Der Wartungsvertrag läuft zwölf Monate und verlängert sich jeweils um zwölf Monate, wenn er nicht mit einer Frist von drei Monaten zum Laufzeitende gekündigt wird. Bei Vertragsende übergibt der Auftragnehmer innerhalb von 15 Werktagen Quellcode samt Repository-Historie, technische Dokumentation, Betriebsanleitung, alle Zugangsdaten sowie einen Datenexport im CSV- oder SQL-Format. Die Einarbeitung eines Nachfolgers erfolgt zum vereinbarten Stundensatz."

Prüf-Checkliste für Ihr Angebot

Nehmen Sie die Angebote nebeneinander und haken Sie ab. Fehlt ein Punkt, ist das kein Ausschlusskriterium, aber eine Frage, die Sie vor der Unterschrift stellen sollten.

Was Ucar Solutions standardmäßig in Angebote schreibt

Damit Sie eine Vergleichsgröße haben, hier unsere eigene Praxis. Diese Punkte stehen bei uns nicht auf Nachfrage im Vertrag, sondern grundsätzlich.

• Volle Nutzungsrechte: Mit vollständiger Bezahlung erhalten Sie das ausschließliche, unbeschränkte und übertragbare Nutzungs- und Bearbeitungsrecht an der für Sie entwickelten Software. Sie dürfen sie durch jeden anderen Dienstleister weiterentwickeln lassen.
• Code im Repository des Kunden: Wir entwickeln von Beginn an in einem Repository, auf das Sie Zugriff haben. Sie warten nicht auf eine Übergabe am Projektende, sondern sehen jederzeit den aktuellen Stand. Wenn Sie noch kein Repository betreiben, richten wir es auf Ihren Namen ein.
• Schriftliche Abnahmekriterien: Jedes Angebot enthält eine Liste nummerierter Anforderungen und die Bedingungen, unter denen sie als erfüllt gelten. Damit ist die Abnahme eine Prüfung und keine Verhandlung.
• Transparente Stundensätze: Unsere Konditionen stehen öffentlich auf der Seite Preise. Der Satz für Änderungen und Wartung ist derselbe, der im Projekt gilt, und er steht vor Vertragsschluss fest.
• Dokumentation als Teil der Lieferung: Betriebs- und Deployment-Anleitung gehören zum Lieferumfang, nicht zu den Zusatzleistungen.

Häufige Fragen

Muss ich für die Prüfung eines Softwareangebots einen Anwalt einschalten?
Für ein typisches KMU-Projekt kommen Sie mit den zehn Fragen aus diesem Beitrag weit, weil die häufigsten Probleme aus fehlender Konkretheit entstehen, nicht aus juristischen Feinheiten. Bei größeren Vorhaben, langen Laufzeiten oder wenn die Software zentral für Ihr Geschäftsmodell ist, sollten Sie den Entwurf zusätzlich von einem auf IT-Recht spezialisierten Anwalt prüfen lassen.

Ist ein Angebot ohne Übertragung der Nutzungsrechte automatisch unseriös?
Nein. Es gibt Modelle, bei denen der Anbieter eine eigene Plattform betreibt und Ihnen daran eine Nutzung einräumt. Das kann günstiger sein. Sie müssen nur wissen, dass Sie dann kein Produkt kaufen, sondern eine Nutzung mieten, und das im Preisvergleich berücksichtigen. Unseriös wird es erst, wenn ein Angebot wie Individualentwicklung aussieht, die Rechtefrage aber offenlässt.

Wie viele Angebote sollte ich einholen?
Drei bis vier sind ein guter Wert. Wichtiger als die Anzahl ist, dass alle Anbieter dieselbe Anforderungsbeschreibung erhalten. Achten Sie auf die Rückfragen: Wer präzise nachfragt, wird auch im Projekt nachfragen, statt Annahmen zu treffen.

Was mache ich, wenn ein Anbieter meine Änderungswünsche am Vertrag ablehnt?
Fragen Sie nach der Begründung. Manchmal gibt es sachliche Gründe, etwa wenn ein Anbieter eigene Bibliotheken einsetzt, die er nicht exklusiv übertragen kann. Dafür lassen sich Zwischenlösungen finden, zum Beispiel ein unbefristetes Nutzungsrecht an diesen Teilen. Wer aber die Herausgabe des Codes oder schriftliche Abnahmekriterien grundsätzlich verweigert, sagt Ihnen etwas über die künftige Zusammenarbeit.

Gelten diese Punkte auch bei Abrechnung nach Aufwand?
Ja, mit Verschiebungen. Bei Time and Material tritt die exakte Leistungsbeschreibung zurück, dafür werden Transparenz über geleistete Stunden, ein Budgetdeckel und die Kündigungsregelung wichtiger. Nutzungsrechte, Datenschutz und Exit gelten unverändert.

Fazit

Der Preis eines Softwareangebots ist eine Zahl, das Risiko steht in den Klauseln. Wer die zehn Fragen aus diesem Beitrag stellt, erkennt innerhalb einer Stunde, welches Angebot durchdacht ist. Am wichtigsten sind erfahrungsgemäß drei Punkte: eine Leistungsbeschreibung mit Bezug auf ein konkretes Dokument, schriftliche Abnahmekriterien und die eindeutige Regelung, dass Ihnen Quellcode und Nutzungsrechte gehören.

Dieser Beitrag gibt Erfahrungen aus Projekten mit KMU wieder und ist keine Rechtsberatung. Bei Verträgen mit größerem Volumen oder besonderer Bedeutung für Ihr Geschäft empfehlen wir, zusätzlich einen auf IT-Recht spezialisierten Anwalt hinzuzuziehen.

Wenn Sie gerade Angebote vergleichen: Schicken Sie uns Ihre Anforderungen, und Sie erhalten ein Angebot mit genau dieser Struktur, inklusive Nutzungsrechten, Abnahmekriterien und Stundensätzen im Klartext. Unsere Konditionen stehen auf der Seite Preise, für alles Weitere erreichen Sie uns über das Kontaktformular.