Caira kann Ihren Vertrag in 3 Klicks prüfen:
Erhalten Sie vorgeschlagene Änderungen und Kommentare direkt in Ihrer Datei
Erstellen Sie eine E-Mail-Zusammenfassung zum Senden an die andere Partei
Die Anmeldung für eine kostenlose Testphase dauert weniger als 30 Sekunden. Keine Kreditkarte erforderlich: Starten Sie Ihre kostenlose Testphase
„Es läuft auf meinem Rechner“: Warum Webentwickler bessere Verträge brauchen
Die Welt der Webentwicklung leidet unter der „Erwartungslücke“.
Sie liefern Code, der der Spezifikation entspricht. Der Kunde öffnet ihn auf einem iPhone 6 aus dem Jahr 2014 und schreit „Es ist kaputt!“
Sie bauen das CMS, nach dem sie gefragt haben. Sechs Monate später rufen sie an und verlangen, dass Sie einen Fehler beheben, der durch ein von ihnen installiertes Plugin verursacht wurde.
Entwicklung ist logisch. Kunden sind emotional. Ihr Vertrag ist die einzige Brücke zwischen beiden. Ohne ihn melden Sie sich für lebenslangen unbezahlten technischen Support an.
Hier sind die rechtlichen Fehler, die Sie in Ihren Geschäftsbedingungen beheben müssen.
1. Das schwarze Loch der „Browser-Kompatibilität“
Die Situation: Sie erstellen eine elegante React-Website. Sie läuft auf Chrome und Safari problemlos. Der CEO des Kunden öffnet sie im Büro in Internet Explorer 11. Das Grid-Layout bricht auseinander. Sie behalten die Zahlung ein, bis „es auf allem funktioniert“.
Die rechtliche Realität:
„Auf allem funktionieren“ ist technisch unmöglich. Ohne eine konkrete Liste könnte ein Gericht „funktionsfähige Website“ als „funktioniert mit gängigen Geschäftstools“ auslegen, wozu auch ältere Browser gehören könnten.
Die Lösung:
Eine Klausel zu unterstützten Browsern.
Seien Sie konkret. „Die Website ist so konzipiert, dass sie in den letzten zwei Versionen von Chrome, Safari, Firefox und Edge funktioniert. Die Unterstützung älterer Browser (z. B. IE11) ist ausgeschlossen, sofern nicht ausdrücklich in der Spezifikation vereinbart.“
2. Abnahmeprüfung (der „Launch“-Auslöser)
Die Situation: Sie stellen die Website fertig. Sie senden den Link. „Lassen Sie mich wissen, was Sie denken.“
3 Wochen lang Stille.
Dann: „Können wir die Schrift ändern?“
Dann 2 Wochen Stille.
Dann: „Können wir das Logo doch verschieben?“
Sie sind 3 Monate über der Frist und haben die letzten 50 % noch nicht erhalten.
Die rechtliche Realität:
Ohne einen definierten „Abnahmezeitraum“ befindet sich das Projekt im Zombie-Modus. Es ist weder fertig noch unfertig.
Die Lösung:
Eine Klausel zur fiktiven Abnahme.
„Der Kunde hat 7 Tage ab Lieferung, um die Software zu testen. Wenn innerhalb von 7 Tagen kein konkreter 'Fehler' (definiert als Absturz/kritischer Fehler) schriftlich gemeldet wird, gilt die Software als abgenommen und der Restbetrag wird fällig.“
So müssen sie es prüfen oder Sie bezahlen.
3. Scope Creep („Nur eine kleine Änderung“)
Die Situation: Sie kalkulieren für 5 Seiten. Zur Hälfte der Arbeit schickt der Kunde den Text. Es sind 12 Seiten. „Ich habe nur die Über-uns-Seite aufgeteilt, das ist doch keine große Sache, oder?“
Das ist eine große Sache. Es betrifft die Navigationslogik, die Auswirkungen auf das mobile Menü und den Zeitaufwand für die Inhaltspflege.
Die Lösung:
Hören Sie auf, für „eine Website“ zu kalkulieren. Kalkulieren Sie für „einen Leistungsumfang“.
Strikte Liefergegenstände: „5 statische Seiten. 1 Kontaktformular.“
Die Klausel zur Änderung: „Jegliche konkreten Wünsche außerhalb dieses Leistungsumfangs werden zu unserem Standard-Stundensatz von £[X] berechnet. Die Entwicklung pausiert, bis die Änderung genehmigt ist.“*
4. Wer besitzt den Code? (Rechte an geistigem Eigentum)
Die Situation: Sie verwenden Ihr Standard-„Starter-Theme“ oder eine Bibliothek von Hilfsfunktionen, die Sie vor Jahren geschrieben haben. Der Kunde zerstreitet sich mit Ihnen. Er verlangt die „vollständige Abtretung des Urheberrechts“ an sämtlichem Code.
Wenn Sie alles abtreten, dürfen Sie Ihr eigenes Starter-Theme für den nächsten Kunden rechtlich nicht mehr verwenden. Sie haben die „Werkzeuge“ verkauft, nicht nur das „Haus“.
Die Lösung:
Unterscheiden Sie zwischen „maßgeschneidertem Code“ und „Background IP“.
„Der Entwickler überträgt das Urheberrecht an dem maßgeschneiderten Design und dem Textlayout nach vollständiger Zahlung auf den Kunden.“*
„Der Entwickler behält das Eigentum an sämtlicher ‚Background IP‘ (wiederverwendbare Bibliotheken/Frameworks) und räumt dem Kunden eine unbefristete, nicht ausschließliche Lizenz ein, sie für diese Website zu nutzen.“*
5. Fehlerbehebung „auf Lebenszeit“
Die Situation: Die Website geht live. Zwei Jahre später aktualisiert WordPress. Die Seite bricht auseinander. Der Kunde ruft an: „Sie haben sie gebaut, Sie reparieren sie.“
Die Lösung:
Eine Gewährleistungsfrist.
„Wir gewähren eine 30-tägige Gewährleistungsfrist nach dem Launch zur Behebung von Fehlern, die bereits beim Launch vorhanden waren. Alle Probleme, die nach 30 Tagen auftreten oder durch Updates von Drittanbietern (Plugins/Browser-Änderungen) verursacht werden, gelten als kostenpflichtige Wartung.“
Warum die Vertragsprüfung Ihre Dokumentation ist
Sie kommentieren Ihren Code. Sie sollten auch Ihre Geschäftsbeziehung kommentieren.
Die KI-Vertragsprüfung analysiert Ihre Entwicklungsvereinbarung. Sie prüft, ob Sie versehentlich „Eignung für einen bestimmten Zweck“ (eine hohe rechtliche Hürde) statt „angemessene Fachkunde und Sorgfalt“ zugesagt haben. Sie stellt sicher, dass Ihr „Abnahme“-Ablauf wasserdicht ist. Sie hilft Ihnen, das Projekt zu liefern und bezahlt zu werden, ohne technische Altlasten.
Haftungsausschluss: Die Informationen in diesem Artikel dienen nur der allgemeinen Orientierung und sind nicht als professionelle rechtliche, finanzielle, steuerliche oder medizinische Beratung gedacht.
