Rechtssichere Vertragsgestaltung bei Softwareentwicklung auf No-Code-Plattformen

No-Code- und Low-Code-Plattformen ermöglichen es Start-ups und Agenturen, Software und digitale Produkte schnell und ohne tiefgehende Programmierkenntnisse zu entwickeln. Doch gerade wenn Softwareentwicklung über SaaS-Dienste und No-Code-Tools wie Airtable, Webflow, AWS Honeycode oder Azure Logic Apps erfolgt, stellen sich erhebliche juristische Fragen. Ein No-Code-Vertrag muss ebenso sorgfältig gestaltet sein wie ein klassischer Softwarevertrag, damit er rechtssicher ist. Andernfalls drohen Risiken – von unklaren Leistungspflichten über Streit um Quellcode-Herausgabe bis hin zu Lücken bei Nutzungsrechten. Im Folgenden beleuchten wir die wichtigsten Aspekte: Wie sind Wartungsverträge bei No-Code einzuordnen? Wann besteht ein Anspruch auf Quellcode oder funktionale Äquivalente? Wie regelt man Nutzungsrechte an individuell erstellten Komponenten versus Plattform-Bestandteilen? Und welche praktischen Klauseln dürfen in keinem „No-Code SaaS Recht“-Vertrag fehlen? Der Beitrag zeigt fundiert, worauf es ankommt, und unterstreicht, warum rechtssichere Softwareverträge in diesem Bereich nur mit professioneller Beratung gelingen.

1. Wartungsverträge bei No-Code/SaaS: Dienst- oder Werkvertrag?

Ein zentraler Punkt bei der Vertragsgestaltung ist die juristische Einordnung von Wartungs- und Pflegeverträgen für No-Code-Anwendungen. In Deutschland unterscheidet das BGB zwischen Dienstvertrag (§ 611 BGB) und Werkvertrag (§ 631 BGB). Dienstvertrag bedeutet: der Dienstleister schuldet ein Tätigwerden (also Bemühungen), aber keinen bestimmten Erfolg. Werkvertrag bedeutet: es wird ein konkreter Erfolg geschuldet (ein „Werk“), das der Auftraggeber abnehmen kann – zum Beispiel eine fertig programmierte Applikation, die bestimmte Anforderungen erfüllt. Diese Unterscheidung hat erhebliche Folgen: Bei einem Werkvertrag greifen Gewährleistungsrechte und Abnahme, und der Auftraggeber kann unter Umständen nach § 648 BGB (ehemals § 649 BGB) vor Fertigstellung kündigen. Bei einem Dienstvertrag hingegen gilt „pacta sunt servanda“ – der Vertrag läuft grundsätzlich für die vereinbarte Dauer, und es besteht kein Anspruch auf einen bestimmten Erfolg, sondern nur auf sorgfältiges Tätigwerden.

Wartungsverträge im No-Code-Umfeld (z.B. für die laufende Betreuung einer Webflow-Website oder einer Airtable-Datenbank) sind in der Regel als Dauerschuldverhältnis mit fortlaufenden Pflichten gestaltet. Typischerweise zahlt der Auftraggeber eine monatliche Pauschalvergütung, damit der Dienstleister bereitschafts- und überwachungsbezogene Leistungen erbringt – etwa regelmäßiges Monitoring, das Einspielen von Updates, Behebung von Bugs oder einfach die Gewährleistung einer bestimmten Reaktionszeit im Fehlerfall. Hier stellt sich die Frage: Handelt es sich dabei um einen Dienst- oder einen Werkvertrag? Die Rechtsprechung tendiert dazu, solche Flatrate-Vereinbarungen als Dienstvertrag zu qualifizieren. Ein Beispiel: Das Landgericht Köln entschied in einem vielbeachteten Fall (Urteil vom 20.02.2015 – Az. 12 O 186/13, „Internetagentur-Flatrate“), dass ein umfassender Agenturvertrag mit monatlichem Pauschalhonorar als Dienstvertrag anzusehen ist. Obwohl einzelne Elemente (wie die einmalige Erstellung einer Website) Werk-Charakter hatten, überwogen die laufenden Marketing- und SEO-Leistungen, welche ergebnisoffene Tätigkeiten sind. Wesentliche Gründe für die Einordnung als Dienstvertrag waren: Die Vereinbarung war als langfristiges Dauerschuldverhältnis angelegt, die Vergütung war unabhängig von einem einzelnen Erfolg geschuldet, und der Schwerpunkt lag auf der fortlaufenden Verfügbarkeit von Leistungen bei Bedarf, nicht auf der Herstellung eines einmaligen Endprodukts. Genau dieses Bild zeigt sich auch bei Wartungsverträgen für No-Code-Software: Der Auftragnehmer hält sich bereit und erbringt bei Bedarf Leistungen, die nicht immer in einem greifbaren „Werk“ resultieren.

