No-Code Vertrag: Recht & Software | IT-Medienrecht

Rechtssichere Vertragsgestaltung bei Softwareentwicklung auf No-Code-Plattformen

No-Code- und Low-Code-Plattformen ermöglichen es Start-ups und Agenturen, Software sowie 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 für die Vertragsgestaltung.

Wir klären, wie Wartungsverträge bei No-Code einzuordnen sind, wann ein Anspruch auf Quellcode oder funktionale Äquivalente besteht und wie Nutzungsrechte an individuell erstellten Komponenten versus Plattform-Bestandteilen geregelt werden. Zudem zeigen wir, welche praktischen Klauseln in keinem „No-Code SaaS Recht“-Vertrag fehlen dürfen. Dieser Beitrag unterstreicht, warum rechtssichere Softwareverträge in diesem Bereich nur mit professioneller Beratung gelingen.

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 Bürgerliche Gesetzbuch (BGB) zwischen Dienstvertrag (§ 611 BGB) und Werkvertrag (§ 631 BGB).

• Dienstvertrag: Der Dienstleister schuldet ein Tätigwerden, also Bemühungen, aber keinen bestimmten Erfolg.
• Werkvertrag: Es wird ein konkreter Erfolg geschuldet (ein „Werk“), das der Auftraggeber abnehmen kann. Ein Beispiel ist eine fertig programmierte Applikation, die bestimmte Anforderungen erfüllt.

Diese Unterscheidung hat erhebliche Folgen: Bei einem Werkvertrag greifen Gewährleistungsrechte und Abnahme. Der Auftraggeber kann unter Umständen nach § 648 BGB vor Fertigstellung kündigen. Bei einem Dienstvertrag hingegen gilt „pacta sunt servanda“ – der Vertrag läuft grundsätzlich für die vereinbarte Dauer. Es besteht kein Anspruch auf einen bestimmten Erfolg, sondern nur auf sorgfältiges Tätigwerden.

Einordnung von Wartungsleistungen als Dienstvertrag

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 erbringt der Dienstleister bereitstellungs- und überwachungsbezogene Leistungen.

Dazu zählen regelmäßiges Monitoring, das Einspielen von Updates, die Behebung von Bugs oder die Gewährleistung einer bestimmten Reaktionszeit im Fehlerfall. Die Rechtsprechung tendiert dazu, solche Flatrate-Vereinbarungen als Dienstvertrag zu qualifizieren. Dies betrifft auch Kundenhotlines und Support im SaaS.

