Sieben Klauseln, die in jeden Softwarevertrag gehören

Die meisten Streitigkeiten bei Softwareentwicklung gehen auf etwas zurück, das nie schriftlich festgehalten wurde, nicht auf etwas, das verletzt wurde. Der Vertrag sagte nicht, wem der Code nach einer Trennung mitten im Projekt gehört, also liegt formal niemand falsch - und alle stecken fest.

Hier sind die sieben Klauseln, die das verhindern.

Die kurze Antwort

Sieben Klauseln, und der genaue Wortlaut in jeder einzelnen zählt mehr als das bloße Vorhandensein einer Klausel mit diesem Titel.

IP- und Codeeigentum mit Auslöserdatum

Die wichtigste Klausel und diejenige, die am häufigsten vage formuliert wird - absichtlich oder aus Versehen.

„Der Kunde besitzt sämtliche Arbeitsergebnisse" klingt schützend. Ohne Auslöser ist es das nicht: besitzt sie ab wann? Manche Verträge übertragen Eigentum erst „nach Abschluss der Zusammenarbeit" - was zum echten Problem wird, wenn die Beziehung in Monat zwei eines viermonatigen Projekts endet, denn formal ist nichts abgeschlossen.

Worauf Sie stattdessen achten sollten: Eigentum geht mit jeder Meilensteinzahlung über oder unmittelbar bei Erstellung, mit einer Rücklizenz an den Entwickler für Portfoliozwecke. Beides funktioniert. Vage Zeitpunkte nicht.

Ausdrückliche Umfangsausschlüsse

Wir haben bereits darüber geschrieben, warum ein Scope-Dokument einen Ausschlussabschnitt braucht, und der Vertrag muss dieselbe Genauigkeit tragen, nicht nur locker darauf verweisen.

„Entwicklung des MVP gemäß beiliegendem Scope" ist schwächer, als es aussieht, wenn der beiliegende Scope selbst nicht auflistet, was ausgeschlossen ist - Kosten für Drittanbieter-APIs, Content, Datenmigration, Support über ein genanntes Fenster hinaus. Ohne diese Liste greift jede Seite auf ihre eigenen Annahmen zurück, und die decken sich selten.

Meilensteinbasierte Zahlung, nicht kalenderbasiert

Ein an Daten gebundener Zahlungsplan - 30 Tage netto, dann 30 Tage später, dann noch einmal 30 Tage später - zahlt unabhängig davon, ob etwas geliefert wurde. Das nimmt Ihnen den einzigen echten Hebel, wenn das Projekt zurückfällt.

Ein an Meilensteine gebundener Zahlungsplan - funktionierender Login-Flow, Kerntransaktion von Anfang bis Ende, funktionierendes Adminpanel - gibt Zahlungen nur gegen etwas frei, das Sie tatsächlich überprüfen können. Diese eine Änderung schützt einen Kunden mehr als fast jede andere Klausel im Vertrag.

Ein definierter Änderungsanfrage-Prozess

Der Umfang wird sich ändern. Ein Vertrag, der nicht sagt wie, sagt implizit „wir klären das, wenn es passiert" - und das begünstigt, wer in dem Moment mehr Hebel hat, meist nicht Sie, mitten im Projekt, wenn ein Partnerwechsel teuer ist.

Die Klausel sollte klar festhalten: Eine Änderungsanfrage außerhalb des definierten Umfangs wird gesondert geschätzt und schriftlich angeboten, bevor daran gearbeitet wird. Das schützt beide Seiten - der Entwickler absorbiert kein kostenloses Scope-Wachstum, und Sie entdecken keine Überraschungsrechnung für etwas, das Sie für enthalten hielten.

Ein definiertes, ausdrücklich begrenztes Supportfenster

„Support nach dem Launch inklusive" ist keine Klausel, sondern eine Floskel. Begrenzt wie - für wie viele Tage, welche Art von Problemen abdeckend, mit welcher Reaktionszeit?

Dreißig Tage Fehlerbehebung an bestehender Funktionalität sind eine vernünftige, übliche Basis. Alles darüber hinaus - neue Funktionen, laufende Wartung, priorisierte Reaktionszeiten - sollte ein separater, bepreister Retainer sein, festgehalten im Vertrag oder einer verknüpften Vereinbarung, keine Annahme, die jede Seite stillschweigend trifft.

Kündigungs- und Ausstiegsbedingungen

Jeder Vertrag sollte schriftlich beantworten, bevor es nötig wird: Was passiert, wenn eine Seite vor Projektende aussteigen will?

Mindestens: Kündigungsfrist, was für die bis dahin geleistete Arbeit geschuldet ist, und die Bestätigung, dass die Eigentumsbedingungen (siehe Klausel eins) auch bei vorzeitiger Beendigung sauber gelten - nicht nur bei erfolgreichem Abschluss. Ein Vertrag, der nur den sauberen Abschluss beschreibt, hat das Szenario nicht geplant, das am wahrscheinlichsten zum Streit führt.

Vertraulichkeit und Wiederverwendungsverbot

Standard in den meisten professionellen Verträgen, aber es lohnt sich, auf das eine zu achten, das Gründer für abgedeckt halten und das es oft nicht ist: eine Klausel, die dem Entwickler untersagt, Ihre spezifische Geschäftslogik, Ihre Daten oder Ihren proprietären Ansatz in einem anderen Kundenprojekt wiederzuverwenden - nicht bloß allgemeine Vertraulichkeit darüber, nicht öffentlich über Ihr Geschäft zu sprechen.

Übliche NDAs decken Geheimhaltung ab. Diese Klausel deckt Wiederverwendung ab, und das ist die Version, auf die es ankommt, wenn der Wert Ihres Produkts darin liegt, wie etwas funktioniert, nicht nur dass es existiert.

Was tun, wenn diese Klauseln fehlen

Die meisten davon sind Ergänzungen, keine Neufassungen. Ein Partner, der sich stark dagegen sperrt, klare Eigentumsdaten, Meilensteinzahlungen oder eine Ausschlussliste aufzunehmen, gibt Ihnen Informationen, die Sie vor der Unterschrift haben sollten, nicht danach - die Fragen, die es vor der Unterschrift zu stellen lohnt behandeln die gesprächsweise Version derselben Prüfung.

Keine dieser sieben Klauseln ist ungewöhnlich oder aggressiv zu verlangen. Sie sind der Unterschied zwischen einem Vertrag, der eine Beziehung beschreibt, und einem, der Sie tatsächlich schützt, wenn die Beziehung aus dem Ruder läuft.

Prüfen Sie einen Vertrag für ein MVP und wollen eine zweite Meinung zu den Bedingungen? Schicken Sie uns die Details - wir sagen Ihnen, was fehlt. Unsere eigene Vertragsstruktur, einschließlich IP-Bedingungen und Zahlungsmeilensteinen, ist in unseren Preisen erläutert.