Für die Praxis bedeutet das: Klarheit im Vertragstyp schaffen! Ist die laufende Betreuung einer No-Code-Anwendung vereinbart, sollte ausdrücklich geregelt werden, dass es sich – wenn dem so gewollt ist – um einen Dienstvertrag handelt, der eine kontinuierliche Mitwirkung ohne Erfolgsgarantie beinhaltet. Andernfalls könnte der Auftraggeber versuchen, einzelne Ergebnisse als „Werke“ einzustufen und z.B. Abnahme zu verlangen oder vorzeitig zu kündigen. Umgekehrt: Werden in einem Vertrag sowohl Entwicklungsleistungen (Werk) als auch Wartung (Dienst) kombiniert, besteht ein Mischvertrag. Hier empfiehlt es sich, die Leistungsarten klar getrennt zu regeln (etwa in separaten Vertragsteilen oder sogar getrennten Verträgen, z.B. ein Entwicklungsvertrag und ein anschließender Wartungsvertrag). So vermeidet man Unklarheiten darüber, welche Rechtsregeln im Zweifel gelten.

Pauschalvergütung und Prüfbarkeit der Leistung: Ein besonderes Problem bei Pauschal-Wartungsverträgen ist die Prüfbarkeit der Leistungen. Oft kann der Auftraggeber von außen kaum erkennen, was der Dienstleister im Hintergrund leistet – insbesondere wenn es wenige Störungen gibt (Beispiel: Der Dienstleister erhält monatlich eine Pauschale für „Monitoring“ einer No-Code-App, aber die App läuft stabil, sodass keine Eingriffe nötig sind). Trotzdem ist die Vergütung geschuldet, denn die Leistung besteht hier in der Bereitschaft und Verfügbarkeit des Dienstleisters. Juristisch wird das mit dem Charakter als Dienstvertrag und der Natur der Vereinbarung begründet: Der Auftragnehmer stellt seine Zeit und Expertise fortlaufend zur Verfügung, was bereits die vergütete Leistung darstellt – unabhängig davon, ob ein konkreter Fehler behoben werden musste. Im oben genannten LG Köln-Fall argumentierte das Gericht, dass das monatliche Honorar „unabhängig von den tatsächlich erbrachten Leistungen“ zu zahlen sei und gerade die ständige Einsatzbereitschaft abgegolten werde. Aus Sicht von Treu und Glauben (§ 242 BGB) sollte ein Auftragnehmer dennoch für Transparenz sorgen: Empfehlenswert sind Reporting-Pflichten im Vertrag (z.B. ein monatlicher Bericht über durchgeführte Prüfungen, Updates, Backups etc.). So kann der Auftraggeber nachvollziehen, dass der Dienstleister tätig war, und das Vertrauensverhältnis bleibt intakt. Außerdem lassen sich so spätere Streitigkeiten vermeiden, ob „nichts getan“ wurde – beide Seiten wissen, welche unsichtbaren Aufgaben erbracht wurden.

Zusammengefasst: Bei Wartungsverträgen im No-Code-Bereich spricht vieles für die Einordnung als Dienstvertrag. Vertraglich sollte dies klar festgehalten und der Umfang der geschuldeten Tätigkeiten (Bereitschaft, Monitoring, Fehlerbehebung etc.) genau beschrieben werden. Eine pauschale Vergütung für die Einsatzbereitschaft ist üblich – allerdings sollten Mechanismen vereinbart werden, wie zusätzliche Leistungen gehandhabt werden: Kommt es zu aufwändigen, ursprünglich nicht abgedeckten Tätigkeiten, kann eine Vergütungsanpassung nach Werkvertragsrecht in Betracht kommen. Tatsächlich hat der Bundesgerichtshof (Urteil vom 08.01.2002 – Az. X ZR 6/00) entschieden, dass selbst bei einem Pauschalpreis-Werkvertrag der Unternehmer Mehrvergütung verlangen kann, wenn der Besteller erhebliche, ursprünglich nicht vorgesehene Zusatzleistungen verlangt hat. Übertragen auf Wartungsverträge heißt das: Werden im Rahmen einer Pauschale zusätzliche Entwicklungsaufgaben übernommen, die deutlich über das Monitoring hinausgehen, sollte vertraglich geklärt sein, ob diese separat vergütet werden. Klare Regelungen und eine saubere Trennung von Basis-Pauschale und Zusatzleistungen verhindern, dass sich später jemand auf Überraschungen berufen muss – im Zweifel wird sonst § 242 BGB (Treu und Glauben) als Lückenfüller für eine faire Interessenabwägung herangezogen, was unnötige Rechtsunsicherheit bedeutet.

2. Herausgabe von Quellcode oder funktionalen Äquivalenten bei No-Code-Projekten

Gerade Start-ups und IT-Projektleiter legen Wert darauf, im Ergebnis einer Softwareentwicklung nicht nur ein laufendes Produkt zu haben, sondern auch Zugriff auf den „Bauplan“ – klassisch den Quellcode. Bei No-Code-Plattformen stellt sich dieses Thema jedoch ganz besonders: Oft existiert kein herkömmlicher Quellcode, weil die Anwendung z.B. aus grafisch konfigurierten Workflows, Datenbanken oder proprietären Bausteinen besteht. Was passiert also, wenn der Kunde verlangt: „Gib mir den Quellcode oder etwas Gleichwertiges heraus“?