Ein Beispiel: Das Landgericht Köln entschied 2015 (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 Werk-Charakter hatten, überwogen die laufenden Marketing- und SEO-Leistungen.

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. 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.

Praktische Konsequenzen für die Vertragsgestaltung

Für die Praxis bedeutet das, Klarheit im Vertragstyp zu schaffen. Ist die laufende Betreuung einer No-Code-Anwendung vereinbart, sollte ausdrücklich geregelt werden, dass es sich – wenn so gewollt – um einen Dienstvertrag handelt. Dieser beinhaltet eine kontinuierliche Mitwirkung ohne Erfolgsgarantie.

Andernfalls könnte der Auftraggeber versuchen, einzelne Ergebnisse als „Werke“ einzustufen. Dies hätte zur Folge, dass Abnahme verlangt oder vorzeitig gekündigt werden könnte. Werden in einem Vertrag sowohl Entwicklungsleistungen (Werk) als auch Wartung (Dienst) kombiniert, entsteht ein Mischvertrag. Hier empfiehlt es sich, die Leistungsarten klar getrennt zu regeln, etwa in separaten Vertragsteilen oder sogar getrennten Verträgen. 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, besonders wenn es wenige Störungen gibt. 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. Dies stellt bereits die vergütete Leistung dar, unabhängig davon, ob ein konkreter Fehler behoben werden musste. Aus Sicht von Treu und Glauben (§ 242 BGB) sollte ein Auftragnehmer dennoch für Transparenz sorgen.

Empfehlenswert sind Reporting-Pflichten im Vertrag. Ein monatlicher Bericht über durchgeführte Prüfungen, Updates oder Backups schafft Nachvollziehbarkeit und Vertrauen. Zudem lassen sich so spätere Streitigkeiten vermeiden. Beide Seiten wissen, welche unsichtbaren Aufgaben erbracht wurden.

Zusammenfassend spricht bei Wartungsverträgen im No-Code-Bereich 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. Es sollten jedoch Mechanismen vereinbart werden, wie zusätzliche Leistungen gehandhabt werden.

Kommt es zu aufwendigen, ursprünglich nicht abgedeckten Tätigkeiten, kann eine Vergütungsanpassung nach Werkvertragsrecht in Betracht kommen. Der Bundesgerichtshof (Urteil vom 08.01.2002 – Az. X ZR 6/00) entschied, 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 bedeutet dies: 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.

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“?

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.
• Individualsoftware: 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.
• 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.
• 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.

Funktionale Äquivalente im No-Code-Kontext

Übertragen auf No-Code-Plattformen bedeutet das: Auch wenn kein klassischer Quelltext existiert, muss der Vertrag regeln, was das 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, womit er die entwickelte Anwendung selbstständig nutzen, reproduzieren oder verändern lassen kann, falls nötig – auch wenn es keinen handgeschriebenen Quellcode gibt.

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.

Vertragsgestaltung für klare Verhältnisse

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. Der Kunde erhält darauf Zugriff, falls der Entwickler ausfällt. 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.

Zusammenfassend ist die „Quellcode-Herausgabe“ im No-Code-Kontext ein heikles Thema, das man vertraglich proaktiv lösen muss. Ohne klare Vereinbarung greift die Auslegung nach dem Zweckübertragungsgrundsatz. Danach erhält der Kunde oft weniger als gedacht. 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.

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. Dieses kann je nach Vereinbarung einfach (nicht-exklusiv) oder ausschließlich (exklusiv), räumlich und zeitlich unbeschränkt oder mit gewissen Einschränkungen sein. Bei No-Code-Projekten ist die Lage komplexer, da hier zwei Ebenen zusammentreffen:

1. Individuell erstellte Bestandteile: Dies 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 in der No-Code-Welt

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. 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. 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 eventuell integrierte Dienste nicht Teil der Rechteübertragung sind. Zum Beispiel: Ein Vertragsanhang könnte alle verwendeten Drittservices auflisten 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 im 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.

Zusammenfassend: 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 was außerhalb dieses Bereichs liegt.

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, um Streit über Kündigungsrechte und Vergütung zu verhindern.

• Vergütung, Laufzeit und Kündigung regeln

  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. Definieren Sie die Laufzeit des Wartungsvertrags und Kündigungsfristen klar. Eine lange Grundlaufzeit mit automatischer Verlängerung 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.

• 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, Export der Datenbankstrukturen aus Airtable. Je nach Plattform kann das sehr individuell sein. Wichtig ist, dass 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 und 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. So 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 sind sie Gold wert. Begriffe wie „Nutzungsrechte Softwareentwicklung“ oder „exklusives Nutzungsrecht“ können im Vertrag als Überschrift dienen.

• Drittanbieter, APIs und Mitwirkungspflichten

  No-Code-Lösungen leben von Integrationen – sei es die Einbindung eines Zahlungsanbieters per API oder die Nutzung von externen Datenbanken oder SaaS-Diensten. Der Vertrag sollte regeln, wer für diese Drittleistungen verantwortlich ist. Muss der Auftraggeber eigene Lizenzen/Abos bereitstellen? Trägt er die Kosten dafür direkt? Wer haftet, wenn ein externer Dienst ausfällt oder seine API-Policies ändert (Stichwort: Webflow API Recht)? 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.

• 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 in der Regel 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. Klären Sie auch, ob der Entwickler für Rechtsmängel haftet, beispielsweise wenn er Open-Source-Komponenten einsetzt.

• 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 Mustervertrag 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. 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. Sie ist 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. 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. 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.