Zunächst ein Blick auf die gesetzliche Lage und Rechtsprechung bei klassischer Softwareentwicklung: Ob ein Auftraggeber Anspruch auf Herausgabe des Quellcodes hat, richtet sich mangels spezieller Regelung nach der allgemeinen Vertragsauslegung und dem Urheberrecht. Nach §§ 133, 157 BGB ist ein Vertrag so auszulegen, wie Treu und Glauben mit Rücksicht auf die Verkehrssitte es erfordern – kurz: Was haben die Parteien nach objektivem Verständnis vereinbart? Und § 31 Abs. 5 UrhG enthält den Zweckübertragungsgrundsatz: Wurden Nutzungsrechte an einem urheberrechtlich geschützten Werk (z.B. Software) eingeräumt, so erstrecken sie sich im Zweifel nur auf das, was zur Erreichung des Vertragszwecks notwendig ist. Für Software heißt das: Der Auftraggeber erhält grundsätzlich die Rechte, um das Programm wie vereinbart nutzen zu können – aber mehr auch nicht, sofern nicht ausdrücklich anders geregelt.

Der Bundesgerichtshof hat in seiner Rechtsprechung Fallgruppen entwickelt, wann ein Quellcode-Herausgabeanspruch besteht und wann nicht (vgl. BGH, Urteil vom 16.12.2003 – X ZR 129/01 und BGH, Urteil vom 30.01.1986 – I ZR 242/83):

• Standardsoftware vs. Individualsoftware: Wird Standardsoftware erworben oder angepasst, besteht in der Regel kein Anspruch auf den Quellcode. Die Gerichte argumentieren, dass der Kunde die Software auch ohne Quelltext nutzen kann und der Vertragszweck (Nutzung der Standardlösung) keine Herausgabe erfordert. Bereits das OLG München urteilte 1991 (Az. 25 U 2586/91), dass bei Standardsoftware der Quellcode nicht mitgeliefert werden muss, sofern nichts abweichendes vereinbart ist.
• Wurde hingegen Individualsoftware (also eine eigens für den Kunden entwickelte Anwendung) beauftragt, hängt es von den Umständen des Einzelfalls ab. Der BGH verlangt eine Interessenabwägung: Nach der Zweckübertragungsregel ist zu fragen, ob der bestimmungsgemäße Gebrauch der Software die Kenntnis des Quellcodes voraussetzt. Grundsatz: In der Regel kein Herausgabeanspruch, wenn die Nutzung des Programms auch ohne Quellcode möglich ist. Der Auftraggeber kann das fertige Programm schließlich nutzen, ohne selbst daran weiterzuentwickeln – genau das dürfte der Vertragszweck sein, sofern nicht anderes vereinbart wurde.
• Ausnahme – absehbarer Änderungsbedarf: Nur wenn für den Programmierer erkennbar war (oder ausdrücklich vereinbart wurde), dass der Auftraggeber oder ein Dritter später weitere Anpassungen oder Erweiterungen am Programm vornehmen will, kann ein Anspruch auf Herausgabe bejaht werden. Ein typisches Beispiel: Der Kunde hat klargemacht, dass er den Quellcode benötigt, um die Software selbst weiterzuentwickeln oder einen anderen Entwickler mit Updates zu beauftragen. Wenn ein solcher Zweck erkennbar Teil des Auftrags war, gehört der Quellcode zur geschuldeten Leistung – dann müsste der Entwickler ihn herausgeben (so wird BGH X ZR 129/01 allgemein verstanden).
• Während laufender Wartung kein Anspruch: Besonders strikt hat der BGH im Urteil vom 30.01.1986 (Az. I ZR 242/83) klargestellt, dass während der Laufzeit eines Wartungs- oder Pflegevertrags der Auftraggeber keinen Anspruch auf Herausgabe des Quellcodes hat. Denn solange der ursprüngliche Entwickler vertraglich zur Pflege verpflichtet ist, besteht gerade kein Bedarf, einen Dritten mit der Weiterentwicklung zu betrauen – der Zweck des Vertrags ist ja, dass der Entwickler selbst die Software betreut. Eine Herausgabe in dieser Phase würde das Vertragsgefüge stören und möglicherweise Geschäftsgeheimnisse des Entwicklers preisgeben, ohne dass der Kunde die Informationen zur vertragsgemäßen Nutzung benötigt.

Übertragen auf No-Code-Plattformen bedeutet das: Auch wenn kein klassischer Quelltext existiert, muss der Vertrag regeln, was der funktionale Äquivalent zum Quellcode ist und ob der Kunde darauf einen Anspruch hat. Bei einer traditionellen Software hätte man Quell- und Objektcode. Bei einer Airtable-Lösung könnten es beispielsweise die Basis-Konfiguration, Formeln, Scripte oder Automatisierungen sein, die der Entwickler eingerichtet hat. Bei Webflow könnten es der exportierte HTML/CSS/JS-Code der Website, sowie Zugänge zur Webflow-Instanz oder dem CMS sein. In Azure Logic Apps oder AWS Honeycode könnten es Workflow-Definitionen, JSON-Exports oder andere Beschreibungsdateien sein, welche die entwickelte Logik repräsentieren. Der Begriff „funktionales Äquivalent“ zielt darauf ab, dass dem Auftraggeber etwas an die Hand gegeben wird, mit dem er die entwickelte Anwendung selbstständig nutzen, reproduzieren oder verändern lassen kann, falls nötig – auch wenn es keinen handgeschriebenen Quellcode gibt.

Vertragsauslegung nach BGB: Fehlt eine ausdrückliche Vereinbarung, läuft es nach obiger Rechtsprechung oft darauf hinaus, dass kein Herausgabeanspruch besteht, solange der Kunde die No-Code-Lösung nutzen kann. Beispiel: Ein Start-up lässt sich von einer Agentur eine komplexe Airtable-Datenbank inkl. Automatisierungen erstellen. Nichts im Vertrag sagt etwas über Übergabe der „Dateien“ oder Konfiguration. Später will das Start-up einen anderen Dienstleister mit Änderungen beauftragen und verlangt vom ursprünglichen Entwickler die Herausgabe aller Einstellungen oder einen Daten-Export. Hat es einen Rechtsanspruch darauf? Wahrscheinlich nicht, denn nach § 31 Abs. 5 UrhG wird der Auftraggeber nur die Nutzungsrechte bekommen haben, die zum Betrieb der Airtable-Base nötig sind – und die Base läuft ja in Airtable, der Auftraggeber hat vermutlich ohnehin Zugriff als Nutzer. Die Konfiguration als solche (die man ggf. als urheberrechtlich geschütztes Softwarewerk oder Datenbankwerk ansehen kann) bleibt im Zweifel beim Entwickler. Ohne Vereinbarung könnte der Entwickler also argumentieren: „Ihr könnt die Airtable-Base doch verwenden wie vorgesehen, weitere Herausgabe schulde ich nicht.“ Ähnlich bei Webflow: Wenn der Vertrag nur die Bereitstellung der laufenden Website schuldet, muss der Entwickler ohne spezielle Abrede z.B. den Editor-Zugang oder den Design-Export nicht herausrücken – solange die Website wie vereinbart erreichbar und nutzbar ist, ist der Vertragszweck erfüllt.

Tipp: Um teure Streitigkeiten zu vermeiden, sollte im Vertrag ausdrücklich geregelt werden, was an den Auftraggeber herauszugeben ist. Idealerweise enthält ein No-Code-Vertrag eine Klausel wie etwa: „Der Auftragnehmer wird sämtliche zur Nutzung, Wartung und Weiterentwicklung der erstellten Anwendung erforderlichen Unterlagen, Dateien und Zugänge an den Auftraggeber herausgeben. Dies umfasst insbesondere [Auflistung: z.B. Export der Projektdateien, Dokumentation der Workflows, Administratorzugang zur Plattform XYZ, API-Dokumentationen etc.].“ Ebenfalls hilfreich ist eine Quellcode-Hinterlegung bzw. ein Escrow-Agreement – auch im No-Code-Kontext denkbar: Z.B. könnte man vereinbaren, dass die Konfigurationsdaten oder Designs bei einem Notar oder in einem Treuhand-Account hinterlegt werden, auf den der Kunde Zugriff erhält, falls der Entwickler ausfällt. In der Praxis wird oft einfacher verfahren, wie auch unser Beispiel-Wartungsvertrag zeigt: Dort blieb zwar der Quellcode zunächst beim Dienstleister, aber es wurde vereinbart, dass der Dienstleister auf Verlangen den Quellcode an den Auftraggeber oder einen von ihm benannten Dritten übergeben muss. Solche Klauseln übertragen das gerichtliche „Es kommt drauf an“ in klare Vertragsrechte. Gerade bei No-Code SaaS-Projekten sollte zusätzlich bedacht werden, dass oft der Betrieb der Anwendung an einen Account gebunden ist: Es ist sinnvoll zu regeln, dass die erstellte Anwendung auf einen Account des Auftraggebers übertragen wird oder dieser wenigstens ein Administratorenrecht daran erhält. Beispiel: Bei Webflow kann die entwickelte Website auf das Konto des Kunden transferiert werden; bei Airtable kann der Kunde als Owner der Base eingetragen sein. Verträge sollten vorsehen, dass der Dienstleister am Ende der Entwicklungsphase die vollständige Kontrolle übergibt – damit der Auftraggeber nicht in der Falle sitzt, wenn die Geschäftsbeziehung endet.

Zusammenfassend: „Quellcode-Herausgabe“ im No-Code-Kontext ist ein heikles Thema, das man vertraglich proaktiv lösen muss. Ohne klare Vereinbarung greift die Auslegung nach dem Zweckübertragungsgrundsatz – und danach erhält der Kunde oft weniger als gedacht (nur die Nutzung, nicht aber die Baupläne). Start-ups sollten also unbedingt darauf achten, dass ihr No-Code-Vertrag Klauseln zur Dokumentation und Herausgabe wichtiger Komponenten enthält. Andernfalls kann es passieren, dass sie bei einem Entwicklerwechsel vor einem verschlossenen System stehen. Aus Entwickler- bzw. Agentursicht wiederum ist es legitim, bestimmte Schutzmechanismen einzubauen – etwa dass Herausgabe erst nach vollständiger Bezahlung erfolgt oder dass eigene Geheimnisse gewahrt bleiben. Wichtig ist, dass beide Seiten ein klares gemeinsames Verständnis haben, was am Vertragsende geliefert wird – sei es Quellcode, Konfigurationsdaten oder zumindest die Zusicherung, Zugriff auf alles Wesentliche zu erhalten.

3. Umfang der Nutzungsrechte: Individuelle Software vs. Plattformbestandteile

Ein weiterer zentraler Aspekt eines rechtssicheren Softwarevertrags im No-Code-Bereich ist die Regelung der Nutzungsrechte. Bei klassischer Softwareentwicklung wird dem Auftraggeber typischerweise ein Nutzungsrecht am erstellten Programm eingeräumt – je nach Vereinbarung einfach (nicht-exklusiv) oder ausschließlich (exklusiv), räumlich und zeitlich unbeschränkt, oder mit gewissen Einschränkungen. Bei No-Code-Projekten ist die Lage komplexer, weil hier zwei Ebenen zusammentreffen:

1. Individuell erstellte Bestandteile: Das sind z.B. spezifische Workflows, Automatisierungen, Designs, Datenbanken oder andere kreative Elemente, die der Entwickler im Rahmen des Projekts geschaffen hat. Diese können grundsätzlich urheberrechtlich geschützt sein – etwa als Computerprogramm (§ 69a UrhG) oder als Datenbankwerk (§ 4 Abs. 2 UrhG) oder sogar als Gestaltung (Design, wenn es schöpferische Höhe erreicht). An diesen Teilen kann der Entwickler dem Auftraggeber Nutzungsrechte einräumen.
2. Plattform und vorgefertigte Komponenten: No-Code-Plattformen selbst (etwa Airtable, Webflow, Azure Logic Apps etc.) und deren Bausteine unterliegen den Lizenzbedingungen ihres Anbieters. Weder der Entwickler noch der Auftraggeber „besitzen“ den Quellcode der Plattform. Man hat lediglich Nutzungsrechte kraft des Vertrages mit dem Plattformanbieter (meistens in Form eines SaaS-Abos). Außerdem greifen oft Open-Source-Libraries oder Engine-Komponenten im Hintergrund, an denen Dritte Rechte halten.

Exklusive Nutzungsrechte an einer Software zu erhalten bedeutet, dass der Auftraggeber die Software unter Ausschluss aller anderen nutzen und verwerten darf – selbst der Entwickler dürfte sie dann nicht ohne weiteres anderweitig einsetzen. Bei individueller Softwareentwicklung für einen einzelnen Kunden ist es durchaus üblich, dem Kunden exklusive Nutzungsrechte an dem speziell für ihn entwickelten Code einzuräumen. Schließlich bezahlt er dafür und will ggf. seine Konkurrenz ausschließen. Im No-Code-Bereich muss man allerdings sauber trennen, was überhaupt exklusiv übertragbar ist. Der Entwickler kann nur Rechte übertragen, die ihm selbst zustehen. An der zugrundeliegenden Plattform (z.B. der Airtable-Software oder der Webflow-Engine) hat der Entwickler keine Rechte, die er weitergeben könnte – hier besitzt nur der Plattformanbieter die Urheberrechte. Folglich erhält der Kunde diese Leistungen nur zur Nutzung im Rahmen der Plattform-Lizenz. Praktisch heißt das: Ein Auftraggeber bekommt z.B. das Recht, die erstellte Webflow-Website zu nutzen, zu bearbeiten und online zu stellen – aber er erwirbt keinerlei Rechte an der Webflow-Software selbst. Ähnlich bei Azure Logic Apps: Der Workflow, den ein Dienstleister dort für den Kunden konfiguriert, mag kreativ sein, aber der Kunde kann nur im Rahmen von Microsofts Azure-Plattform darauf zugreifen. Urheberrechtlich könnte man diskutieren, ob der spezifische Workflow als Computerprogramm dem Dienstleister gehört – aber selbst wenn, braucht der Kunde hauptsächlich die Betriebserlaubnis auf Azure. Dafür sorgt Microsofts SaaS-Vertrag (gegenüber dem Kunden oder dem Dienstleister, je nach Konstellation).

Übliche Lizenzmodelle und Ausschlussklauseln: In der IT-Branche ist es üblich, Verträge so zu formulieren, dass der Auftraggeber alle erforderlichen Nutzungsrechte an den Lieferungen erhält, aber der Entwickler gewisse allgemeine Rechte oder Drittkomponenten ausnimmt. Zum Beispiel findet sich oft eine Klausel, dass der Auftraggeber ein exklusives Nutzungsrecht an der Individualsoftware erhält, jedoch ohne die Rechte an allgemein verwendbaren Modulen, an Open-Source-Komponenten oder an der Entwicklungsumgebung selbst. Diese bleiben beim Urheber bzw. bei Drittanbietern. Stattdessen erhält der Kunde daran ein einfaches Nutzungsrecht, soweit nötig. Eine solche Klausel könnte etwa lauten: „Der Auftraggeber erhält an den vom Auftragnehmer individuell erbrachten Arbeitsergebnissen (einschließlich Softwarecode, Scripten, Konfigurationen und Dokumentationen) das ausschließliche, zeitlich und räumlich unbeschränkte Nutzungsrecht für alle bekannten Nutzungsarten. Der Auftragnehmer bleibt berechtigt, allgemeine Konzepte, wiederverwendbare Bausteine und sein Know-how frei zu nutzen. Rechte an von Dritten stammenden Komponenten (insbesondere an der No-Code-Plattform selbst, an Bibliotheken oder an Open-Source-Software) werden nicht übertragen; insoweit erhält der Auftraggeber lediglich die nach dem jeweiligen Lizenzvertrag zulässigen Nutzungsbefugnisse.“

Eine solche Regelung stellt sicher, dass der Kunde die volle Kontrolle über die Ergebnisse der beauftragten Entwicklung hat (er kann sie nutzen, verändern, weiterlizenzieren etc., soweit es die individuelle Leistung betrifft). Gleichzeitig schützt sie den Entwickler davor, ungewollt seine allgemeinen Lösungen oder Vorlagen zu verlieren – und sie wahrt die Rechteinhaber Dritter. Gerade im No-Code-Vertrag sollte ausdrücklich erwähnt werden, dass Plattform-Bestandteile und evtl. integrierte Dienste nicht Teil der Rechteübertragung sind. Zum Beispiel: Ein Vertragsanhang könnte alle verwendeten Drittservices auflisten (z.B. „Verwendete Dienste: Airtable (Cloud-Datenbank), Webflow (Web-Builder), Google Maps API, Open-Source-Library XYZ unter MIT-Lizenz“…) und klarstellen, dass der Auftraggeber diese Komponenten nur im Rahmen der jeweiligen Nutzungsbedingungen verwenden darf.

Open Source und Engine-Komponenten: Ein analoger Fall lässt sich in der Spieleentwicklung beobachten: Wenn ein Studio ein Spiel auf Basis einer Game-Engine (wie Unity oder Unreal) entwickelt, kann der Publisher nicht die Engine-Rechte vom Studio einfordern – diese liegen bei Unity/Unreal. Ähnlich sind bei No-Code die „Engine“ oder Framework-Bestandteile nicht exklusiv verfügbar. Oftmals greifen auch Open-Source-Module in No-Code-Plattformen (z.B. ein JavaScript-Library, die in Webflow-Export genutzt wird). Hier greift automatisch die jeweilige Open-Source-Lizenz: Der Auftraggeber darf diese Komponenten nutzen, muss aber Lizenzauflagen einhalten (etwa Nennung von Lizenztexten, keine exklusive Verwertung). Ein rechtssicherer Softwarevertrag wird diese Punkte bedenken: Im Zweifel schadet es nicht, im Vertrag zu erwähnen, dass bestimmte Softwareteile Open Source sind und unter welcher Lizenz sie stehen – so weiß der Auftraggeber, was er darf und was nicht (z.B. darf er eine bestimmte Komponente nicht kommerziell weiterverkaufen, falls Lizenz das verbietet).

Zusammengefasst: Der Umfang der Nutzungsrechte sollte bei No-Code-Entwicklungsverträgen sehr deutlich beschrieben sein. Der Auftraggeber will sicherstellen, dass er an allen individuellen Ergebnissen die notwendigen Rechte erhält – am besten exklusiv, um die Lösung frei nutzen und weiterentwickeln zu können. Gleichzeitig muss akzeptiert werden, dass die zugrundeliegende Infrastruktur und generische Bausteine nicht ihm gehören können. Wichtig ist daher eine Abgrenzung individueller Software vs. Plattformbestandteile im Vertrag. Dann ist klar, wofür der Kunde bezahlt (und Eigentum/Nutzungsrechte erwirbt) und was außerhalb dieses Bereichs liegt. Fehlt eine solche Klarstellung, drohen Konflikte: Entweder fühlt der Kunde sich getäuscht, weil er dachte „alles gehört ihm“, oder der Entwickler sieht sein Know-how gefährdet. Mit präzisen Lizenzklauseln und Branchen-üblichen Ausschlüssen lässt sich das vermeiden.

4. Praktische Hinweise für No-Code-Verträge

Abschließend einige praktische Tipps, welche Punkte in Verträgen für No-Code-/Low-Code-Projekte unbedingt geregelt sein sollten, und wo typische Missverständnisse lauern:

• Leistungsumfang und Vertragstyp klären: Beschreiben Sie genau, welche Leistungen der Entwickler erbringt (z.B. Konfiguration einer Airtable-Datenbank, Erstellung einer Webflow-Website, Implementierung von API-Integrationen, laufende Wartung etc.). Legen Sie fest, welche als Werkleistungen mit Abnahme gelten (z.B. die erstmalige Erstellung der Anwendung bis zur Live-Schaltung) und welche als Dienste im Rahmen eines Dauerschuldverhältnisses (z.B. anschließende Betreuung, SEO oder Hosting). Damit ist von vornherein klar, ob es ein No-Code-Vertrag im Sinne eines Werkvertrags, Dienstvertrags oder Mischvertrags ist. Bei Mischformen unbedingt Schwerpunkt definieren oder Leistungen trennen – so verhindern Sie Streit über Kündigungsrechte und Vergütung.
• Vergütung, Laufzeit und Kündigung: Bei Pauschalvergütungen (Flatrate-Modellen) sollte transparent sein, was abgedeckt ist (z.B. bis zu X Stunden Support im Monat, Monitoring, kleinere Bugfixes) und was nicht. Regeln Sie, wie mit Mehrleistungen umgegangen wird – etwa ein Stunden- oder Tagessatz für zusätzliche Anforderungen, die über das Paket hinausgehen. Definieren Sie die Laufzeit des Wartungsvertrags und Kündigungsfristen klar. Eine lange Grundlaufzeit mit automatischer Verlängerung, wie im LG Köln-Fall, ist üblich, aber bedenken Sie: Handelt es sich um einen Dienstvertrag, ist eine ordentliche Kündigung während der Laufzeit grundsätzlich ausgeschlossen, außer vertraglich vorgesehen. Werkverträge kann der Auftraggeber jederzeit kündigen (§ 648 BGB), was für den Dienstleister ein finanzielles Risiko ist. Stimmen Sie daher Vertragsmodell und Kündigungsklauseln aufeinander ab, um unerwünschte Lücken (oder Überraschungen durch gesetzliche Regelungen) zu vermeiden.
• Herausgabe von Unterlagen und Zugängen: Vereinbaren Sie ausdrücklich, welche Unterlagen, Daten und Zugänge der Entwickler dem Auftraggeber übergeben muss. In einem No-Code-Vertrag sollten Stichworte wie „Quellcode“, „Konfigurationsdaten“, „Dokumentation“, „Zugangsdaten“ etc. auftauchen. Beispielsweise: Admin-Zugang zur Webflow-Instanz, API-Schlüssel, Beschreibung aller Workflows in Azure Logic Apps (Urheberrecht an den Workflows bleibt beim Entwickler, aber der Auftraggeber erhält ein Nutzungsrecht – vgl. Azure Logic Apps Urheberrecht), Export der Datenbankstrukturen aus Airtable etc. Je nach Plattform kann das sehr individuell sein. Wichtig ist: beide Seiten wissen, worauf der Auftraggeber nach Projektende Anspruch hat. So vermeiden Sie die Situation „Quellcode Herausgabe No-Code“ – bei der der Auftraggeber realisiert, dass es gar keinen traditionellen Code gibt und vertraglich nichts vorgesehen ist.
• Nutzungsrechte umfassend aber präzise regeln: Stellen Sie sicher, dass der Vertrag eine Nutzungsrechtsklausel enthält, die auf die Besonderheiten eingeht. Der Auftraggeber sollte mindestens ein zeitlich und räumlich unbeschränktes Nutzungsrecht an der erstellten Lösung erhalten, um sie im vorgesehenen Umfang zu betreiben. Falls gewünscht, vereinbaren Sie exklusive Rechte an den individuellen Teilen, damit der Auftraggeber z.B. der einzige ist, der diese spezifische Kombination oder Lösung nutzen darf. Gleichzeitig sollte im Vertrag stehen, dass Plattform- und Drittkomponenten nicht vom Entwickler übertragen werden können. Damit ist z.B. klargestellt, dass der Kunde zwar die fertige Webflow-Website nutzen darf, aber natürlich keine Rechte an der Webflow-Software oder an allgemeinen Templates erwirbt. Solche Klauseln wirken vielleicht selbstverständlich, aber in Streitfällen (und auch in der Wahrnehmung des Kunden) sind sie Gold wert. Begriffe wie „Nutzungsrechte Softwareentwicklung“ oder „exklusives Nutzungsrecht“ können im Vertrag als Überschrift dienen, damit die Bedeutung unübersehbar ist.
• Drittanbieter, APIs und Mitwirkungspflichten: No-Code-Lösungen leben von Integrationen – sei es die Einbindung eines Zahlungsanbieters per API, die Nutzung von externen Datenbanken oder von SaaS-Diensten (CRM, E-Mail usw.). Der Vertrag sollte regeln, wer für diese Drittleistungen verantwortlich ist. Muss der Auftraggeber eigene Lizenzen/Abos für Airtable, Webflow & Co. bereitstellen? Trägt er die Kosten dafür direkt? Oder besorgt der Entwickler das und stellt es in Rechnung? Wer haftet, wenn ein externer Dienst ausfällt oder seine API-Policies ändert (Stichwort: Webflow API Recht – z.B. wenn Webflow die API-Nutzung einschränkt, sollte der Entwickler nicht ungeprüft dafür haften müssen)? Zudem: Oft ist der Auftraggeber verpflichtet mitzuhelfen, etwa indem er Accounts einrichtet oder Zugang zu seinem Azure-Portal gibt. Solche Mitwirkungspflichten gehören in den Vertrag. Ebenso sollte eine Klausel zu Änderungen der Plattform rein: Wenn die No-Code-Plattform während der Vertragsdauer ein Update erfährt oder Funktionen einstellt, muss klar sein, ob der Entwickler verpflichtet ist, kostenlos nachzubessern, oder ob das einen neuen Auftrag darstellt.
• Gewährleistung und Haftung anpassen: Standard-IT-Verträge enthalten Gewährleistungsregelungen für Software (Mängelbeseitigung etc.). Bei No-Code muss man im Blick haben, dass manche Probleme aus der Plattform kommen könnten. Zum Beispiel, ein Bug in der Airtable-Software selbst oder eine Änderung in Azure Logic Apps, die einen Flow bricht – dafür kann der Entwickler idR. nichts. Der Vertrag sollte solche Fälle in der Haftung adressieren (etwa höhere Gewalt oder Ausschluss der Haftung für Umstände außerhalb der Kontrolle des Entwicklers). Zudem sollte die Gewährleistungsfrist für Werkleistungen definiert sein, aber bei dauerhaften Dienstleistungen greift statt Gewährleistung eher das Dienstvertragsrecht (also nur Haftung bei Schlechtleistung). Klären Sie auch, ob der Entwickler für Rechtsmängel haftet – beispielsweise wenn er Open-Source-Komponenten einsetzt, muss er gewährleisten, dass diese die Software nicht „verseuchen“ (Stichwort Copyleft-Lizenzen).
• Keine blinden Übernahmen von Musterklauseln: No-Code-Projekte unterscheiden sich in einigen Punkten erheblich von klassischen Softwareprojekten. Standardklauseln aus einem herkömmlichen IT-Vertrag decken oft wichtige Besonderheiten nicht ab. Beispiel: Ein übliches Vertragsmuster könnte vorsehen, dass der Entwickler am Ende „sämtliche Quellcodes, Builds und Dokumentationen“ übergibt. Wer nur mit Baukasten gearbeitet hat, steht dann vor der Frage: Habe ich überhaupt einen „Build“? Was, wenn Teile der Applikation gar nicht exportierbar sind, weil sie in der Cloud bleiben müssen? Umgekehrt könnte ein Mustermuster-Vertrag das Thema laufende Pflege gar nicht behandeln, obwohl es faktisch vereinbart wurde – ein Risiko, denn dann gelten default die gesetzlichen Regelungen, die vielleicht nicht passen (z.B. könnte ein Richter das ganze als Dienstvertrag einstufen, obwohl der Text nicht eindeutig war). Auch Vorsicht bei Übersetzungen: Manche nutzen englische Templates, aber Begriffe wie „License“ oder „Work Made for Hire“ haben im deutschen Recht andere Entsprechungen. Fazit: Einen Vertrag für ein No-Code/Low-Code-Projekt sollte man nicht im Copy-Paste-Verfahren zusammenstellen. Besser gezielt anpassen oder – noch besser – von Anfang an durch einen Experten entwerfen lassen.

Warum professionelle Beratung? Die obigen Hinweise zeigen: Ein vermeintlich „einfaches“ No-Code-Projekt wirft ähnlich komplexe juristische Fragen auf wie ein klassisches Softwareprojekt, teils sogar neuartige. Die technische Struktur (Baukasten, SaaS, APIs) muss sich in der vertraglichen Struktur widerspiegeln. Start-ups und Agenturen laufen Gefahr, wichtige Punkte zu übersehen, gerade weil No-Code-Tools vieles abstrahieren. Die Erfahrung eines IT-Rechtsanwalts, der sowohl die rechtlichen Feinheiten als auch die technischen Gegebenheiten von No-Code-/Low-Code-Stacks versteht, ist hier enorm wertvoll. Nur so entstehen Verträge, die beide Seiten schützen, die wirtschaftlichen Ziele absichern und rechtlich Bestand haben.

Fazit

Die Entwicklung von Software auf No-Code-Plattformen wie Airtable, Webflow, AWS Honeycode oder Azure Logic Apps ist ein Game-Changer für schnelle Ergebnisse – aber kein Freifahrtschein, die Juristerei zu ignorieren. Im Gegenteil: Weil die Technik anders ist, müssen Verträge umso genauer hinsehen. Ob es um die korrekte Einordnung von Wartungsverträgen (Dienst- vs. Werkvertrag), um die Herausgabe von Quellcode bzw. Konfigurationen, um die Nutzungsrechte an der Software oder um praktische Vertragsdetails geht – jedes Detail zählt, um einen No-Code-Vertrag wirklich rechtssicher zu machen. Wer all dies berücksichtigt, schützt sich vor bösen Überraschungen und legt den Grundstein für eine vertrauensvolle Zusammenarbeit zwischen Auftraggeber und Dienstleister.

Insbesondere Start-ups, Agenturen und IT-Projektleiter sollten die geschilderten Fallstricke ernst nehmen. Ein unklarer Vertrag kann im Nachhinein viel Geld, Zeit und Nerven kosten – etwa wenn ein Investor fragt, wem eigentlich die Rechte an der entwickelten App gehören, oder wenn der Entwickler plötzlich nicht mehr greifbar ist und man feststellt, dass man keinen Zugriff auf wichtige Komponenten hat. Rechtsanwälte für IT-Recht mit Erfahrung in SaaS und digitalen Plattformprojekten können hier wertvolle Begleiter sein: Sie kennen die relevante Rechtsprechung (von BGH X ZR 6/00 bis LG Köln „Flatrate-SEO“), sie verstehen Begriffe wie „Zweckübertragungsregel“ und API-Lizenzbedingungen, und sie wissen auch technisch, was es bedeutet, wenn eine Webflow-Website exportiert wird oder ein Skript in Airtable hinterlegt ist.

Kurzum, ein rechtssicherer Softwarevertrag für No-Code-Projekte vereint juristische Präzision mit Verständnis für die Low-Code-Welt. Damit können innovative Unternehmen die Vorteile von No-Code voll ausschöpfen, ohne rechtlich auf dünnem Eis zu stehen. Die investierte Mühe in eine saubere Vertragsgestaltung zahlt sich am Ende aus – und im Zweifel steht ein spezialisierter Anwalt bereit, um genau diesen Mehrwert zu bieten. Denn No-Code hin oder her: Bei Verträgen sollte man kein „No-Law“ riskieren.